The Role of Technical Communication in User-Centered Design
Incorporating usability techniques. Focusing on the user. Influencing others to design a more usable product. These continue to be frequent topics in our industry publications and conference sessions. Many of us have incorporated user-centered design (UCD) techniques into our documentation lifecycles but still find ourselves initiating grass-root efforts to ensure that our developers and engineers do the same. What a struggle it is to document unusable products. That’s why I was so thrilled when asked to manage our small team of user experience (UX) designers.
Two years ago this function was just starting up again at CheckFree after falling victim to the previous economic downturn. And this time around I was going to lead the team. What a great combination to have under one manager: technical communicators and UX designers, two teams with a common goal of making life easier for our end-user. Managing both teams, however, has been a challenging experience. I want to share with you the lessons I’ve learned so far: how to integrate technical communicators into the UCD process and how to prepare for the management challenges as you do.
One of the first things I did as the new UX manager was to identify the roles necessary to support the UCD process and determine whether we had the expertise in-house to fill those roles. On the UX team, we decided to outsource our usability testing due to resource constraints. On the Technical Communication team, we adjusted job responsibilities to enable those with information design skills to focus on user interface (UI)-centric projects and work closely with the UX designers. The following tables display the roles and deliverables for both the UX and Tech Comm teams.
In Jesse James Garrett’s essay “The Nine Pillars of Successful Web Teams,” he defines UCD as “…understanding what your users need, how they think, and how they behave-and incorporating that understanding into every aspect of your process.” The CheckFree UCD process includes four phases of design, each of which lends itself to Tech Comm involvement.
The purpose of the analysis phase is to understand users and their needs. This phase enables UX designers to collaborate with key business and product stakeholders to review high-level business requirements and lead the effort to define user profiles and scenarios.
Currently, Tech Comm is not directly involved in this phase. We use the UX deliverables created during this phase to make educated decisions about the informational needs of the end-users. In the future, Tech Comm should be participating in ongoing user research and doing some of our own, with a focus on the user and task analyses of our information deliverables.
Conceptual design phase
The purpose of the conceptual design phase is to brainstorm design concepts, test the concepts with users, and iterate the design. This phase enables UX designers to go through their creative process, brainstorming design ideas to support the business requirements, and iterating their early designs based on user feedback.
Currently, Tech Comm involvement in this phase is low. We participated in one early usability test as observers. In the future, Tech Comm should be brainstorming design concepts for user assistance access points on the UI. Collaborating with the UX designers during this phase will increase the chances of securing space on the UI for more than just the traditional help link, opening up opportunities for techniques such as embedded help or advanced search features.
Detailed design phase
The purpose of the detailed design phase is to add the final level of detail and complexity to the design concepts, test the detailed design with users, and iterate the design. This phase enables UX designers to work out all the details of their final design. Currently, Tech Comm involvement in design begins during this phase with the following tasks and deliverables:
Tech Comm reviews the UX wireframe deliverable before it is distributed to the larger project team. The information designer edits the wireframes for consistent use of terminology and labels, striving for consistency both within the UI and across all information deliverables for the product. The information designer also responds to UX recommendations for the location of instructional text throughout the UI and often negotiates with the UX designer for additional text locations.
UI instructional text
Tech Comm and UX collaborate on the UI instructional text. UX drafts the first version of the text in the wireframes and assigns a TCOM ID to each text segment. Tech Comm edits the placeholder text, focusing on content, tone, and style to maintain consistency across all information deliverables. The information designer then works with the visual designer to integrate the text into the UI design and delivers the final text, organized by TCOM ID, to the developers to copy into their code.
Assistive technology text
Our product was designed to conform to Section 508 of the Americans with Disabilities Act. To support this design, Tech Comm writes all of the text that a screen reader would read aloud to vision-impaired users. This text includes descriptions for most elements on the user interface, including graphics, tables and their contents, and navigation points. Tech Comm delivers the final text to the developers to copy into their code.
Informational messages/error messages
Tech Comm and UX collaborate on the informational and error messages displayed on the UI. UX drafts the first version of the messages to communicate the intent, and Tech Comm edits the text to create the final version. Tech Comm then delivers an XML file of messages to the developers. We need to continue to improve our process for this deliverable. Developers are still occasionally writing their own messages, using existing messages from past product versions, and creating duplicate messages.
Usability test participation
Usability tests offer a great opportunity for Tech Comm to participate in the design process. Over the course of the past year and seven tests later, Tech Comm has done everything from simply observing the test in progress, logging the test subjects’ actions and comments, and participating in break-out sessions after each test, to attending recap meetings a day after each test. Most of the usability tests over the past year have focused on the product, not on Tech Comm deliverables. However, through observing test subjects perform tasks, we were able to gain valuable feedback on the UI instructional text, user affinity to clicking help links, and UI terminology and button labels. For one of the first usability tests early in the redesign of our product, Tech Comm also created a terminology survey for users to take before the test in an attempt to settle some hot debates among project stakeholders. Unfortunately, the survey did not give us conclusive results.
Implementation and deployment phase
The purpose of the implementation and deployment phase is to support the UI design through the product development lifecycle, test the actual product with users, and prepare for future versions of the product. The UX designers take on a support role, answering questions as developers work through their technical design and coding phases, and as the quality assurance analysts write their test plans and test the code.
Currently, Tech Comm creates most of its traditional deliverables during this phase, including online help and print documentation. The information designer also continues to support the design, often updating design deliverables to accommodate changes coming from the coding and testing phases of the product development lifecycle. Tech Comm struggles with resource constraints during this phase, juggling deliverable deadlines for the current product with design responsibilities for the next version of the product. In the future, Tech Comm should assign dedicated design resources to help support the overlapping product release cycles and make a list of enhancements for future versions of the information deliverables.
Managing the Tech Comm and UX teams through our new UCD process did not come without its challenges. Here are four areas that required my management focus throughout the course of the project and my lessons learned for each area.
- Watch out for turf battles between the writers and designers. While portions of the writer and designer skill sets are different, portions are also very much the same. I’ve been on some projects where the roles worked well together and the resulting synergy was strong. On other projects, the skill-set overlaps caused problems. And when they clash, they clash with force!
- Clearly define roles and responsibilities on each team for each project; don’t assume that the skill sets will always blend. For example, during one phase of the project we had problems with the Tech Comm information designer and a UX information architect both reviewing UI labels and terminology. During another phase of the project, the UX team had a difficult time reaching consensus when multiple designers were working in parallel on different parts of the UI.
- Appoint escalation points and decision makers to bring an end to debates. The ultimate solution to design debates is to test different options with actual users. Unfortunately, project timing does not always allow for this to happen when a decision is needed. There should be a decision-maker backup plan.
Team identity, cohesiveness, and support
- Facilitate the creation of both separate and joint team visions. Tech Comm and UX teams need to create their own identities and have time to both vent and brainstorm within their own teams. Equally important is the need for these teams to join together to create a single vision that focuses on the user.
- Help the Tech Comm and UX teams recognize their similarities and differences to achieve mutual respect. One area of focus should be with their skill sets. Also consider exploring communication styles, working styles, and conflict resolution styles. Designers and writers often approach project situations differently; if they understand their style differences, they can learn how to better relate to each other.
- Find and sustain at least one champion in senior management for Tech Comm and UX. Both professions share the reality of having to prove their value from time to time, especially when management changes result in new team members who are not familiar with what we do.
Technical communication expertise
- Spend time as a writing team identifying the differences in writing styles for each deliverable. We often focus on the differences between writing for the printed page versus online help. In addition, we need to consider effective writing styles for UI informational messages, error messages, instructional text, and text written especially for tools supporting product accessibility.
- Continue to market your Tech Comm team’s ability to write for the UI, and be prepared for opposition. Some will still think of technical writers as those who write long, wordy manuals. Arguments you may encounter include: too much UI text makes the product look more complex than it is, a well-designed UI shouldn’t need instructional text, and too much UI text detracts from the visual design. Focus your responses on differences in user learning styles and usability test results that show places where users were confused about what to do next.
Process and resource management
- Define multiple processes to address different resource scenarios. First of all, make sure to define a process. Lack of process quickly translates into lack of trust from project team members, especially those wary of Tech Comm and UX functions to begin with. Once you have a default process defined, consider variations on that process based on project complexity and Tech Comm and UX resource availability.
- Assign dedicated Tech Comm resources to participate in design. This may be hard to do, especially in the beginning when the team is not prepared to lose the writing time of one of the writers. However, depending on the product release cycle, it can be too much work for the same Tech Comm resource to participate in both the design and development phases of the project. For example, we had to add extra resources to our project after realizing that one writer could not meet online help deadlines for the current product version while working on design deadlines for the next product version.
The UCD process I’ve described reflects the adjustments we’ve made after 18 intense months and three product versions. The process has come a long way, but there is still plenty of room for improvement. Fortunately, the project team has embraced the concept of UCD and recognizes its benefits after seeing the redesigned product. The Tech Comm and UX teams are also working together better after surviving earlier struggles. In the spirit of UCD, we will continue to iterate our process until we settle on a solution that enables us to produce high-quality deliverables in a timely manner while still meeting our common goal of making life easier for the end-user. In the meantime, my technical communicators are integrated in the UCD process and making valuable contributions.
About the Author