Label Alignment in Long Forms | Paper Prototyping for Engineers

Ask UXmatters

Get expert answers

A column by Janet M. Six
January 18, 2010
Sponsor Advertisement
Continue Reading…

Label Alignment in Long Forms

Q: I am producing a very long data-entry form that is at least 3000 pixels in height. It does not require users to complete all fields. However, it is likely that users would complete all fields. I cannot choose to place the labels above the input fields, because this would double the height of each field. Therefore, I need to use a layout with labels on the left. However, if I chose to make the labels right aligned, it would be very hard to scan down the form—both because of the size of the form and the number of fields it has. As a result, I am choosing a left-aligned approach. Do you think this is appropriate, or do you believe, regardless of the form size and number of fields, that I should align the labels on the right if they are to the left of the input fields?—Paul Wallas

The following experts have contributed answers to this question:

  • Pabini Gabriel-Petit—Publisher and Editor in Chief, UXmatters; Principal User Experience Architect at Spirit Softworks; Founding Director, Interaction Design Association (IxDA); and UXmatters columnist
  • Michael Griffith—User Experience Director at Hewlett-Packard
  • Caroline Jarrett—Owner and Director at Effortmark Limited
  • Tobias Komischke—Director of User Experience at Infragistics
  • Whitney Quesenbery—Principal Consultant at Whitney Interactive Design; Past-President, Usability Professionals’ Association (UPA); Fellow, Society for Technical Communications (STC); and UXmatters columnist
  • Jim Ross—Principal of Design Research at Electronic Ink and UXmatters columnist
  • Paul Sherman—Principal at Sherman Group User Experience; Vice President of Usability Professionals’ Association; and UXmatters Columnist

Caroline Jarrett, who is co-author with Gerry Gaffney of Forms that Work: Designing Web Forms for Usability, answers: “I know one of the most popular articles on UXmatters is Matteo Penzo’s article ‘Label Placement in Forms,’ in which he advised placing labels above fields. However, he focused on the time it took for users’ eyes to jump about as they read a form. While this can be important for very short, trivial forms such as the ones he described in his article, it is not particularly important for any other type of form. The sheer length of a form—both visually and in terms of the effort completing it requires—is really important. Your idea of using left-aligned labels would, as you point out, make it easier to scan the labels—a task that is unnecessary for a short, trivial form, but is often very important for a long form. It would also reduce the visual length of the form and probably make it seem a bit less daunting.”

Pabini relates how Matteo’s article came about and shares her thoughts about its conclusions: “I asked Matteo to undertake his eyetracking study and write the article ‘Label Placement in Forms’ for UXmatters, because the UX Design team with which I was then working as a consultant was embroiled in an endless debate on the topic of label alignment in forms. Over many years, this has been a recurring debate at many companies, as well as in online discussions, so I wanted to see some definitive data.

“When I first read Matteo’s article, I made a similar observation to Caroline’s: His conclusions emphasized the rapid completion of forms, which is really important for short forms comprising familiar data—such as forms for signing in or providing personal contact information. However, I don’t believe our sole goal in designing most forms is their rapid completion. This is often an important goal, but in some cases, you might actually want users to take a moment to consider some of the information they’re providing in a form. For all forms—especially long forms—easy comprehension by users, layouts users can easily scan, and ensuring users are willing to complete a form are also key design goals. (More on this later.)”

“I don’t think the length of a form really makes that much difference,” counters Whitney, “as long as all of the questions in a form ask for information users are likely to expect to—and be willing to—fill out.”

Some General Guidelines for Labels in Forms

“What you should always try to avoid is having very different label lengths in the same form,” states Tobias. “For example, if one label is a whole sentence, but another is only one word, that results in an unattractive visual layout, as the example in Figure 1 shows. This is especially true when short labels are at the beginning of a form, requiring some effort on the part of users to locate the first indented field.”

Figure 1—An example form with very different label lengths
Form with different label lengths

“Make every effort to use labels of approximately the same length,” agrees Pabini. “If you’re able to use labels having similar lengths, the decision regarding whether to place a label above or to the left of a field, using left alignment or right alignment, diminishes in importance. Regardless of the labels’ placement, they’ll consistently be more closely coupled with their field visually.

