Human-Centered Software: Creating More Value by Balancing Feasibility, Viability, & Desirability

As software makers, the chief goal of any project is to deliver the best user experience possible in terms of beauty (visual and interaction design), usability (workflows and information architecture), and usefulness (features and functionality). In a perfect world, every interface that I design and build would have an ideal, easy-to-use workflow, a carefully crafted information architecture, be perfectly polished down to the last pixel and keyframe, and go through rigorous user testing before being deployed to production.

If only reality were so kind.

Every day, software teams are faced with decisions that affect the design of the product that they are building. Changing requirements, additional discovery, and constraints in technology, budget, and deadline will all have an impact on the user’s experience. It’s up to the team to ensure that the impact is a good one.

One of Atomic’s partners, the international design consultancy IDEO, famously frames this tension with the Desirability-Viability-Feasibility venn diagram. Design thinking, or human-centered design, is the practice of using these three lenses to find the best solution to a problem.

The Value of Integrated Teams

Atomic Object’s project teams are integrated, bringing together designers and developers to form one product team. This makes us uniquely equipped to use human-centered design and create a superior product. Designers, developers, and clients work closely together to explore and balance the facets of desirability, viability, and feasibility within each feature and component of the project. Because we’re consciously viewing our work through these three lenses — and recognizing when tension arises between them — we can handle constraints in the best way possible, and even leverage them for good. This makes sure the end product meets both user needs and business objectives.

As a designer, my default position is to look at everything through the desirability lens. My gut instinct is to fight for the things that are the most elegant, easy, and usable. By taking a step back and engaging with my team to understand a project through the lenses of feasibility and viability, I begin to see things in a different way, and sometimes I make different choices when it comes to deciding what’s valuable for the project.

Viability & Desirability: Using business constraints to focus design effort on the areas of greatest impact

At face value, you might assume that viability (business needs) and desirability (user needs) are unlikely to be at odds with each other. Providing a good user experience is good for the business, right? While this is true to a certain extent, business needs — whether they’re related to timing, budget, or other goals — are often at odds with providing a perfect user experience. When this happens, taking a close look through the lenses of viability and desirability can help the team make smart decisions.

One experience I’ve had in maximizing the intersection between viability and desirability was when one of our clients needed to completely replace a piece of custom software that is core to their business model. The software has a web-based backend that allows their staff to add, change, and track records within their system, and a native iOS iPad app that the client’s contractors use in the field.

This project is a significant investment for our client, representing a large portion of their budget this year, and the feature set has to support the needs of many groups across their organization. As we began developing the software, our team recognized that both the budget and the release timetable were going to be tight, and to deliver the value our client needed, we had to economize wherever possible.

One important decision we made, in collaboration with our client, was that we would focus our UX efforts on the iPad application and not spend as much time on the administrative interface. We made our decision by considering the needs of the personas who would be using our application: it was important to have a polished, well-tested experience for the contractors who were using the iPad application in the field, and for the people who the contractors were working with. The contractors will be using the iPad to complete a complex process as quickly and accurately as possible in an unpredictable environment, and the people in the field need to see a smooth, polished process that gives them a sense of confidence and trust in our client and their representatives. Therefore, we put a lot of effort into designing a visually appealing user interface, creating usable controls and workflows, and doing usability testing on the iPad application.

The web-based administrative interface, on the other hand, is only ever be seen by a few of our client’s employees, who use it in the controlled environment of their office. From a visual design standpoint, it’s pretty spartan. Some of the UI elements are visually inconsistent (owing to a combination of browser default controls, and leveraging open-source javascript components with their default skins) and many of the workflows aren’t as smooth as I’d like. However, I don’t think it’s bad software design, because it’s the right balance of desirability, feasibility, and viability for the client’s needs.

While the design perfectionist in me wishes we could take the time to make the administrative interface more visually appealing, that wouldn’t be a wise spend of our client’s budget or the team’s time. The client needs this piece of software ASAP, and the tool serves their needs. Perhaps in later revisions, after the client’s staff has had a chance to live with the software, we’ll have a chance to work with them to streamline the high-impact features.

Desirability & Feasibility: Making informed implementation decisions

