STC Usability SIG Newsletter
Usability Interface

Seize the Day
Taking Our Place as Owners of the User Interface

By Jennifer Atkinson

Sophia Marx, Lisa Braz, Lea Wolseley, and I presented a session at STC’s 48^th Annual Conference in Chicago. The session, “Seize the Day: Taking Our Place as Owners of the User Interface,” addressed why and how to take responsibility for the user interface (UI). We also gathered information with a web-based survey asking other technical communicators how they face this issue.

When we started working on this presentation, the four of us spent a fair amount of time debating the use of the term “owner” in the title. After all:

• We’re not the ones coding the user interface.
• We’re not continuously working with customers to understand their needs and how we can meet them through the intelligent design of our product.
• Many of us may not have any formal education in user interface design. So how can we talk about owning the user interface?

In an imperfect world of trade-offs and compromises, we know this: part of our job is to function as user advocates. Most of the time, we don’t have professional UI designers, or a Human Factors department, or any one person looking at the user interface as a whole. So lacking those resources, who else is better suited to be looking out for our users?

Do not march into your next team meeting and announce, “Move over. I’m taking over the UI.” Instead, approach your responsibilities with a new sense of ownership. And we’ll tell you how.

One participant in our survey put it very well. This person said:

Technical communication is about analyzing audiences and their tasks. Good user interface design does the same thing. It builds UIs based on the audiences and the tasks they must perform. We are a natural fit to develop, test, and maintain UIs. The more information we can communicate through the UI, the less our audiences need additional information such as books, web sites, and so on. We, as technical communicators, have to turn our attention to building better UIs, so that we can evolve and rely less on typical books as documentation.

About the survey

We developed the survey to give us a taste of how other technical communicators were facing the problem of improving the user interface of their products. Sophia created the survey by using the tools at Zoomerang.com, who hosted the survey. We invited technical communicators to take the survey during February of this year. Seventy participants from the United States, Europe, Canada, Australia, and Israel participated. Sophia reported the following data:

The participants were fairly evenly divided by size of company: 20 percent from small companies (11–99 employees), 33 percent from medium companies (100–1,000 employees), 20 percent from large companies (1,000–5,000 employees), and 24 percent from behemoth companies (more than 10,000 employees). The average background of the participants indicated they contribute occasionally to user interface design and that the engineering department actually owns the user interface.

Two other interesting tidbits that we discovered in our survey concerned the participants’ view of the barriers to good UI design, and identifying existing software release priorities.

Top barriers to good UI design include:

• Project schedules that do not allow the time necessary for good UI design
• Management for whom good UI design is not a priority
• Lack of appropriate skills
• Lack of UI standards that made it difficult to create consistent UIs

We asked participants to identify the existing priorities for a software project. Their responses included on-time completion of projects and software with good performance that is full featured, and that ships with fewer, rather than more, bugs.

Obviously, creating a product with a usable interface isn’t near the top of the list. So, knowing that it’s generally not a priority helps you prepare your strategy. It’s clear that putting good UI design on the priority list is going to be important to your success.

Working with developers

Lea interviewed a number of developers to gather tips on how to work with them to relinquish some responsibility for the user interface. First, she said you need to be careful about using the term “owner.” She found it put developers on the defensive from the moment she used the term. The rest of the tips included:

Provide input on the UI early in the development cycle. It’s a lot easier to change GUI items early rather than late, when they’re worried about reducing the bug count before the product ships.

When you provide feedback, explain the rule that dictates the right answer. Most developers want to know the rules, so they can do it right next time. If the feedback is just a suggestion and not really an implementation of a rule, tell them.

When you provide feedback, come prepared with a solution. Don’t just sit back and criticize.

The developers were mixed on whether they wanted the writers to initiate the feedback or whether the writers should wait for the developers to ask for help. However, as practitioners, we found that developers started asking for feedback after we had the initiative to start providing suggestions.

Know the development tools and environment. It will make a difference if your suggestion to change a label on a button means merely updating the label in an externalized string file, or if it means finding all hardcoded occurrences in legacy files and laboriously updating each string.

Finally, start small and build on small successes. It can help developers change their habits if they see for themselves the value of your contribution.

Working with writers

Lisa, as a documentation director and manager, knows that it can be intimidating for writers to step up to owning the user interface. She listed the following challenges for writers:

• Writers don’t have enough time to do their regular job, let along add more tasks like UI design.
• Writers aren’t always confident they can improve the UI.
• A good UI may not be a priority for the company, so why work hard to fix something that doesn’t pay off for you internally?

Here are some tips on how to face those challenges:

Writers don’t have enough time

If you’re a manager, you have several options: make UI design a part of the writers’ job description; plan for participation by putting it in the project plan and allocating time; understand that by being involved early, the writers will save time later.

If you’re a writer, here are some of your options: talk with your manager about making this one of your goals; volunteer to get involved with the UI whenever possible; encourage developers to ask you questions whenever they need help.

Writers aren’t confident they can improve the UI

To boost confidence and be more prepared, consider the following suggestions:

• Attending classes on UI design.
• Preparing a list of recommended books, articles, and web sites (see the list in our handout, available at the STC web site).
• Building a relationship with the human factors department, if you have one.
• Working with other writers on your suggestions before sharing them with developers.

Good UI is not a priority for your company

If your company doesn’t value the effort or time you need to expend in order to improve the UI, consider one or more of these options:

• Educate your peers, other managers, and their managers about the value of good UI.
• Work on incorporating UI feedback as part of the typical development process.
• Try to make the UI feedback as painless as possible.

Working with other groups

We found that 39 percent of our survey participants had a person or a department in their company who functioned as a human factors group. During our presentation at the STC conference, we also asked how many people used to have human factors people, but then lost them in a layoff. A number of people in the audience raised their hands, as did one of the speakers. So any thoughts on how to work with a human factors group needs to be in the context of understanding their possibly tenuous role in the company.

One of the biggest advantages of a human factors group is that they define the interface standards:

• Use the standards like you use a style guide.
• Recognize that consistency in interface design is a significant goal. Put aside efforts to improve just one area if it means that it will be inconsistent with other areas.
• Create a poster of the UI standards, and distribute it as widely as possible.

We know that, when human factors departments exist, they don’t usually have the luxury of a lot of time to provide all the services you probably want.

It’s important to understand that human factors departments offer a whole menu of services, such as:

• UI standards, as described earlier.
• Usability audit, where they go through each part of the GUI and offer feedback on how well the product is meeting the users’ needs. This is an ideal activity if you want to limit the scope of the effort.
• Usability testing, where the human factors people design tests (with your help), recruit test subjects, administer the tests, and summarize results in a report.
• Voice of the customer, where they meet with customers, show them low-fidelity prototypes, and generally get inside the heads of the customers. The human factors people can return to the company and serve as the voice of the customer.

Of course, other allies exist within the company besides human factors departments. For example:

• QA or Verification: recruit them to write a detailed checklist that assesses compliance with the standards.
• Customer support: when they code a call, is "Poor usability" one of the options? You can also find a support person with a lot of internal credibility and invite them to provide feedback on early prototypes.

For more information

You can find our presentation slides, handouts, and survey results at the STC web site at www.stc.org/48thConf/48th_post.html (the session is listed under the name Sophia Marx). You can contact any of us by e-mail:

• Jennifer Atkinson, jennifer.atkinson@peregrine.com
• Lea Wolseley, lea.wolseley@peregrine.com
• Lisa Braz, lbraz@broadvision.com
• Sophia Marx, sophia.marx@chordiant.com