“Also, avoid labels for text boxes or drop-down lists that wrap onto multiple lines. To prevent labels’ wrapping, try shortening them—conciseness is a virtue. But be sure to allot sufficient width for them. If your labels are long, examine whether you are trying to accomplish too much with them. Rather than using a long label, you could provide interactive user assistance to the right of fields. Your layout of labels in relation to their fields should be consistent—though there’s one exception: scrolling text boxes require greater width, so their labels are usually above them.

“Tobias’s example of how not to design a form, shown in Figure 1, presents an interesting problem, begging for a solution. I’d revise his example form as follows, creating labels of relatively uniform length:

  • Move Last name and First name to the top of the form and invert their order—or better, provide a single Name text box.
  • Change the cryptic label DOB to Birth date.
  • Move Gender above Age, so all fields relating to a person’s birth would appear together.
  • Add a Birthplace group label above separate City and State text boxes—thus, limiting the length of their labels without losing clarity. Or better, have a single Birthplace text box, with interactive user assistance to the right of the field that presents the following tip: City and state—for example, Princeton, NJ.
  • Change Country you have your primary residence in, which isn’t even good English, to Country, with the following interactive user assistance to the right of the field: Location of your primary residence. However, putting Country in close proximity to Birthplace gives me pause, because users might assume the field is related to Birthplace. (I have a hard time believing this particular combination of form fields would occur in real life.) An alternative would be to use the label Residence or Primary residence—which is clearer, but overly long in comparison to the other labels—with Country or Country in which you reside in interactive user assistance to the right of the field. This label would be a bit obscure, but the field’s overall structure would be parallel with that of the previous field.
  • Add more vertical space between the fields.”

Label Alignment

Now, let’s get to the crux of the matter. Where should you place the labels for fields?

  • to the left of fields AND
    • left aligned OR
    • right aligned
  • above fields and left-aligned

Left-Aligned Labels to the Left: Pros and Cons

Caroline recommends left alignment for field labels to the left: “Your form is long, so the chances are that some of its questions are relatively complicated, some of the users’ answers might require more research, or you might need to justify some questions and explain how your organization intends to use their answers. In any of these situations, you’ll usually need longer questions—and those don’t look good and are hard to read when they are right aligned.”

Pabini disagrees with Caroline’s conclusion: “While Caroline’s reasoning about the instances in which a form needs to provide more information to users is cogent, I don’t agree that these situations justify using longer labels. In my mind, very little would. Instead, I see these as justifications for providing interactive user assistance to the right of form fields.

“Even assuming a designer absolutely cannot bring label lengths into relative conformity, there are still a few circumstances in which left-aligned labels for fields might be appropriate—particularly where users’ need to scan a form is paramount. For example, in a long, familiar form for a data-entry professional who usually needs to fill out only a few fields or in an edit view of a long form in which a user would likely be modifying only a few fields, scanning becomes very important.

“Left-aligned labels can be very hard to read, especially when their length varies, because users’ eyes can accidentally jump to the wrong row in a form when moving between labels and fields. This is most likely to occur when fields have insufficient space between them. However, I think the need to visually couple labels with their distant fields is the primary reason for the typically long duration of saccades with left-aligned labels—approximately 500ms (milliseconds)—that Matteo noted in his article. In general, I’d recommend that you not use left-aligned labels, except where users typically need to scan forms. However, if you do, make sure the labels are of a uniform length and relatively short.

“You haven’t mentioned the audience for your form, but for a consumer application,” Pabini continues, “I wouldn’t use left-aligned labels in a long, unfamiliar input form, requesting data that may be difficult to provide, because users must read—or at least skim—the entire form to know what to fill out and what they can skip over. Right-aligned labels are usually preferable for consumer applications.”

Right-Aligned Labels to the Left: Pros and Cons

“You should use right-aligned labels,” asserts Jim. “People do not scan down a form in the same way they scan a regular list of items. When filling out a form, people usually tab from one field to the next, focusing on one field at a time. This is especially true when they are going to fill out all or most of the fields in the form.

“Eyetracking studies of form-label placement—see Matteo Penzo’s ‘Label Placement in Forms’—have shown that right-aligned labels require shorter eye movements than left-aligned labels. Users first focus their attention on a form field, then their eyes travel to the left to read its label. Right-aligned labels require the eyes to travel shorter distances to view both the form field and the label.”

