Moving into User Research | Establishing Design Guidelines

By Janet M. Six

Published: June 22, 2009

Send your questions to Ask UXmatters and get answers from some of the top professionals in UX.

We’ll discuss two topics in this edition of Ask UXmatters:

Ask UXmatters answers our readers’ questions about user experience matters. If you want to read our experts’ responses to your question in an upcoming edition of Ask UXmatters, please send your question to: ask.uxmatters@uxmatters.com.

Moving from Technical Writing to User Research

Q: I’m currently working as a technical writer and am interested in a user research career. I was informed that transitioning toward user research without any academic qualifications and experience might be tough, and hence, a better idea would be to progress to information architecture (IA), then transition to a user research role.

I read the Ask UXmatters column “Using Prior Work in Your Portfolio | Moving from MIS to UX.” To answer the question posed in that article—What interests you about this field where you want to apply your background?—I would like to apply my knowledge of IA concepts, user and task analysis, and interviewing skills to help companies create good, functional software products and Web applications that offer great, usable experiences.

I will become a member of the IA Institute soon, and I have started reading the following:

  • The Design of Everyday Things, by Donald Norman
  • Observing the User Experience: A Practitioner’s Guide to User Research, by Mike Kuniavsky
  • Information Architecture for the World Wide Web: Designing Large-Scale Web Sites, by Louis Rosenfeld and Peter Morville

Could you suggest how to progress to an IA role, then to a user research role? Also, what are the probable tools I’d need to use. How should I create sample work to demonstrate my IA knowledge? Would a Certified Usability Analyst (CUA) certification from HFI help?—from a UXmatters reader

The following experts have contributed answers to this question:

  • Mike Byrne—Associate Professor, Department of Psychology, Rice University; Director, Computer-Human Interaction Laboratory, Rice University
  • Pabini Gabriel-Petit—Publisher and Editor in Chief, UXmatters; Principal User Experience Architect at Spirit Softworks; Co-founder and Emeritus Member of Board of Directors, Interaction Design Association (IxDA)
  • Tobias Komischke—Director of User Experience, Infragistics
  • Whitney Quesenbery—Principal Consultant at Whitney Interactive Design; Founder and Past-President, Usability Professionals’ Association (UPA); Fellow, Society for Technical Communications (STC); and UXmatters columnist
  • Janet Six—Principal at Lone Star Interaction Design; UXmatters Managing Editor and columnist

Why Move from Technical Writing to Information Architecture, Then to User Research?

“There are opportunities to move directly from technical writing to user research, as many others have done.”—Pabini Gabriel-Petit

Our experts think someone has given our reader bad advice. “There are opportunities to move directly from technical writing to user research, as many others have done—or to design, as I did myself many years ago,” replies Pabini. “The best technical writers do user research to understand the audience for their documentation, create user profiles or personas, perform task analyses, and do usability testing to ensure that their documentation meets users’ needs. All of these are activities in which a user researcher engages. Thus, as a technical writer, you can start amassing experience in user research and building a portfolio of user research documentation. It sounds like you may already be doing some of this.

“If you’re not already doing all of these things for your current job as a technical writer, try to persuade your management of the value of engaging in these activities. This would enable you to get some of the experience you need to make a transition to user research. It’s not clear from your question whether you want to do generative user research or usability testing, and there are some differences in the kind of background you need to do these two different kinds of user research well. To do generative user research successfully, you need a deeper understanding of product domains, which requires more experience in product development.”

“I’m not convinced that the path from technical writing to user research has to go through information architecture (IA). It could just as easily start with working on usability testing, which is a closer skill set to researcher than IA.”—Whitney Quesenbery

“I’m not convinced that the path from technical writing to user research has to go through information architecture (IA),” contends Whitney. “It could just as easily start with working on usability testing, which is a closer skill set to researcher than IA—not that they don’t all overlap.

“I’d suggest looking for any starting-level job the person could get, as long as it moved them from a job that was strictly writing to one that started to work on early stages of design and development. Frankly, if you are just starting to investigate this move—for example, just starting to read some of the important books—you may not really know what job you will really like and be good at. You could either try to get a job as a generalist, supporting a range of different UX activities, or work on short-term contracts as a specialist in several different fields.”

