From Technical Writer to Business Analyst

By Amanda White

Technical writers and business analysts use similar skills but in different ways. Here’s how to switch hats from one position to another.

When I first told people I was getting a master’s degree in technical writing, one of the most common responses I got was, “Oh, you’re going to be a business analyst?” To which I had to respond, “A what? I thought I was going to be a technical writer….”

It turns out we were both right. After a few months in my first technical writer role, I was moved to the title business analysis. Also known as a “requirements analyst” or a “requirements engineer,” a business analyst is tasked with figuring out what people need their software to do. That may not sound like it has much in common with technical writing, but when you examine both careers, they use similar skills: creating clear and organized documentation of complex systems, communicating between technical and nontechnical audiences, interviewing subject matter experts, and advocating for the user. However, these skills are used in different ways. Here are the differences you will face when switching hats from technical writer to business analyst (or vice versa).

What vs. How

When you’re writing user help, you’re telling the user how to do something. You’re assuming that they already know what it is they want to do. In requirements gathering, rule number one is to concentrate on what the user wants to do and leave the details of how they should do it for later.

There are several reasons for this. One is that it’s easy to lose sight of the actual goal of the product when you get bogged down in details. Another is that the people requesting the system are experts on the problem they need to solve, but they are not experts on technology or design. The extent to which you will eventually be involved in the decision and documentation of the “how” depends on the makeup of your team. On a large team, you might just be responsible for supplying and prioritizing the user stories, while on a small team, you might be the primary person responsible for user experience, making design decisions in conjunction with the development team.

Concept vs. Reality

When you are documenting a product as a technical writer, you have the product itself to go by. It’s usually more or less complete by the time you get your hands on it. If it is not complete, you at least have something you can put your hands, or your mouse, on. If you want to see how it works, you can click around and push the buttons.

If you’re a business analyst, there’s nothing to click. You’re writing and talking about a product, or a new set of features, that’s just an idea. This means that making sure everyone’s on the same page, communicating concepts to the stakeholders, and keeping track of what has been decided is an ongoing struggle. Wireframes, use cases, mock-ups, and flowcharts can all help, but there’s no quick and easy way to document an abstraction.

Technical Audiences vs. Nontechnical Audiences

The technical writer is usually communicating technical knowledge to less-than-technical people. Business analysis, on the other hand, usually goes the other direction: you will need to transform ideas from nontechnical people into documentation for developers. As technical communicators, our first rule of thumb is “know your audience,” and that doesn’t change when you’re wearing the business analyst hat. What a technical writer may document as “Click the plus icon to add another row,” a business analyst may record as “User can increment the fields.”

Black Box vs. White Box

When you’re writing user help, you only want to include information that will benefit the user. And the user doesn’t actually care how the system works behind the scenes—they just want to know what they have to do to get what they want. But when you’re writing requirements, you are writing for developers, who most certainly do care how the system will work.

A description of a system that only includes outside interactions (usually actions taken by the user) is called “black box,” as if the system is painted black so you can’t see inside. A description of a system that explains what’s going on behind the scenes is called “white box,” although “clear box” would be a more accurate term.

For example, a help topic on submitting your address might look like this:

1. In the top menu bar, click Profile.
2. Under Address, enter your address in the text box.
3. Click Submit, and in the confirmation box click OK.

A use case of the same task might look like this:

1. User navigates to profile page.
2. System displays editable user profile.
3. User enters address and submits.
4. System displays confirmation pop-up.
5. User confirms.
6. System adds address to the database and displays confirmation message.

There are twice as many steps in the white box system because for every action the user takes we are also recording the action the program takes.

First vs. Last

Technical writers often join a project just as it’s wrapping up. Here’s the widget, now document it! Business analysts are the first to touch a project. Before the project technically exists, a business analyst is scoping out the needs and even weighing costs to benefits to see if it should make the queue. Being the first hand in a project means that you have more influence over it. There are various points at which you can contribute to shaping the system under construction, from advising clients on prioritizing features to offering suggestions on enhancements. You may even have a say in the program’s design and user interface.

Document as Medium vs. Document as Product

As a technical communicator, the documentation you produce, whether it’s a user manual or a tutorial video, is your product. While it’s true that the purpose is to communicate information to the user, it’s your documentation on which you are judged. To a business analyst, your requirements documentation is your primary deliverable, but what really counts is your ability to capture and communicate requirements. In other words, if you write flawless, fleshed-out use cases that are easy for the developers to understand, but you fail to notice a key business rule, your perfect documentation isn’t going to protect you from an angry project sponsor who now has to spend money to change the software. The decrease of importance of documentation as an end deliverable is more pronounced in the world of agile development, where requirements are fleshed out as iteratively as the software itself, thus encouraging “living” documentation.

Whether you are seeking a new career, expanding your role on your current team, or just perusing want ads and thinking “Hmm, could I do that?” business analysis is a natural transition for technical communicators (as is technical communication for business analysts). Retooling your existing skill set for requirements analysis will open up another segment of the jobs market to you and give you more creative influence over software development and the user experience.

Suggested Reading

Thinking of delving into the world of business analysis? Fortunately, your career in technical communication is a good foundation to get you started. But to make the transition, here is some recommended reading:

Brennan, Kevin, ed. A Guide to the Business Analysis Body of Knowledge. 2nd edition. International Institute of Business Analysis, 2009. (The “BABOK” is the International Institute of Business Analysis’s (IIBA) flagship publication. Use it as a reference or to study for Certification of Competency in Business Analysis (CCBA) or Certified Business Analysis Professional (CBAP) exams.)

Cohn, M. User Stories Applied, for Agile Software Development. Addison-Wesley Professional, 2004.

Cockburn, Alistair. Writing Effective Use Cases. 1st ed. Addison-Wesley Professional, 2001. (However you gather your requirements, chances are you’ll be documenting them as either use cases or user stories. Cohn’s and Cockburn’s works are classics in their respective mediums.)

Carkenord, Barbara. Seven Steps to Mastering Business Analysis. J. Ross Publishing, 2008. (Carkenord’s book is a good general introduction to business analysis and covers more elicitation and analysis techniques than documentation.)

Cadle, J., D. Paul, and P. Turner. Business Analysis Techniques: 72 Essential Tools for Success. British Computer Society, 2010. (You’ll never be at a loss for analysis tools with this book. Diagrams, reports, and analysis methods with handy acronyms are so plentiful that every business analyst is likely to find something of interest.)

Amanda White is optimization development manager at EBSCO Information Services in Ipswich, MA, where her role has transformed from technical writer to business analyst to manager of an agile development team. She recently received her master’s degree in technical writing from Utah State University.