If you want to avoid endless iterations of a design with (internal) clients, team members or developers, it’s time to start focusing on outcome instead of output. Or even, the personal taste of the client.
First of all: we design for the user in the first place. These people are the ones that eventually will use the product. So we need to keep them in mind when we start designing. What do they want to accomplish?
Do you prefer listening over reading?
We have released a podcast on this topic as well!
What is the difference between output and outcome?
An output is a product or service that you create; an outcome is the problem that you solve with that product. (Nielsen Norman Group, 2016).
For example, for a (business to consumer website (B2C), an output could be a page with video tutorials. The outcome would be customers easily gain the knowledge they need when and where they need it.
Before you start building the output, you need to find out first from the users if this is the information they need and how they are going to use it.
Features vs. benefits
We can also look at output vs outcome as features vs. benefits. A feature is something a product or service offers, whereas a benefit is what customers actually want (Nielsen Norman Group, 2016). The last thing you want to become is a feature factory that no one wants to use. That would definitely be a waste of time and money.
Starting off with fewer but more relevant features will save your user time, which is a huge benefit in times when we’re all busy enough. Saving time obviously helps saving money, since time=money. Finally, a simpler product is often easier to use. This way, you help people to avoid making mistakes. A friction-free experience will be good for your reputation as a company. Because when something is delightful to use, people are more likely to recommend your product or service to others.
A client’s personal taste is not the best start
“Can you please make this more pink, because that’s what I like better”.
One of our personal frustrations are clients that want to make their product look and work according to their personal taste. Or those who think that design is all about making things pretty. But surprise: we’re not building the product for the client, but for their users. Unless the client is the sole user, of course. So designing for the personal taste of the client is a very poor choice. But how to deal with an answer like: “But this is how I want it?”.
Dealing with client resistance
If a client really is not open to your design arguments on how to make the product more useful for the end-users, you may want to reconsider working for them. Because it’s really hard to agree on a choice if there’s no evidence behind it that says that’s the best choice. Also, personal taste is so… personal. And subjective. Liking something or not will hardly help users get to the desired outcome. It is important to continue to remind the client who you are building for and why the choices should appeal to that audience. Asking the client how for example changing color, a font, or a navigation structure will help people to achieve what they want, might start them thinking about this.
Design for all users, not some users
Because what if that color is hard to read by your visitors? Because there are an estimated 300 million people in the world with color vision deficiency (Clintoneye.com). If we count in people with low vision, there are even more users that you are excluding from using your product. If you consider people with temporary low vision, eg. when you visit a digital space on mobile while in the sun, the glare could interfere with a bad choice of color and font size. This is only one example. But not considering the users (what’s best for them) can make the number of people who cannot use your product grow very fast.
“Essentially, 80% of all features developed (deeply and broadly researched)
are rarely or never used. It is too expensive to become a feature factory! “
-Cathi Bosco
Source: Feature adoption report (PDF)
And how to measure success? How do you know if you’ve met their expectations when you design or build something based on output instead of outcomes?
Also: you are not your user. Even as UX experts, we are always surprised how talking to actual users brings us unexpected insights.
Resources for the article
- Design Outputs and Design Outcomes
- Outcomes vs outputs
- Minimize Design Risk by Focusing on Outcomes, not Features