Whitney continues, “I do think it would be hard to go straight into open-ended user research. If I were going to use the results of a research project to shape the future of my products or services, I’d want the people doing that research to have some experience. I suppose this also depends, in part, on where they live and how many opportunities they have locally.”

“I don’t buy the premise,” argues Tobias. “Why should it be easier to go from technical writing to information architecting than to user research? I generally agree that it is very helpful to have an academic background, but I would think this pertains to IA as well. If you’re a good technical writer, you care about the people who read your documents and try to write for them. Maybe you have talked with your target audience to better understand what aspects of your writing they perceive as good and not so good. I’m oversimplifying here, but that’s pretty much the whole idea of user research.

“I don’t buy the premise. Why should it be easier to go from technical writing to information architecting than to user research?”—Tobias Komischke

“Information architecture is about the right organization and treatment of information,” explains Tobias. “For information architects, user research findings are one essential input. I consider both roles important and demanding—in that the more learned knowledge and practical experience you have, the better you can perform them. But that’s normal, so the real question is this: How can you acquire the right knowledge, and how can you start getting practical experience in the area in which you really want to work—which is user research?

“Learning about user research is the easier part, because it depends on your own effort. There are tons of books out there. You can invest in training or get certificates to improve your resume. My special tip is to read about basic fields like social psychology and ethnography and the methods they use in those fields.

“Getting practical experience is the hard part, because managers may be hesitant to allow you in this new role without being able to refer to a solid track record. I suggest you apply some guerilla tactics and start doing your own user research in your current role—or team up with user researchers you may have in your organization—to optimize your technical documentation. For example, if you’re working on online help, you could ask colleagues, friends, and family to provide feedback. You can investigate the different usage scenarios and user requirements from these folks’ perspectives. Granted, this is not necessarily the ideal way to do user research, but hey, tons of usability testing is done with internal people, too! It is a start that will let you apply the lessons learned from the books. And it generates value for your organization, too!”

“Why make two transitions? If you know you want to move into user research, I would suggest you put all your efforts into moving into user research.”—Janet Six

I agree. Why make two transitions? If you know you want to move into user research, I would suggest you put all your efforts into moving into user research. Please don’t let your lack of academic qualifications stop you. Those merely open doors. It is your excitement and talent for what you do that really make you succeed.

In “Using Prior Work in Your Portfolio | Moving from MIS to UX,” I wrote:

“It is not so much the courses you take, as the expertise you display when you are speaking with a potential client or employer. You need to start building a good portfolio. … It is what is in your mind, not what classes you have taken. You have your own unique gifts. Find them and use them. It is not about fitting in with everyone else…. Find your strengths.”

Pursue what you really want to do. Don’t accept the limitations other people try to impose!

“Since the innovation of highly interactive user assistance in Web applications, user assistance and interaction design have become much more closely coupled,” explains Pabini. “Plus, as a technical writer, you’re intimately acquainted with the interactions users must perform to accomplish their tasks using applications. So, if you do decide to segue through some aspect of designing user interfaces on your way to user research or decide design interests you more than user research, it might make just as much sense to try interaction design. But if you’re sure user research is what you really want to do, go for it! Give it everything you’ve got, because it takes focused effort to overcome the challenges inherent in changing your profession.”

Preparing for a New Profession

“You need some way to show potential employers you are ready for the work you want to do, but academic qualifications are not the only way to do it.”—Whitney Quesenbery

“Obviously, you need some way to show potential employers you are ready for the work you want to do, but academic qualifications are not the only way to do it,” suggests Whitney. “Taking conference tutorials or an academic course is a good way to get the basics—and push yourself to get familiar with current state of the art. Learning involves more than just reading a few books. You need to do a few projects yourself—not only to create some portfolio material, but to find out what you like about the work.”

“Some companies actively facilitate their workers’ making transitions between professions,” offers Pabini, “because they want to keep good people and, to do that, they have to help them grow. For example, when I was at Apple Computer, one group could loan workers to another group to let them get actual work experience in a new profession. Plus, I was able to take courses in human interface design at Apple University.

“You can gain a lot of experience by simply volunteering to do work for which there is a need. User experience groups are often short staffed.”—Pabini Gabriel-Petit

