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

As a designer, my chief goal within 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.


Creating a great piece of software is tricky and expensive, and teams who aren’t sensitive to the tensions between feasibility, viability, and desirability can be doomed to deliver a sub-par product. However, by communicating openly and deliberately looking at the project through the three different lenses, integrated teams can turn constraints into advantages and produce an innovative solution.