Reinventing the Job

by Mary Jane Adams

I am thankful every day to have food on the table, a roof over my head, and a job that I enjoy (most of the time.) I am thankful to have made the transition from contracting to direct full-time employment at the company where I work. I am thankful to know that the work I do and the contributions I make to our project are noticed and appreciated. And I am acutely aware of how rare all this is in a world where the economy is turned upside down, unemployment is higher than it's ever been in my lifetime, and the overall mood of the country is bleak. Still, it is hard for me to fathom how different the working world is now than it was a few years ago.

In 1999, after working for five years as an editor at a traditional book publishing company, I was hired into a dream job. At that time, I didn't even know what information architecture was; yet I was hired to be an information architect at a growing Web consulting firm. I quickly learned that information architecture was very similar to the work I had been doing as an editor—ripping apart and reconstructing sentences, breaking information into digestible chunks, and changing text formats to help readers easily find what they seek.

Organizing the information presented on a Web site involves processes that are similar across many types of communication vehicles, whether a book, lecture, research paper, PowerPoint presentation, or any other medium. The common denominator is finding the best way to communicate a message to a particular audience within the inherent structures of the medium. Print publications and the Web share the written word; all the traditional rules of grammar, syntax, and literary expression apply to both.

However, there are subtle differences in the way people absorb the information they read on a printed page versus a computer screen. In a publishing house, readability can assess how easy or hard it is for readers to receive the intended message. On the Web and in the software industry, usability is the yardstick that measures ease of use through interaction. In other words, how easy or difficult is it for someone to get from the home page to a desired page? Is the navigation intuitive and easy to follow, or does it involve circuitous wandering from link to link? Usability includes readability plus a whole lot more.

My position at the Web firm became an opportunity to adapt skills I already had to a growing new medium, the Internet. This was my teeth-cutting job in the tech sector, and no school could have taught me what I learned during the two years I spent there. I learned the important difference between writing for print and writing for the Web. And I discovered a passion for user-centered design, which applies the usability yardstick to Web sites and software to ensure that people will actually be able to use new technology rather than scratch their heads and stare at it.

In addition to learning basic principles of information architecture, I also learned how to write and develop many types of documentation that are useful in creating Web sites and software applications, including use cases, site maps, interactive storyboards, Web prototypes, and usability studies. These types of documentation help a Web site development team clearly define what they are doing and where they are going. Such documentation can also help clients and people who will use the Web site understand the team's overall design before they create it. Documentation is necessary to help all parties see a common picture of a project and communicate their ideas and concerns. After all, communication is the purpose of all documentation.

Create Storyboards Tomorrow

One of my first assignments at the Web firm was to work on a team that was developing storyboards for a Web site. I had a week to create the storyboard template. I protested to a friend, "I've never made storyboards!" He said, "If you had to create storyboards tomorrow, what would you do?" The question ran around in my head for a day. Then I realized that I could send an e-mail message to work colleagues asking if anyone could share examples of storyboards they had created. Within 24 hours, my in-box was filled with examples. I showed a few of them to our team, and suggested a hybrid approach that I thought would work for our project. Everyone liked the idea, and it became the template for our storyboards. The Web firm did not last long. Its stock price went up, and then it went down and never recovered. I went out when the CEO announced the third round of layoffs through a videoconference that all employees could stream to their desktops. What a weird way to lose a job! But I soon discovered that the timing was fitting. I lost my job on November 30, 2000, and my beloved aunt Jane died a week later. I needed downtime to grieve. It gave me an opportunity to reflect on my whole life and what I was doing with it. It gave me plenty of time to look for my next job. And strangely, the job found me.

Serendipity

A former colleague told me that a contract technical writing position had become available at a company where he was about to take a different job. I interviewed for the job and got it. Given the current economic climate, I was extremely lucky to go from a layoff to a contract position within two months. However, after I started the new job, I found that I had joined a dysfunctional software development team. Constant infighting on our team caused the overall design of our project to change almost daily. I had entered complete chaos. Over the year that followed, I felt that I was witnessing everything that can possibly go wrong on a software development project. That being said, I had some satisfaction in being able to know this. At the previous Web firm, I had learned about sane approaches to software development that make everyone's life and work easier. Documentation actually plays an important role in helping a software team move from the chaos of brainstorming to a well-conceived design. Communication is the key. Since many software developers resist documenting what they do, a tech writer can play a very important role. I gradually found that my work helped get our project back on track.

Fortunately, the software team moved beyond its dysfunctional stage and is now coding with new purpose. Today, I am creating a Web-based format for all of our technical documentation and moving all of our paper-based documentation to our intranet. My next project will be creating a help system for our Java-based software, and my manager asked me to help with our graphical user interface (GUI) design. My information architecture experience was a necessary precursor for all of this.

When I worked at the publishing company a few years prior, I didn't know a thing about software development processes. In fact, I sometimes saw openings for technical writing jobs, but never felt that I had the qualifications to pursue them. How did I gain these skills in just a handful of years? How did I learn all this stuff that was so foreign in my publishing world? I just had to find the courage to dive into the unknown with confidence that the abilities I already had in my backpack were sound ones. I also had to learn how to read programmers' scrawl, but that's another matter. These are the most important lessons I've learned: Don't be afraid to ask questions, and don't be afraid to dive into new things you've never done before. You never know what you will learn along the way. And you might learn to do things you never imagined.

Mary Jane Adams is a writer, editor, and information architect. She aspires to be a successful sea kayaker in the Pacific Northwest.