The UX Triple-Constraint
Time, Complexity and the User Experience
4 minute read
Someone much smarter than I has probably already made this observation, but it occurred to me in a recent discussion with a product stakeholder that there exists a kind of “usability triple constraint,” not too different from the one folks in the project management world have recognized for years.
The triple constraint is a project management model that says that all projects are a balance of time, resources, and quality. Or, as the sign behind the counter at my auto mechanic puts it:
“We offer three kinds of service: Fast, Good, and Cheap. You can pick any two.”
The argument continues that, in order to get something quickly and of good quality, it’s going to cost you. To get something quickly at a lower cost, you’re going to sacrifice quality. Finally, to get something of good quality at a lower cost, it’s going to take time.
A similar trinity exists in terms of usability.
Time, Complexity, and the User Experience
The balancing act, in this case, consists of time, complexity, and the user experience.
Time refers to the project schedule; how long it will take to deliver the item in question, which might be a feature, a product feature-set, or a complete product. This is often the most immediate concern in the stakeholder’s mind, the “when can I have it.”
Complexity refers to the scope of the product, the requirements and business rules, and where those items get played out in the user experience. Almost all useful products carry with them a high level of complexity. The issue in software design is not to drive complexity from the finished product, but to channel it.
Designers and developers work together to present complex concepts and enable complex interactions without burdening the user. This is the real work of software design and development: You worry over the little details of the user interface, or grind out code that shifts complexity away from the UI and into the business layer of the product.
Good software does the hard stuff for the user; clears a path, guides, and enables her to achieve her goals. If the team doesn’t handle that complexity, then it is left to the user to do so, resulting in a confusing or frustrating experience.
Within the context of the usability triple constraint, the team’s arguments might sound like:
- “If it’s complex, we can get it to you fast, but the user is going to suffer.”
- “If we remove some complexity from this iteration we can get it to you faster and still provide a good user experience.”
- “If you want to keep the full feature-set and still deliver a good user experience, we’re going to need more time.”
The Inevitable Time Crunch
The usability triple constraint is a useful concept to keep in mind when negotiating with stakeholders on tight deadlines. Unless you are working in a truly user-centered organization, the fact remains that it is usually the design team who has to advocate for the user. Many organizations are still heavily production-focused and a team may find itself in a predicament where its user-centered philosophy does not yet completely mesh with the existing culture.
So how do you manage these constraints?
Buy time, if possible. Stakeholders usually understand the importance of a good user experience, but when the chips are down, the expectation invariably shifts back to the schedule, and the implications of not sufficiently addressing complexity under a tight deadline are usually more damaging than a schedule adjustment. Remind them of this.
Remove complexity. Sometimes, the best way to address the issue is to defer a business rule or feature altogether. Save it for the next iteration.
A Model Comparison
While comparing the relationship between time, complexity, and the user experience with those of the traditional triple constraint may not be perfectly analogous, the give-and-take represented in both models is strikingly similar. It is an interesting comparison. When working on products where time and complexity are at odds, the UX triple constraint provides a handy means for framing your case for the user.