April/May 2007

Volume 47, Number 5

Of Users and Unicorns

by Jessica Betterly

Every technical writer has been there—trying to write about something that was designed in an alternate reality, that fantasy world where users and unicorns are just a theory. And we sit there, struggling to find some way to explain this thing to our readers. Seven years ago, I became a technical writer, creating user guides to explain software created in that alternate world. (Folks, it had and still has DOS-based screens with blue backgrounds and white text in bold Courier.)

Now I’m a Business Analyst, one of those people designing the software. And every day, I try to remember that users are not a theory, that real human beings will use this software, day in and day out.

How it All Began

I was lucky—from the time I started as a technical writer, I was told that my job was to bring the users’ perspective into the project design. Not every company is organized like that, nor do they want to be. But I attended project meetings from the initial conceptual stages all the way through to release. I reviewed the product vision and functional requirements. I was able to voice my opinion, always reminding my teammates that real people would need to use this software.

I learned to explain to developers that their ideas were really cool, but “I’m not sure how much value that brings to the user.” Or another favorite: “A couple of extra clicks aren’t much to us, but if you do that all day, wouldn’t it become annoying?” I always tried to keep in mind that developers love to come up with new ideas, and a project always benefits from that kind of enthusiasm. But someone needs to direct that energy to benefit the user, and sometimes that was me.

Crossing the Rubicon

Once I felt confident representing the user in meetings and requirement reviews, I took the next big step—writing the requirements themselves.

I started small. First, I convinced the developers that it would be much easier on them if I wrote the messages displayed by the software. They quickly realized for themselves that I wrote better messages than they did, and soon getting every message “blessed by Jess” was a part of the development process.

Next, I took on the user interface (UI) challenge. Development would mock up a screen and I would offer suggestions for improvement. Eventually I said, “Wouldn’t it save you time if I designed the UI?” So that became my next step towards the ultimate power.

Finally, my company took on a huge project and needed everyone to help in any way they could. I jumped up and said, “I can write requirements!” And I could. But then I had to listen to everyone else offer up criticism (like I had offered for so long) with a measure of grace. It was a growing experience, to say the least.

Look Where It Got Me

Now I’m a Business Analyst—a job title that leaves my father a little befuddled. He understood how I filled my days when I wrote user guides. He doesn’t quite understand what a “Business Analyst” does all day, but trusts that I’m the best “Business Whatever” in the world, because he’s my dad.

And each day, I go to work and try to view the software from the perspective of someone I will never be: a consumer of the product. I interview clients so that I can understand what they need. I talk to our resellers to hear what they think. I listen to support personnel explain what they see as our clients’ biggest pain points.

And then I go to my alternate world, where hopefully my users are no longer theoretical (even if unicorns are). And I write requirements that developers, quality assurance (QA) testers, and technical writers use to create a software program that a very real person will use 8 hours a day, 5 days a week, 50 weeks a year.