by Indi Young
July 28, 2003
It happens again and again. You spend hours in design meetings debating a point, and then a single word from upper management squashes your decision. Or maybe your design debates just go on for weeks because of office politics. How can you streamline this process? By deriving your conclusions from research instead of just “experience.”
Everyone has an opinion about design. If your debate is based only on opinions, the person with the most power always wins. Almost always. The team that has rational support for its conclusion can trump power and opinion. User research can give you concrete proof that one direction is better than another.
Follow these four steps to keep office politics out of your design. Conducting research the right way (remember what you learned in high school science class) will help you build a better case, and better software.
Earning respect and trust is the first step toward winning a design debate. To gain trust, you must remain objective. Gathering data without influencing it with your own hopes or organizational biases is important. Your peers will need to see that data does exist to support your conclusions. Before they believe your results, they’ll have to believe that you conducted your research scientifically.
If you’re not sure how to conduct interviews or proctor usability tests without influencing the data you gather, review time-tested techniques. Adaptive Path Partner Mike Kuniavsky goes into depth about data-gathering techniques in his new book, Observing the User Experience. Christina Wodtke talks about effective interviewing in her book, Information Architecture: Blueprints for the Web. We also teach objective techniques in our Beyond Usability tutorials.
When you sort through your data looking for conclusions, you must first clear your head. You don’t want to let your own mental model guide the structure you create out of the data. Most analysis consists of searching transcripts or videos for patterns. These patterns may represent common mistakes, perceptions, or ways of doing something. Some data may not fall into the pattern, but will remain an outlier. Do not force anything to fit a mold, but let the data form its own picture.
Conclusions differ depending upon the type of research you are conducting. For example, usability research will produce lists of how users have trouble using a product. Task analysis will produce a mental model. Card sorting will produce topical groupings. The patterns should represent more than you previously foresaw. Your peers will see new combinations of ideas and know that it is the data speaking. These new combinations will add respect for the scientific roots of the entire data set.
From your conclusions, you can now derive recommendations.
Extenuating circumstances can start to creep in at this point. The senior engineer might point out, “An extra dialog box will make the user read and understand what they are about to do.” The head of consulting may say, “I don’t care what the mental model says, we earn 60 percent of this company’s revenue, so we should be in the universal navigation.”
Often, guiding this person through your derivation process will convince her or him of the validity of your conclusions. Sometimes, business needs will override the user’s mental model. You will need to judge the difference, and be flexible when necessary.
A decision derived from research and validated by team members is much less open to contention after the fact. Once you’ve decided on recommendations, review the data with your team-and management, if you can. Show them how you came to those conclusions.
Working objectively, it will be easier to process your coworkers’ perspectives. It will also be easier for them to accept some of your recommendations.
Follow these four steps, and you’ll rarely have to worry about falling behind when someone with more clout has a different opinion.
Objective, research-based solutions will get your team working together smoothly, and you’ll finally be able to avoid frustrating second-guessing from management and peers.
Indi Young is a founding partner and practive lead at Adaptive Path. She specializes in task analysis and making navigation understandable, useful, and reliable.
Published by Adaptive Path | 363 Brannan St. | San Francisco, CA 94107 | 1-415-495-8270 | http://adaptivepath.com/