“With right-aligned labels, each label and its field are always in close proximity to one another,” adds Pabini, “so if labels are very short, users’ eyes can sometimes take in both a label and its field in one fixation. Plus, users’ eyes are not likely to jump to the wrong row in a form, as can happen with distant left-aligned labels when fields have insufficient vertical space between them.

“When I looked at Matteo’s data, I noted that there was not a great difference between the time it took to complete a form with labels above fields—with 50ms saccades—versus a form with right-aligned labels to the left of form fields—with 170ms saccades. His data and analysis validated to me that my standard practice of using right-aligned labels for longer forms is, indeed, correct.

“Aligning labels to the right is popular for short, trivial forms where all the questions are simple, the answers are easily available in users’ heads, and there are no concerns about how an organization might use their answers,” says Caroline.

Choosing Between Left- or Right-Aligned Labels

“Label placement is an epic topic, and there are good reasons for both right-aligned and left-aligned labels,” affirms Tobias. “Let’s assume, for now, that a form’s fields are left-aligned. Eyetracking studies on menus have shown that users can scan items faster if they’re left aligned, because their eyes can follow a straight path from top to bottom. But with data-entry forms, there are not only items below other items, but also the fields that are associated with labels. That makes things somewhat more complicated. We’re talking about a 2-column grid structure, consisting of an unspecified number of rows.

“So, it comes down to this question: What is more important?

  1. To be able to quickly scan the list of labels? This would call for left-aligned labels.
  2. To be able to quickly grasp what field belongs to a label? This would call for right-aligned labels.

“There is an ISO (International Organization for Standardization) standard just for data-entry forms: ISO 9241-17:1998, ‘Ergonomic requirements for office work with visual display terminals (VDTs)—Part 17: Form filling dialogues.’ This standard says that, as a rule, labels should be right aligned. It also says that, in case the labels have similar lengths, you can left align them. See Figure 2 for an example.

Figure 2—An example comparing left and right alignment in the same form
Comparing left and right alignment in the same form

“Their overall goal seems to be to move labels and fields closer together, so they’d answer the above question by choosing the second option. That does make sense to me, because bringing labels and fields close to each other makes it easier to connect both. Plus, since the gaps between them have pretty much the same width throughout the form, the negative space between labels and fields creates its own gestalt, making it easier to visually understand the 2-column structure of the form and to anticipate the location of its elements.

“I would even argue—and this goes a little bit against the premise of the first answer to the question I posed earlier—that the ragged-left border resulting from right-aligned labels helps users to understand and anticipate the items they need to fill in, similar to the way a pattern of ascenders—bdf—and descenders—gjp—creates the typical shape for a specific word.”

“I suggest mocking up both versions in simple HTML, doing some hallway tests, using your design sense, and picking whichever solution both looks better and performs better,” advises Paul. “All design guidelines are made to be broken. That’s how design advances and evolves.”

Whitney agrees with Caroline and recommends “aligning labels on the left, so they are easy to scan.” But she concedes that “this topic has been debated many times. The conclusion seems to be that it does not make as much difference as the energy we expend upon it. We have to base part of our decision on the overall layout of the form and the length of the labels. However, the other consideration is whether the people using the form are likely to need to read all of the labels, so they can find the fields they want to complete. If so, laying out the form for easy scanning makes the most sense.”

“As with so many design decisions, the answer to the question of label alignment is: It depends. Though even after analyzing the same data,” Pabini observes, “not all experts come to the same conclusion. So, the debate rages on!”

Labels Above and Left Aligned: Pros and Cons

“Matteo’s eyetracking study proved conclusively that placing labels above form fields is optimal in short forms, because they are very closely coupled visually with their fields and users can take in both with a single fixation,” acknowledged Pabini. “I often place labels above fields in dialog boxes and other short forms, especially when asking users to provide familiar data. Plus, when localizing a user interface is necessary, placing labels above fields eliminates the layout problems that can occur when translations result in much longer labels. However, I don’t think placing labels above fields is optimal for long forms. In such a form, there are likely to be group labels above closely related fields. In such an information hierarchy, placing form fields to the left provides a clearer distinction between the two levels of labels.”

