Ever notice how often a product that makes a huge splash at tradeshows fizzles in the marketplace? The story goes like this: Product is introduced at show to much fanfare. News media gives Product lots of press, and consumers everywhere express interest in Product's features and capabilities. Product hits store shelves…and stays there. Some early adopters purchase Product, but it never penetrates into mass consumer markets.
What went wrong? Market research clearly identified potential dollars in target markets just waiting to spend money on the new product. So why did it fail?
The problem is not with the market research, which is a necessary first step to rolling out a new product. Rather, the culprit is an absence of a true understanding of the people who will ultimately use the product. Just as important as market research, design research is a necessary ingredient for creating, developing, and delivering a successful product. Marketers need solid market research to guide their decisions about product positioning, revenue potential, and target markets. Likewise, designers need solid design research to guide their decisions about the product's interaction framework, feature set, and overall appropriateness for its users.
A design research phase consists of three main activities: stakeholder interviews, domain research, and user interviews. Some combination of all three makes for a successful phase. The length of each activity depends on the complexity of the product. More is always better, but effective design research can be gathered in a relatively short amount of time. Typically, one to three weeks is sufficient for most business and domain products, while complex enterprise systems with multiple interfaces require a longer research period.
An intimate understanding of user research is fundamental for designers. In order to gain such an understanding of the research, designers must lead—or at least participate in—user interviews. Simply handing them a report generated by someone else is not nearly as effective. If the design team is truly immersed in the user research and models that come out of that research, it will be much easier for them to design a product that meets the needs of the users rather than themselves.
It is vital that the people who will be designing your product have a good understanding of the company's specific goals for it. Is the product going to be positioned as a major revenue generator? What kind of development resources will be assigned to the project? Are there existing brand guidelines that will have an impact on the visual design of the product? What is the deadline for code drop and customer ship?
Don't assume, even within your organization, that your design team understands your corporate vision. Often, the product vision is diluted as it moves up and down the corporate hierarchy. Sometimes, a product vision is not well articulated to begin with, but is rather a collection of good ideas with vague requirements. Discovering this at the beginning of an initiative can save a lot of grief later. If your company does not have a clear idea of what they want to build and sell, you will never be able to design a product that meets expectations.
Domain research activities focus on the big picture of the product space. The design team should perform competitive research to identify existing products and services that may solve similar problems or offer complimentary features. For technical products (complex enterprise products or specialized domains, such as for medical devices or healthcare products), identify a subject matter expert (SME) whom you can use as a resource throughout the project. To immerse yourself in the basics of the product domain, spend at least an hour or two with this person before conducting user interviews. This will give the design team an overall understanding of the common terminology and vocabulary used in the industry or consumer space and provide a good forum for asking naïve questions before embarrassing yourself in front of real users. Just the other day I baffled and was baffled by a client as we both used the term “engineer” in a conversation. It turns out that he meant “sound engineer” when he used the term, and I meant “developer.” Once we cleared up the confusion, I was able to use the term appropriately and save myself and those around me a lot of confusion in the future.
Understanding common terminology and practices not only builds credibility (try saying, “disk drive” instead of “volume” to a roomful of IT storage professionals, and see what kind of reaction you get), but it also minimizes confusion. When it comes time to design, being able to provide solutions to customers in familiar language eases the learning adjustments they have to make.
User interviews represent the most important element in design research. An ethnographic approach in gathering user research is particularly effective. Ethnography is a social research technique based on studying people's behavior in everyday contexts, rather than under controlled conditions (such as a conference room in a focus group testing center). Ethnographic techniques focus on informal conversation and observing the subjects in their environments, instead of on questionnaires or set lists of topics. This approach will allow you to be efficient while unearthing the true attitudes and behaviors of users, as opposed to merely gathering statistics.
These ethnographic techniques provide quick, rich results. As a designer, your goal is not to create an exhaustive research report; therefore, you will be invariably less scientific than an ethnographic anthropologist or social science researcher would be. Rather, your goal is to understand users enough to be able to step into their shoes during the design process. While your experience and expertise with interaction design will provide for a foundation of good interface concepts, it is your understanding of users that will help you make appropriate design decisions for the product at hand. Otherwise, you're just creating design based largely on what you know and like. Unless you happen to be representative of the core target markets for the product, and unless you happen to have no quirky behaviors or processes that skew your perception of the problems being solved, the product won't meet the needs and goals of the people who will actually use it.
For example, I was on a team that recently completed a design project for an irrigation management tool aimed at golf course superintendents. We traveled to several courses around the country to talk with superintendents and their staff. It was valuable to watch each superintendent guide us through the current software tools they use to control their course's irrigation systems. More valuable, though, was the time we spent away from the computer. We rode around the course in golf carts as the superintendents performed some of their routine activities, and we were able to observe many behaviors that never would have come out of a meeting in their offices. We had heard, for example, that superintendents take a lot of notes as they travel around the course (they told us this themselves, in fact). In reality, though, the notebook mostly stayed in the back of the cart, and when a problem came up, the superintendent would either fix it on the spot or radio someone else to fix it right away.
Later, when we were designing the interaction framework for the product, we were able to quickly make decisions about how much data capture—or in this case, how little—was needed in the interface. Without those golf cart trips, we may have spent a lot of time designing an expensive-to-build feature that would not have added much value to the design.
Why do companies skip design research?
I hear this statement a lot from executives, and there is no doubt that they have enormous amounts of expertise and experience with their product domain. But does a CEO of a large CRM Company really know what today's telemarketers and customer support agents want to do with the product's call-center module? Even with consumer products, it's dangerous to assume knowledge of the individuals within the target market.
This is a common concern shared by many consumer product companies. How does one do user research for a cell phone, when anyone in the world is a potential user?
Sure, it's not possible to quickly profile every possible type of user. That does not mean, though, that there is no point in trying to understand any users at all. Knowing some users very well is better than not knowing any of them. Remember, design research and user modeling are first and foremost design tools. As your design team is faced with making decisions about what features to include in a product, and how to present those features to users, having intimate knowledge about at least one or two types of users will help them lean one way or the other. If they don't have any design research to draw on, they will be left only to their instincts, individual experiences, and design principles.
It's possible to target users who are representative of a large number of other users. The targets will often span multiple marketing segments. Interviewing some of these representative users and knowing them well makes it unnecessary to interview others in the groups they represent.
Don't worry so much about knowing every kind of user before the first release. As the product matures, keep adding to your knowledge store about your customers and make adjustments accordingly. Don't eliminate the process because it seems too big to swallow whole.
Avoid focusing on the "lowest-common-denominator" user, that is, the one who potentially represents the users with the least amount of technical skill, money, and motivation to buy your product. Focus somewhere in the middle; there is more chance that the users to the left and right of that user will also be pleased with your solution.
The key to having designers internalize and use design research is to let them participate in or, better yet, perform the research. Splitting up the design team from the research team can easily create a conflict of interest. The goal of a dedicated research team is to create a report that will probably be used for multiple purposes. The research itself is the end goal.
When designers perform design research, it is not the research but the product design that is the end goal. Designers constantly anticipate design questions, and as they perform research, it's always with an eye towards how it can help them create a solid design in later phases of the process. They may ignore or miss entirely some research opportunities, not because they are uninteresting or not valuable, but because they don't relate directly to the design task. This helps them remain focused and can greatly reduce the amount of time needed to do the research. Since the research itself isn't the sole objective, designers can be more selective and take more risks.
Other advantages to having the designers participate in or lead research is that they can't help but internalize the information they discover. Seeing first-hand the raw material that is used to create the user and domain models makes it easier to apply and believe in those models during the design phases.
While this is a legitimate concern, the research techniques discussed here yield rich, accurate results in brief periods of time. An ethnographic research approach and a small number of user interviews can provide the foundation for a quick and successful design research phase. In addition, the time you spend up front understanding users and the domain will save time during the design and development process by reducing guesswork, re-work, and exploration down blind alleys. Knowledge is power, and empowering your design team with knowledge about your business goals, your technical boundaries, and your users will provide an extra edge in ensuring that your product isn't the one gathering dust on the shelf after the tradeshow.