“Even if your company doesn’t provide such programs, you can gain a lot of experience by simply volunteering to do work for which there is a need. User experience groups are often short staffed. If a project you’re working on would benefit from user research, but there is no user researcher on your product team, volunteer to do the work yourself. If there are user researchers on your team, you can volunteer to help them. Perhaps your writing skills are stronger, and a user researcher might welcome your assistance in creating user research documentation or writing usability test scenarios. You can learn a lot by working closely with user researchers and reading the documentation they create. Doing these kinds of projects will let you get the knowledge and work experience you need.”

“Joining various UX associations is good, but active networking is essential,” recommends Whitney. “If you haven’t already joined the major online UX communities, you should do so. It’s a great way to find good resources and listen in on current discussions. For finding your first job, face-to-face networking with local colleagues at meetings and meetups is essential.”

“Most companies want graduate training. We’ve placed undergraduates in non-research jobs, but for research-oriented jobs, generally companies have indicated that they want at least a Master’s degree.”—Mike Byrne

From the academic perspective, Mike Byrne says, “My experience has been that most companies want graduate training. We’ve placed undergraduates in non-research jobs, but for research-oriented jobs, generally companies have indicated that they want at least a Master’s degree. However, I’m not sure of the extent to which this can be offset by work experience—that probably depends a great deal on the organization.”

“While it’s true that employers often ask for graduate degrees for user research roles, an academic degree alone does not fully prepare one to do the work,” explains Pabini. “Having actual, on-the-job experience is so much more valuable than formal academic study alone. That’s why internships are so valuable. Study provides a great foundation, but does not really prepare you for working in a corporate context. There’s so much more to it than just knowing the basics of one’s own profession. Since you’re already working within a corporation, you have the opportunity to learn from your coworkers in other specialties. Nonetheless, you might find becoming a Certified Usability Analyst beneficial.”

Switching Professions

“The biggest catch in career switching is being willing—and able—to take assignments at a slightly lower rate of pay, to gain the experience.”—Whitney Quesenbery

“The biggest catch in career switching is being willing—and able—to take assignments at a slightly lower rate of pay, to gain the experience,” admonishes Whitney. “I don’t advise people to work for free, but I do suggest that they offer an introductory rate. For example, if there is a company in your area that routinely hires people for IA or usability work, offer to do one or two short projects at their entry-level rate, so you can prove to them that you really do bring valuable experience—even if from another field. Then, even if the company is not willing—or able—to bump them up to a better rate, they will have gotten those all-important first few projects onto their resumé. This can make even working for companies with a reputation for treating staff as commodities worthwhile.”

Tobias sums up by saying, “In short, don’t waste time with information architecture if what you’re really passionate about is user research! I’m not saying it’s easy, but one of the nice things about UX is that it’s so inclusive. Most UX professionals I know are career changers. You can be one of them!”

Establishing and Documenting Design Guidelines

Q: What is the best way to set up and document user interface (UI) guidelines?—from a UXmatters reader

The following experts have contributed answers to this question:

  • Mike Byrne—Associate Professor, Department of Psychology, Rice University; Director, Computer-Human Interaction Laboratory, Rice University
  • Pabini Gabriel-Petit—Publisher and Editor in Chief, UXmatters; Principal User Experience Architect at Spirit Softworks; Co-founder and Emeritus Member of Board of Directors, Interaction Design Association (IxDA)
  • Peter Hornsby—Senior Information Architect at Friends Provident; UXmatters columnist
  • Mike Hughes—User Assistance Architect at IBM Internet Security Systems; UXmatters columnist
  • Whitney Quesenbery—Principal Consultant at Whitney Interactive Design; Founder and Past-President, Usability Professionals’ Association (UPA); Fellow, Society for Technical Communications (STC); UXmatters columnist

Your Target Audience

“Remember that the goal is to have designers and developers use the UI guidelines.”—Whitney Quesenbery

“In addition to the sage advice you might get about form, structure, and format… Remember that the goal is to have designers and developers use the UI guidelines,” answers Whitney. “Think about how people work in your company, and how you can make these guidelines useful enough and easy enough to use that they really will be used throughout a project. Documenting guidelines is just one part of what should be a process of creating a shared approach to design.”

“What you document and how you document it must be tailored to your audience. Remember that people work in different ways. Documenting your standards is only half the battle. You need to get buy-in from the organization as well.”—Peter Hornsby

