Job Sculpting: Writer to Interaction Designer

CIDM

August 2002


Job Sculpting: Writer to Interaction Designer


CIDMIconNewsletter Jennifer Square, Interaction Designer, Nationwide Insurance

Many technical writers will relate to my story. I was a technical communicator caught at the end of the development process and spent a lot of time writing about a confusing user interface or constructing training materials to help users learn and navigate through their systems. I spent about three years writing software documentation, training materials, and release communications for users before I made a career change. This article is about how I made this career change, but I would like to call it: How I “job sculpted” my way into a new role.1

The manuals and other training materials I wrote were usually for either transactional-based mainframe systems or Web-based applications. The users were not programmers but people in service centers or agencies. They had to use these systems every day to accomplish their work: answering customer service phone calls. After burying myself in a mass of quick reference cards, online documentation, and paper manuals, I began to think there had to be a better way.

In my research, I read articles about writers contributing to the user interface, but none of these articles offered any advice on how I could change our interface design process so I could contribute to it. Even if I had time to contribute to the process, I was often not consulted at the right time or even in the right way. My help was usually requested after-the-fact and on a spare-time basis. Most of the time, my proposed changes to the user experience were more complex than could be implemented in the development timeframes.

How Are You Going to Respond?

I was giving a presentation about the division of roles in technical writing at the 2000 STC conference in Orlando and at the end, someone came up to my co-presenter and suggested that we read Alan Cooper’s The Inmates are Running the Asylum (Sams, 1999). We started as soon as we returned home and found that Cooper calls upon technical writers and other professionals to move into interaction design to improve the user experience. This field was more than user interface design. Cooper explains that

Interaction designers work from the outside in, starting from the goals the user is trying to achieve, with an eye toward the broader goals of the business, the capability of the technology, and the component tasks. Requires thinking about software behavior, concepts, and lastly in terms of the user interface. Determines where the concrete is poured as much as it determines which fabric will be most appropriate for the windows. (page 23)

He defines interaction design in relation to user interface design:

“Interface” suggests you have code over here, and people over there, and an interface that passes in between them. It implies the interface is the only thing the user needs. Interface design is only a secondary role-much like packaging in retail. (page 23)

Cooper ends with this question for readers: How are you going to respond? His book provided fuel for ideas. Moving from writer to interaction designer was the best thing I could do for users. It was a better and more efficient use of my time. I began to construct a proposal for fitting me into a role of interaction design. I wrote a three-page proposal outlining my plans for the job, where I would fit in, what processes I would follow, sample screen prints of our current systems, and my proposed redesigns. I sent it to the five decision-makers in my office and waited. Two of them responded with interest!

My interviews began. I chose to work with our systems team, which was devoted to rolling out a Web interface to replace a mainframe system. This Web interface was one of the systems I had spent the most time with on documentation and training projects.

New Roles and Faces

In April 2001, I started my new job by planting myself in the midst of all the programming work. Admittedly, I was a bit scared because I really didn’t have any programming experience, and suddenly, I didn’t have any tangible deliverables, and nobody was calling anymore for copies of quick reference cards.

My first meeting about a new proposed Web page brought me in contact with a programmer who changed the way I thought about programmers and programming. At first, my impressions of him were everything Cooper describes in his book or I had experienced with other programmers: confident and outspoken. He seemed to be very opinionated about the way things should be done, and I walked out of the meeting wondering if I had the strength to deal with the demands of this new role.

For a few weeks, we worked on the Web page with our team and spent time dealing with people’s different opinions about how a button should look or the way a font appears on-screen. I began to think that I wouldn’t be able to handle many more discussions about whether buttons should be yellow or blue. Was this job really for me?

The Bigger Picture

Our discussions needed to move past colors and buttons and immediate deliverables and on to how we could create a goal-directed and task-based user experience. One afternoon, I sent the programmer an email telling him we needed a new direction. We needed to create a Web-based application that allowed for more than 200 user tasks and 35 system rules and concepts. Upon reading the email, the programmer came to my desk; we started to talk about where we wanted to go in the future.

Until then, our team had only a faint idea of where we were going: replacing the frontend of the mainframe system on the Web. As Cooper warned, we could have been quickly swept up into adding more and more features and growing complexity with each release. Just because it was going on the Web didn’t mean using the system was going to be any easier. Where was our plan for how the tasks would appear to the user in the integrated user interface? The question lingered: How are we going to do this? As far as I knew, not much work had been done on the process or looking at all the tasks users do in their daily lives. That’s where technical communicators have expertise; that’s where most writers spend their time. Cooper suggests that technical communicators are perfect for this type of position, “Experience in technical support or documentation provides designers with perspective in thinking about user’s needs.” (page 235)

I believe my email started a key relationship with the programmer. Through our talks, I found that he was everything Cooper had described but more. I learned that his passion and strong opinions were not a bad thing. I could deal with them if it meant an improved user experience. He was concerned about the users, usability, and design. He was eager to try new ideas and challenge himself to learn new programming techniques that would make our user interaction easier. He supported looking at the bigger picture because it meant his team of programmers could avoid costly rework every time we needed to add a new feature. Every user interaction designer needs to have a programmer who can support or challenge her in terms of new ideas and paradigms, especially if she does not have technical skills or programming experience.