“I don’t think you should rule out placing the labels above the form fields,” recommends Jim. “Even though this would increase the length of the page, it is easier for people to complete a form with labels above the fields. Eyetracking studies show that labels above fields require the least amount of eye movement. Often, people can see a form field and read its label with only one fixation, thus completing the form is less time.”

Other Factors in the Usability of Long Forms

Pabini explores some other factors in the design of forms: “As I mentioned earlier, there are some other factors that are key to the usability of forms—especially for long forms—including the following:

  • easy comprehension by users
  • layouts users can easily scan
  • ensuring users are willing to complete a form”

Easy Comprehension by Users

“To help users better comprehend form fields,” explains Pabini, “do the following:

  • Provide clear, concise labels that use plain language.
  • Use terminology that is familiar to your users.
  • Use consistent styling for labels—for example, sentence capitalization and bold text.
  • Where appropriate, use text box sizes that indicate the length of the data a user should provide.
  • Clearly indicate whether fields are optional or required.
  • Provide interactive, inline user assistance, including
    • tips
    • validation”

Layouts Users Can Easily Scan

“When users don’t need to complete all of the fields in a long form, they must be able to easily scan the form to determine what fields they should complete,” continues Pabini. “To make it easy to scan a long form, do the following:

  • Use labels of a fairly consistent length.
  • Place required fields near the beginning of a form.
  • Ensure all required fields are visible.
  • Effectively chunk form fields into groups.
  • Provide clear group labels.”

Ensuring Users Are Willing to Complete a Form

“As Caroline mentioned earlier, it’s important to make long forms seem less daunting,” concludes Pabini. “Achieving this goes a long way toward ensuring users are willing to complete your forms. However, label placement plays a only small part in achieving this goal. Some more important things you can do to help people successfully complete long forms include the following:

  • Ask for only essential information. Doing so may let you shorten a long form and engenders trust. Avoid asking users for information they’ve already provided elsewhere, but if you do, at least prefill those fields with users’ data.
  • Organize a form’s fields into groups. Providing this kind of structure to forms helps users get an overview of a form.
  • Use progressive disclosure. Place related fields that are not required and may not always be relevant in groups that expand only once a user selects an option—indicating that they are relevant.
  • Provide helpful user assistance. When requesting information users might have to look up, ensure they know in advance what information they’ll need. Provide interactive user assistance to focus users’ attention on the information they’ll need to successfully complete the current field.
  • Prevent errors.
    • Provide default values. Providing helpful default values both reduces the effort of completing a form and is an effective means of preventing errors.
    • Provide inline validation. As users complete a form, let them know whether they have successfully filled out each field. Doing so nips errors in the bud.”

Motivating Form Completion Over Time

Michael observes, “Your statement that your form ‘does not require users to complete all fields. However, it is likely that users would complete all fields’ is curious! I have yet to meet users who enjoy filling out optional form fields. If your Web site or application is one that people will visit often, consider collecting any optional information across multiple visits. Later on—perhaps after their fourth visit—when users sign in, present them with a message that asks in a polite way whether they would be willing to provide more information, so you can provide better service to them. Give users a short explanation of how you’ll use the additional information to improve their experience. If they decline, do not ask again. The most important thing to remember is that, once you have gained users’ trust, they will be more willing to share information, and the information they share will be of higher quality. uses a similar technique, motivating users with a goal: Your profile is 80% complete, add education to reach 85%.” 

References on Designing Web Forms

Our experts recommend the following resources on Web form design:

International Organization for Standardization. “ISO 9241-17:1998, Ergonomic requirements for office work with visual display terminals (VDTs)—Part 17: Form filling dialogues.” International Organization for Standardization, 1998. Retrieved December 23, 2009.

Jarrett, Caroline. “Caroline’s Corner: Label Placement in Forms.” UsabilityNews, November 3, 2006. Retrieved December 23, 2009.

—— “Label Placement in Forms—What’s Best?PDF Proceedings of the 22nd British HCI Group Annual Conference, 2008. Retrieved December 23, 2009.

—— and Gerry Gaffney. Forms that Work: Designing Web Forms for Usability. San Francisco: Morgan Kaufmann, 2008.