Many of the tensions that arise between designers and developers result from conflicts between desirability and feasibility. When these conflicts arise, integrated teams have a serious advantage over siloed teams.

The harsh reality of technology is that the most elegant user interfaces aren’t always the easiest ones to implement. While I may have a great idea for a widget, workflow, or interaction, constraints in technology (or sometimes, in a developer’s skill) can make my designs difficult or expensive to implement. In cases where a designer simply hands off a mockup to a developer and says, “Here, implement this,” technology constraints are often the biggest reason for a designer’s intentions not being fully realized. The mockups are treated as the end product of a design, not the first step.

At AO, I have the privilege of working with developers who are extremely aware of user needs — one could say we practice Human-Centered Development as well as design. When I’m working on a user interface, my mockups and sketches are the first step in a conversation about what the best solution would be for a design problem. When I have ideas that are difficult to implement, my team members and I usually step up to the whiteboard and have an open discussion about the complicating factors from the standpoint of both user needs and technological implications. In these discussions, we work together to come up with the best solution. Sometimes we decide to go the extra technological mile and implement my design after all, because it contains an element that’s crucial to the user experience. But more often, we come up with a new solution that’s better than my original idea and provides maximum impact for user needs, technology needs, and our customer’s needs.

Using Human-Centered Design for Software Rewrites

If you are rewriting a complex, internally-facing software application, applying human-centered design (HCD) practices is a key play for driving success with end users and management.

The Challenges of Rewriting

Many custom, internal applications were originally created for complex, custom business processes that couldn’t be satisfied through off-the-shelf software. After an initial, significant development phase, subsequent development is usually made as incremental add-ons with tight time and budget constraints.

There is usually not enough prioritization, time, or budget for add-on requests to focus on the application holistically or on overall quality. It’s not uncommon for IT maintenance teams to manage and perform update requests solely through digital request systems that don’t facilitate or encourage collaborative design or testing. When it’s time to rewrite an internal application, the user experience, technology stack, and code quality are usually extremely complex and woefully neglected.

Due to expectations of feature parity, significant undocumented complexity, and transition management considerations, I believe a successful rewrite project is more difficult and daunting than new product development.

A Better Approach

As a first step, get the right team to take on your rewrite project. Don’t ask an IT team that is accustomed to updates and maintenance to take on a massive rewrite effort. An experienced product development team, supported by key IT team members for infrastructure and integration expertise, will do a better job at scoping, planning, and executing.

A good product development team will apply HCD methods during your project’s scoping and planning phase. This will help refine and prioritize requirements.

Early in the scoping and planning phase, have your team’s lead designer and developer:

• Work with business stakeholders to identify the different functional groups of users, the value each group creates from use of the application, and the number of users in each group.
• Meet with and job shadow five to eight users (some is better than none, but value diminishes beyond eight) from each functional group to learn how the existing software is used. Identify:
• Goals and common use patterns over different dimensions of time (e.g. daily, weekly, etc.)
• Essential features and pain points
• Unused features
• Tools used outside of the system that could be beneficial to add or integrate (you may observe cheat sheets, sticky notes on monitors, data dumped into Excel and re-imported into the application, etc.)

After the lead designer and developer meet with users across functional groups, they can work to identify:

• Features that could be improved to increase efficiency, quality, etc.
• Features that can be simply copied
• Features that could be removed
• Cross-cutting features that are valuable to multiple functional groups
• Groupings of features that could represent a meaningful, intermediate release for one or multiple functional groups

Another added bonus of meeting directly with end users is that they will likely feel valued and invested in the project. Users will more likely be enthusiastic about the rewrite project when they are part of the change instead of having change forced upon them. You can continue to build enthusiasm and support by keeping users involved in design feedback sessions and also seeking their feedback on release plans.

The Benefits of Using Human-Centered Design Methods

By employing HCD methods, you will build goodwill and enthusiasm for your rewrite project. You will gain validated insights into possible, incremental release plans.

Incremental progress builds momentum, delivers value early, and increases managerial support. This approach is much more satisfying than the common pattern of simply updating technology, delivering a monolithic release (likely late and over-budget), and being bombarded by complaints about how the big upgrade missed the mark.

‍