Dancing Bear

Many people didn’t understand my new role or the processes of design and usability. We decided to create a “lunch and learn” presentation to help clear the confusion. It included a combination of Alan Cooper’s and Don Norman’s research in usability and design and JoAnn Hackos’s research on task analysis. We titled it “Dancing Bear,” using the term Cooper introduces in his book.

According to Cooper, a Dancing Bear is a drearily hard-to-use product whose sole virtue is delivering features unavailable anywhere else. It begins when a company adds features and more features without fitting them into a larger, longer-term plan. The product ends up filled with mismatched parts and random features. Our presentation included a plan for how we would avoid creating our own Dancing Bear. We created prototypes of our bigger picture that gave ideas about what our system would look like if we had every featured released. What would the user experience be?

The programmer and I gave this presentation first to managers and interested parties. After the initial presentation, we were asked to present to our entire office, which included everyone from the Vice President to the interns-a total of ten presentations before the year was out. The processes and concepts were subsequently endorsed and encouraged by our management, which was key to making progress for our users.

Post Dancing Bear

As Margaret Wheatley suggests in her book, Leadership and the New Science (Berrett-Koehler Publishers, 2001), the goal state or vision is not a destination. Instead, it drives the work we are doing today. After the presentations ended, the programmer and the rest of our team started the hard work of analyzing our release deliverables and assessing where each would fall in terms of that bigger picture. It included looking at our applications and tasks and making sure to plan for connection points with other systems that our users need, not just ours. That’s where we are now, making sure our deliverables fit into the bigger picture of where we need to go and then delivering.

The Design Team

The technical publications industry must be aware of the convergence of many professions in usability and design. At the 2002 STC conference in Nashville, Whitney Quesenberry, Lou Rosenfeld, and Ginny Redish talked about how several different fields are merging. Technical writers, trainers, process designers, and programmers claim that they too can contribute to the user interface design process. Some of these people may not be formally trained, certified, or educated in usability and design, but they are being assertive in their opinions and suggestions. At the same time, there are the usability and design professionals who have certificates and degrees in their fields and can add value to the process. How does one compete or contribute?

Recently I have become an organizational coach to work with our usability and design team. This team was originally working on usability and design for our external Internet site. Now organizational coaches have been established with this group so that the usability and design team can also help with development of internal Web applications and processes.

An organizational coach working with the design team is an excellent model for a lone interaction designer. The benefits of this process are that all the nit-picky details (what graphics to use, what colors to use, and so on) of the user interface design and process can be taken care of with the design team’s meticulous interface standards and guidelines. An interaction designer should be involved in the process from the beginning when the requirements are written. When working with another design team, the designer will have a few more eyes and ears involved in the process. User interface design professionals should take care of the look-and-feel requirements and establish formal design processes. They may also help with conducting usability testing.

As Cooper and Norman suggest, this organizational model will work only if the interaction designer knows the product, starts the design process at the beginning, and understands the specific needs of the users and the characteristics of the application. That means that interaction designers will spend a lot of time with users. My lesson for interaction designers: Leave the colors up to the artists. Have them set the standards, and then limit the color discussions with your team. It’s so much easier.

Your goal as an interaction designer should be to consult, create, and learn about the user’s working environment and how tasks and processes are accomplished and participate in user reviews and usability testing. Create prototypes before coding begins. Keep asking about the bigger picture and plan for it. Dabble in some technology or learn how graphics are created. At the same time, you’re not a Photoshop Jockey. Your team should not come to you for graphics creation.

Lessons Learned

Our paradigm as technical communicators needs to change radically. Talk to any group of technical communicators, and many will claim they are user advocates. Ask them to describe the extent of their advocacy and if users really notice their work. They may have relabeled a menu item or added some instructional text in the user interface, but to what degree are they really changing the user’s experience? Can they really contribute effectively between writing manuals, compiling online help, and spending time with users? To be effective in my area, I needed to devote my entire time to the interaction design job and change processes. I face enough multi-tasking and challenge just with one job role.

We need to close the knowing-doing gap. Many of us read books or attend seminars on various topics related to our profession. We could each have read Cooper’s book, but how many of us will act? Steve Maguire, author of Debugging the Development Process (Microsoft Press, 1994), states, “Why spend years of learning by trial and error when I can pick up a good book and in a few days achieve insights that took someone else decades to formulate? If team members read just six insightful books a year, imagine how that could influence their work.” (page 117) However, it’s not just reading the material or attending a class that produces results and real change; we need action. We know what to do, but what’s our call to action? As Cooper asks: How will you respond? CIDMIconNewsletter

About the Author

BPAugust02a3

Footnotes

1. I have taken the term job sculpted from the article, “Job Sculpting: The Art of Retaining Your Best People” by James Waldroop and Timothy Butler (Harvard Business Review, September 1999). A PDF is available for download at <www.hbr.com>.

We use cookies to monitor the traffic on this web site in order to provide the best experience possible. By continuing to use this site you are consenting to this practice. | Close