Penzo, Matteo. “Label Placement in Forms.” UXmatters, July 12, 2006. Retrieved December 23, 2009.

Tan, Chui Chui “Web Form Design Guidelines: An Eyetracking Study.” Cxpartners, April 27, 2009. Retrieved January 8, 2010.

Wroblewski, Luke. “Inline Validation in Web Forms.” A List Apart, September 1, 2009. Retrieved January 8, 2010.

—— “Web Application Form Design.” Functioning Form. Retrieved January 8, 2010.

—— Web Form Design: Filling in the Blanks. Brooklyn, New York: Rosenfeld Media, 2008.

Paper Prototyping for Engineers

Q: I am a classically trained engineer and am now getting ready to use paper prototyping for the first time. My company usually focuses on the technical parts of our products and thinks of usability only toward the end of a project timeline, if at all. Paper prototyping can us give an inexpensive way to improve our products and, hopefully, will instill a sense of the importance of involving user experience early on future projects. The product we’re currently developing is for users who are highly trained, technically oriented employees in the network-support domain. Do you have any tips for me?—from a UXmatters reader

The following experts have contributed answers to this question:

  • Pabini Gabriel-Petit—Publisher and Editor in Chief, UXmatters; Principal User Experience Architect at Spirit Softworks; Founding Director, Interaction Design Association (IxDA); and UXmatters columnist
  • Mike Hughes—User Assistance Architect at IBM Internet Security Systems and UXmatters columnist
  • Caroline Jarrett—Owner and Director at Effortmark Limited
  • Whitney Quesenbery—Principal Consultant at Whitney Interactive Design; Past-President, Usability Professionals’ Association (UPA); Fellow, Society for Technical Communications (STC); and UXmatters columnist
  • Jim Ross—Principal of Design Research at Electronic Ink and UXmatters columnist
  • Paul Sherman—Principal at Sherman Group User Experience; Vice President of Usability Professionals’ Association; and UXmatters Columnist
  • Janet Six—Principal at Lone Star Interaction Design; UXmatters Managing Editor and columnist

Our UXmatters experts have offered both encouragement and some very useful tips on doing paper prototyping. I say good for you for wanting to involve User Experience earlier in your project timelines. The benefits of integrating usability test results into design are greater then. When they are applied at the end of a project, it’s like putting a Band-Aid on a broken arm.

“Hurrah for you,” exclaims Whitney. “I’ll bet your networking applications are complicated—not the sorts of tools you can fix as you go. So, hurrah for getting users involved with the design early. Not only will this let you design a better user experience, you may even find that the users have good design ideas. I assume you have read Carolyn Snyder’s excellent book, Paper Prototyping—or some of the many articles on the subject on the Web.” “There are many fine resources for learning more about paper prototyping,” says Paul, “and I’m sure a quick search on the Web will provide you with the top resources.” Caroline suggests, “Definitely run, don’t walk, to your nearest bookshop or preferred online book vendor and get Carolyn Snyder’s excellent book.”

Jim also recommends Paper Prototyping: “It’s the best book for practical tips on how to conduct your usability testing with paper prototypes. It also covers the basic principles of usability testing. You can create your paper prototypes at various levels of fidelity—from hand drawings to images you’ve created in a graphics program, then printed out. In addition to creating screens, you can create menus and other user interface elements, then cut them out and place them on top of a page to simulate changes that occur on a screen. For example, you can simulate opening a menu in response to a participant’s click.”

“Our experts all agree that Paper Prototyping is the definitive reference on conducting usability testing with paper prototypes,” says Pabini. “We’ve published some excellent content about paper prototyping on UXmatters, including the following:

  • Book Review: Paper Prototyping’—Read my very detailed review of Carolyn Snyder’s book, which provides a synopsis of the book’s main points. My book review covers creating a paper prototype, planning a usability study with a paper prototype, designing tasks for a usability study, preparing and refining a paper prototype, facilitating a usability test, conducting a usability study with a paper prototype, and deciding whether to use a paper prototype. As I said in my review, the companion Web site for Paper Prototyping ‘provides a rich trove of resources for paper prototypers, including PDF versions of templates, forms, checklists, handouts, and procedures from the book; links to Web sites where you can obtain the supplies you need to create paper prototypes; and an extensive list of references, including articles, papers, and books.’
  • Conference Review: UIE Web App Summit 2007: Part III’—As a developer, you might find Sean Kane’s comments on paper prototyping interesting. My review of his talk, ‘Building a Great User Interface, the Netflix Way,’ includes a diagram that shows where paper prototyping fits in the development lifecycle. At the time he gave this talk, Sean was Director of User Interface Engineering at Netflix.
  • Innovation Workshops: Facilitating Product Innovation’—Jim Nieters discusses the creation and testing of paper prototypes during innovation workshops.
  • When Role Playing Doesn’t Work: Seven Guidelines for Grounding Usability Testing in Participants’ Real Lives’—Isabelle Peyrichoux provides a case study about testing a feature using a paper prototype.