“To give a very UX-y answer: Who are your users?” asks Peter. “What you document and how you document it must be tailored to your audience. Remember that people work in different ways. Documenting your standards is only half the battle. You need to get buy-in from the organization as well.

“Working with your users can give you a double win—helping you to create guidelines in a form that they can use and encouraging your users to buy into using the guidelines—which is, after all, why you are doing the work! You will need to incorporate the guidelines into your own work and make them available to other users in a form they can easily access. Consider referring to them in wireframes and requirements documents, and spend time evangelizing about the guidelines to the rest of the organization.”

“What you want the guidelines to contain will be different for different audiences, so I don’t think there is a best, one-size-fits-all solution.”—Mike Byrne

“I don’t know that there’s a single best way to document UI guidelines,” admits Mike Byrne. “The three I’ve dealt with the most are the Apple Human Interface Guidelines (HIG) from the 1980s, the NASA Human-Systems Integration Standard (HSIS), and Mayhew’s Principles and Guidelines in Software User Interface Design. All of these do some things well and other things less well, but that depends, to some degree, on what the application area is and who the guidelines are written for. For instance, are the guidelines designed to be read by developers to make sure they build things that conform or are they written for UI people running usability studies on prototypes?

“What you want the guidelines to contain will be different for different audiences, so I don’t think there is a best, one-size-fits-all solution. I’d recommend thinking hard about who the target audience is, then looking at a number of sources for guidelines, and adapting them to your specific needs.”

Guidelines Versus Standards

“It is worth considering whether you’re writing guidelines or standards,” advises Peter. “What you call them is likely to have an impact on how your users respond to them.”—Peter Hornsby

“It is worth considering whether you’re writing guidelines or standards,” advises Peter. “What you call them is likely to have an impact on how your users respond to them. A guideline will carry less authority than a standard, but some people may react more favorably to it. It all depends on what you are trying to achieve in your organization and the role that UX currently plays.”

Documenting Guidelines

“Look for ways to present the guidelines—in patterns, personas, sample implementations, and examples—that help your team internalize the core principles and easily look up the details.”—Whitney Quesenbery

“I’d urge you not to over-specify and over-write,” Whitney recommends. “Look for ways to present the guidelines—in patterns, personas, sample implementations, and examples—that help your team internalize the core principles and easily look up the details.”

“Annotated visual examples tend to be well understood by a majority of people,” offers Peter. “But don’t shy away from explaining in clear, concise terms how to do things if more detail is necessary than you can provide in a visual example. Consider breaking the guidelines down into reasonable chunks that refer to one another where appropriate. This will make it easier to maintain your guidelines over time. Using a consistent structure for your guidelines will reduce the learning overhead associated with using them.”

“Establish firm standards for things that need to be and can be tightly controlled. … Use a pattern language to describe design problems and show recommended approaches.”—Mike Hughes

“There are a couple of ways of approaching UI design guidelines that you can effectively blend,” suggests Mike Hughes. “The first is to establish firm standards for things that need to be and can be tightly controlled. Examples are text fonts, screen colors, capitalization rules—headline versus sentence style—stacked labels, which are above the field, or leading edge or trailing edge alignment of non-stacked labels.

“Another useful approach is to use a pattern language to describe design problems and show recommended approaches. The idea of a pattern language was first introduced by the architect Christopher Alexander. He describes a pattern language as a collection of patterns, each of which describes a relationship between (a) a certain context, (b) forces that recur within that context, and (c) spatial configurations that allow these forces to resolve themselves. Eventually, UI designers adopted the use of a pattern language, and there is already a large body of work in this area. Start by seeing if there are existing collections of pattern you can adopt, in much the same way technical writing departments often start their style guides by pointing to the Chicago Manual of Style and saying, ‘Unless we say otherwise, follow it.’”

Pattern Libraries

“Pattern libraries provide good starting points for UI guidelines,” suggested Pabini. Here are links to some of the best pattern libraries and articles on patterns:

Links to patterns contributed by Pabini Gabriel-Petit and Mike Hughes.

UI Guidelines

“You can model your user interface guidelines on the many good examples of guidelines that exist. The following are examples of successful user interface guidelines and include guidelines for desktop operating systems, Web sites, Web applications, and mobile applications,” says Pabini:

Links to guidelines contributed by Pabini Gabriel-Petit and Mike Hughes.

Join the Discussion

Asterisks (*) indicate required information.