Writing Professionally Outside of Professional Writing

In an earlier entry, I noted that one of my vivid memories from my time in professional writing comes from the ironic realization that I was doing very little writing throughout one of my courses. Instead, this computer-aided publishing class mainly focused on the design of text and other content that already existed, with the actual writing in the class dealing with the decisions that went into the creation or modification of any presented design. In a sense, this course therefore focused more on the overall user experience of a document—how the user would view all the words and paragraphs and content as a whole—rather than how one would create the technical written elements that were necessary to form the document in the first place.

Perhaps to balance this out, then, I want to discuss a recent writing experience that I find to be almost thematically opposite. One of the classes I took this semester was Purdue’s software engineering class, described on the university’s catalog as an introduction to the methods and tools of creating software. At first glance, this course seems like a useful technical experience and maybe even a good glimpse into experience architecture from a software perspective; the course does not, however, necessarily seem to be one that would include lots of writing. However, the course has consistently emphasized the need for planning and organization, especially with software that is complex and modular. And so far, most of these things have been done in writing.

During this semester, all teams in the course are to make a social media application that combines select features of contemporary social networks. The instructors of the course give all teams a universal list of requirements that the application should eventually perform: Users should be able to create accounts, users should be able to make posts, posts should be assigned to topics and users should be able to follow topics that they’re interested in, and so forth. The actual technology that each team uses to meet these requirements can vary, but the capabilities of the final product are set in stone. From here, it might seem as if the next thing for teams to do would be to start programming—after all, the requirements have been written out and even formatted in a checklist-like pattern.

However, there is an extensive amount of documentation needed before delving into any technical work. Some documents are relatively simple, such as one that includes only a basic outline of the project’s goals, expected deliverables, and stakeholders. Other documents are more complex, including one that details the technical tasks that need to be done to meet the requirements of the project, or one that illustrates the design decisions (both functional and technical) that teams made when choosing how to build their applications. Even though many of the document’s pages are filled with diagrams rather than pure text, it remains the case that almost all these documents have been more than a dozen pages each. So while working on the most recent planning document, I felt a sort of déjà vu: I was writing more in my computer science class than I normally did in my professional writing classes!

Why bring this up in a professional writing class, then? Other than the irony, I find that it is important to remember that software engineering (along with several other technical fields) is very much related to user experience architecture—perhaps it’s a bit closer to the gritty technical details than professional writing, but at the end of the day, good software still tries to provide the user with a positive and intuitive experience, just like how a good document will provide the user with clear navigation and useful content. And while developing software takes a different technical skillset than writing documents, it is important to realize that both things follow the same principles during development: The end product should be designed around what the user needs and wants. Intermediate products should iterate upon each other as development continues, each instance taking the best of what existed in the previous iteration while modifying the problems that may have appeared. And every choice—be it a design choice that the user will mostly ignore or a technical choice that will directly impact how the user interacts with the product—should have a rationale for implementation, a usability reason behind its existence.

However, I find one more thing relevant about this situation: The intensity of the writing expected from people outside of professional writing. All these mentioned documents are expected to be long and thorough, and each of them deals with information that is technical and complex. The gate to writing each of these documents, then, is not how well the prose is crafted but rather how well the writers can understand the product that they will be developing—the technical details about a technical product. To me, this implies a sort of baseline that writing professionals need to meet: We need to be able to learn the technology that we’ll be writing about and then write about in a way that makes us seem like experts, even if we aren’t. Of course, not every document will require the same level of technical depth, and there will be some documents that no manager would dare trust the developers to write (such as most public software documentation, if we keep with the computing theme), but the ability to learn quickly and explain that new knowledge in a way that makes sense nonetheless remains an important quality for any professional writer to have.