Catalyst 2: User Experience (Overlooked)

by Tom Johnson on Apr 21, 2010
categories: beginners

We didn't have a very good support model for the application. It became clear that our service desk, which included mostly BYU students working part-time and supporting over 100 different applications, couldn't answer questions that users had. They would only escalate the questions to us. And not many of our customers trusted the support desk anyway. Eventually the project manager started forwarding customer questions to me. I became the go-to person to support the application.

At first I resisted this, because after all, I wasn't a support desk agent. It was a little demeaning. Customer Support had always been a separate department in other places I worked. But I figured that since I could update the help on the fly, I would just either point users to answers in the help or add to the help until the help was complete and answered every possible question users could have. It would give me good feedback about questions users would have, so that I could write better help.

But as I started talking more and more with the customers, and even observing them in the computer classrooms where I also gave training, a funny thing started to happen. I started to see how users actually used the application. In my training sessions, I would give them a list of tasks to perform, and then I would watch them. It wasn't so much training as a massive usability lab. I would see users try to click certain buttons because of the interface text, and I would see them go to the wrong screens. I would ask them to explain why they did something. They provided abundant feedback.

Suddenly when we gathered together in project meetings, I was no longer the guy who was just writing the help files. I had tapped into the user experience in a way that the interaction designers hadn't. I knew how the users thought, how they acted. My close personal interactions with them allowed me to understand users better than anyone else on the entire project team. I even started to offer a few training sessions with the real intent of measuring usability. I would give a 15 minute overview to users on how to use the application, and then give then 10-20 tasks to perform. I just moved about the room watching users try to complete the tasks.

Because of this user knowledge, I became a key player in decisions about design. I was often included with the other core leaders on the team -- the quality assurance lead, the project manager, the interaction designer -- in key decision-making meetings about the application. When the interaction designer would present an application screen, I would look at it and say, users don't understand that term. Users are getting lost here. Users keep clicking this button and thinking that it sends the item there, when in fact it sends it here. Users have a different workflow and process for this, and so on.

The project manager had a motto of NIHITO, meaning nothing important happens in the office, and so he often accompanied me in the classroom training where he could interact with the users as well. After a session where he could look over the shoulders of users as they moved through the application, he said the interaction designer (IxD) should definitely be there so he could see for himself how his designs were being followed. The IxD never made it to any of the sessions I led, unfortunately.

The more training and customer support I gave, the more valuable it made me on the project team. I was no longer just documenting what is. I was instead defining what should be. I became an influence in the shaping of the prototypes for future releases. And often when the project manager and the interaction designer were at loggerheads on a design, the project manager would say, let's let Tom decide. And I would. And you know, I was usually right. It was precisely this user knowledge that gave me a seat at the design table.

I decided to continue filling the support role for the application, mainly because it gave me an incredible insight into the user experience -- their pain points and problem areas, their questions, workflows, and business processes. Yes, it helped me create better help. But more than anything else, it helped me transition into a more prominent player on the team, influencing the design and product roadmap. I realized that this knowledge of our users was more important than almost anything else. Others could learn to write. Others could create diagrams. But who knew the mind of the user? I did.

Later, at a conference with Noz Urbina, I interviewed him for a podcast. Noz explained exactly what I had experienced but in the context of social media. Noz said that one consequence of managing the social media channels is that the technical communicator taps into the user feedback in a serious way:

Now the technical communicator is in essence the key holder on a pipeline in of customer data, which is essential to product development, which is essential to the business's profitability.... So now instead of just giving the manual which goes in the box because they have to, now the tech comm has a conversation going with the client post-sale, to see where their problems are, to see how their customer experience has been with the product over time. And because that conversation is intimate about the details of the customer experience with the technology, then that becomes very valuable data.

Some technical communicators tap so fully into the user experience that they transition from their tech comm roles entirely into a usability role. Theresa Putkey, a Vancouver-based technical writer, made this transition. I spoke with her about how she did it. She said,

I was doing the technical writing. ... I had been telling these [project] guys, this UI is really bad. I don't even know how you could have thought of this. Of course I said it nicer than that. Like, this is a good first attempt, but if you really want to do it well, this is how you can do it. So when they wanted to [start another project] with requirements and usability, they didn't have anybody to do it, and I said I'll do it. Because that's something I'm interested in. Since it was a small team, they said that's great. And I got along with everybody. So that's how I started doing the usability stuff. Started designing the UI and writing the specs for it. And then also doing the technical writing at the end.

Next: 1.7 Catalyst 4: Wiki Manager (Overlooked)