Build It So They Will Return

“Build it, they may or may not come. But if they do come and you haven’t built it right, they almost certainly won’t come back” — Anonymous

Often times we hear designers or developers say, “But I thought the user would find this feature very cool” or “Since we can do this, I thought it would be a nice add-on.” And chances are that this may trigger a much larger conversation and argument on who is right, who is wrong, and what could be “cool” for the user. Sound familiar? Situations like this are not uncommon in the technology domain. In fact they are so common that we brush it off with a casual air and perhaps see no fault in this approach to discussing our designs.

On evaluating the above instance, a few things become clear. The designer is designing for himself or herself with no evidence that the user will find the same feature so “cool.” Guesswork and intuition are driving design conversations and the design process has become feature-centric rather than user-centered. The result is unsuccessful products with all the features that the design team wants, but that have little or no relevance to the user. So the question is: How do you design a product that will work for others and not just for you?

Using the “define and design” approach

I remember from my personal experience with the advertising industry that every marketing or advertising brief I wrote started with a problem statement followed by a definition of the target audience the problem is addressing, as well as other key information. When the brief was complete and passed off to the creative people, not only did it give them a complete picture of the problem, it also provided them with enough contextual information to empathize with their target audience and produce effective responses. Thus, almost every business solution or creative strategy evolved out of a powerful problem statement and the understanding of its target audience.

The same need for contextual information applies to product designers and developers. We need several critical pieces of information at the start of a project to get started and keep the process on track. We need answers to questions such as:

• What is the company’s business goal?
• Who is the target audience?
• What are their current needs?
• What is their current work practice?
• How will the product address their needs and support their work practice?

The answers to these questions and others like them will provide good direction for the design teams. As tempting as it might sound, it is however not recommended that designers go on a design spree before they actually have all of these questions answered.

Recently more and more companies are realizing the value of this approach as it not only saves them time and money, but also helps them to get it right for their users the first time.

Understanding user needs

Abraham Maslow’s pyramid of human needs provides good insight, even for designers, into understanding the evolution of human needs. Maslow’s theory advocates that the appearance of one need usually rests on the prior satisfaction of another, more important, more basic, yet more powerful need. As a person’s low-level needs are met, he or she moves up the hierarchy of needs. These principles can be applied to product design.

Products need to fulfill some basic user need before he or she can move from one level of product usage to the next. There is no point shipping your product with a zillion and one features and functions that address high-level needs without supporting to the low-level needs of basic functionality. Many products fall into the trap of providing more than the required features and functions and fail miserably when it comes to providing the basics that score high on users’ lists. This situation raises an important and valid question of how to identify user needs in order to prioritize them in a way that is of value the designers.

Knowing users is not the same as understanding their needs

Sometimes you come across people in your company who, when presented with user data, are in complete denial either because it is in total contrast with their beliefs or the data does not appeal to them and what they want to do. These people tend to think they know their customers well because they go on customer visits that involve talking to the customers in conference rooms, asking them questions about their work, needs, and likes and dislikes.

What they don’t understand is that although data obtained from such visits is potentially marketing data, it is too abstract and incomplete to be good design data. This kind of data generates a feature list, but it doesn’t paint an accurate or complete picture of the user’s work. Just knowing the users doesn’t necessarily translate to understanding their work practice and needs.

Think work practice, think user needs — not features

The best way to understand the users and their needs is by observing them while they are at work. Simple as it may sound, the skill of observing and understanding the users and their needs is complex. It is not as straightforward as just asking the users what they need. By doing so you can never elicit an appropriate response from them.

Why, you ask? Users seldom think in terms of needs and as such can’t tell you what they need. Some of them may not even be aware that they have needs. They accept certain product flaws and shortfalls as the norm and create workarounds to fulfill their task goals. Also, we have to understand that the users take everything that occurs in their workplace for granted and don’t remember every detail of their tasks.

For example, one company we’ve worked with was convinced that it needed many more ways to search for information, allowing the users to construct searches to target information based on a multitude of fields. These fields were in the source data, so the company assumed that users would want to filter search results by them. They were convinced that more search capability would answer the oft-heard user complaint “I can’t find what I’m looking for, give me better searching.” But In observing their users at work, the company discovered that customers couldn’t find what they were looking for because the search result display was unclear; users couldn’t figure out what documents were being found. No amount of additional search capability, relevancy ranking, other features that would be higher up on the pyramid would resolve their more basic need: “tell me what I’m looking at in ways I can understand.”

When users are interviewed in settings outside of their natural work environment such as conference rooms, labs, user conferences, or focus groups it is not possible to see all the breakdowns in their work or know the intents behind why they do things in certain way. Instead, what you might then end up getting from them is an incoherent feature list that doesn’t give you any insight into how those features will actually support their work. You also don’t get to see the aspects that break the work practice which translate to user needs.

It is imperative that, as designers, we learn to think in terms of work practice-it is the breakdowns and the flow in user work practice that helps designers understand the users’ needs. This forms the basis for building a conceptual design.