“Other books that provide useful information about paper prototyping include Effective Prototyping for Software Makers, by Jonathan Arnowitz, Michael Arent, and Nevin Berger, and Todd Warfel’s new book Prototyping: A Practitioner’s Guide. Both books include a chapter on paper prototyping.”

Some Tips for Conducting Usability Tests with Paper Prototypes

“My advice is more attuned to the social, organizational, and political context,” explains Paul. “I strongly recommend having your stakeholders observe usability testing if possible. If you have the equipment, it would be great to push live video of the test sessions to them, either via a Webcam or a camcorder attached to a TV or monitor in the next room. The reason I recommend this is because watching users interact with the prototype helps your team achieve alignment and a shared vision about how to improve the design. It’s all too easy to dismiss or discount the findings from usability testing when you haven’t watched the test sessions. But once your team watches them, they become actively engaged in the process. The magic of usability testing isn’t in the testing, it’s actually in the watching.”

“It may be that your company perceives usability as being user friendly or some other soft attribute,” suggests Caroline. “Try to focus on hard numbers. Your target audience is very technical and, therefore, expensive to employ. If you can save them time, you’ll have a winning product. Look for numbers such as time on task, time to learn an unfamiliar task, and error rates. You can measure all of these for a paper prototype in the same way you would measure them for an interactive prototype.”

“Identify the most critical use cases and plan several quick testing iterations around those,” advises Mike Hughes. “Arrange for users to come in the morning for three days in a row. During the first morning, test your prototype with two or three users, then make any necessary changes to the prototype in the afternoon. The next morning, test your revised prototype with new users. At the end, wrap up your findings and do a walkthrough of the paper prototype on video—that can be your design specification.”

“Conduct tests with an assistant who plays the part of the computer,” suggests Jim. “Have this person represent the computer by simulating the actions of a user interface in response to the participants’ actions. For example, the person playing the role of the computer might overlay paper drop-down menus or change to new screens in response to a participant’s clicks.

“Playing the role of the computer can be very difficult, because it requires knowing exactly which part of the paper user interface to lay down in response to each participant action. Keeping track of all the paper pieces during a session can be very demanding. So don’t try to do that yourself. It is difficult enough to facilitate the session, observe, and take notes without also trying to play the role of the computer. Be sure to run through a few practice sessions so you and the ‘computer’ can become familiar with the process.”

Jim also offered this recommendation for working with paper itself: “To ensure that your prototype lasts over several testing sessions, you may want to create your prototype on card stock and have it laminated. Paper can get bent, ripped, and smudged over the course of several sessions. More durable prototypes are easier to handle and keep fresh.”

Working with Engineers

Since you are working with highly technical developers and users, it is important to frame your use of paper prototyping in technical terms. If the use of personas is not too uncomfortable for your development team, use them. Some of your colleagues might expect that a usable product is one with a cute interface. They should know that well-documented studies have shown that good design for both a product’s front end and back end can significantly improve performance, reduce maintenance, and even reduce the time it takes to develop a product. I, too, am a classically trained computer scientist. I do the following when introducing the concepts of user experience to a group of technical professionals:

  • I start with a quick story of a UX nightmare—like the story of the dishwasher in “Multiple Mistakes Drown Interface.” This helps connect the developers to their personal bad experiences with products and always compels them to share their own UX nightmares. Often, I have to stop the string of stories so we can get on to the technicalities of improving user experience. Right away, I am able to make a connection with the developers that motivates them to integrate better UX design into their projects.
  • Then, I immediately show how the designers might have improved the UX design in the case of my nightmare story. I specifically point out how minor changes could have made huge improvements. This is important, because many engineers have no training in user experience and might expect all good UX design to be beyond the capability of their domain. Some engineers might even need what I call untraining, to overcome what they’ve learned from certain collegiate engineering programs that actually mock the importance of good user experience. Be sure you know the right solution to the nightmare design. Since you are new to UX design, don’t try to come up with this solution on the fly. Of course, I expect you already know that your colleagues will grill you with questions. You need to know the answers and be confident of your facts.
  • Next, I show some data. Engineers always love to see numbers. I often briefly introduce the Goals, Operators, Methods, and Selection Rules (GOMS) model to them, then explain how to derive a number showing how good the improved design is in comparison to the nightmare design. It is crucial that you provide data that demonstrates why UX design and usability are important to your company. Otherwise, you may lose the support of part of your product team. Of course, you might lose some of their support anyway, because UX design and usability are foreign to many of them.

At this point, you can create a paper prototype of your design. Be sure that you follow good design principals, and avoid the temptation to just move the paper around without any specific justification. Act with purpose and tie your changes back to your data. I recommend Ben Shneiderman’s Designing the User Interface as a good place for classically trained engineers or computer scientists to learn the basic principles of good UX design—particularly, his ‘Eight Golden Rules of Interface Design.’ You do not have to make complicated changes at this early stage in your adoption of paper prototyping. You can make huge impacts with some very focused changes.

As an engineer, you have the distinct advantages of being able to speak to other developers in their own language and understanding the specific obstacles they face in their work. Good luck with your paper prototyping! 

References on Paper Prototyping

Kieras, David E. “GOMS Models: An Approach to Rapid Usability Evaluation.” Electrical Engineering and Computer Science Department, University of Michigan. Retrieved December 23, 2009.

Arnowitz, Jonathan, Michael Arent, and Nevin Berger. Effective Prototyping for Software Makers. San Francisco: Morgan Kaufmann, 2007.

Gabriel-Petit, Pabini. “Book Review: Paper Prototyping.” UXmatters, May 8, 2006. Retrieved January 6, 2009.

—— “Conference Review: UIE Web App Summit 2007: Part III.” UXmatters, March 6, 2007. Retrieved January 6, 2009.

Nieters, Jim. “Innovation Workshops: Facilitating Product Innovation.” UXmatters, June 22, 2009. Retrieved January 6, 2009.

Peyrichoux, Isabelle. “When Role Playing Doesn’t Work: Seven Guidelines for Grounding Usability Testing in Participants’ Real Lives.” UXmatters, September, 2008. Retrieved January 6, 2009.

Shneiderman, Ben, and Catherine Plaisant. Designing the User Interface: Strategies for Effective Human-Computer Interaction. 5th Edition. Reading, MA: Addison-Wesley, 2009.

Snyder, Carolyn. Paper Prototyping: The Fast and Easy Way to Design and Refine User Interfaces. San Francisco: Morgan Kaufmann, 2003.

Tognazzini, Bruce. “Multiple Mistakes Drown Interface.” AskTog, June 2003. Retrieved December 23, 2009.

Warfel, Todd. Prototyping: A Practitioner’s Guide. Brooklyn, New York: Rosenfeld Media, 2009.

Principal at Lone Star Interaction Design

Dallas/Fort Worth, Texas, USA

Janet M. SixAs Principal of Lone Star Interaction Design in Dallas, Texas, Dr. Janet M. Six helps companies design easier-to-use products within their financial, time, and technical constraints. For her research in information visualization, Janet was awarded the University of Texas at Dallas Jonsson School of Engineering Computer Science Dissertation of the Year Award. She was also awarded the prestigious IEEE Dallas Section 2003 Outstanding Young Engineer Award. Her work has appeared in the Journal of Graph Algorithms and Applications and the Kluwer International Series in Engineering and Computer Science. The proceedings of conferences on Graph Drawing, Information Visualization, and Algorithm Engineering and Experiments have also included the results of her research. Janet is the Managing Editor of UXmatters.  Read More

Other Columns by Janet M. Six

Other Articles on Web Form Design

New on UXmatters