When you are in a job interview for a technical writing position, there are a few questions that the interviewer is almost certain to ask.
In fact, if the question that I discuss in this post does not come up, you can use that as part of a litmus test towards determining if the organization is really serious about technical writing. And if they are not serious, you definitely want to think about if you really want to work for them.
The Most Common Question in a Job Interview for a Technical Writer
The most common in-depth question that you will face in an interview for a technical writer job is:
Can you explain the lifecycle of a technical document? (This process is also known as the documentation development life cycle or DDLC.)
The following is a detailed answer that you can provide to this question.
(Note: Some of the details I provide with regard to this question are based on the assumption that you are writing a user manual in particular. So if you plan on using the information included in this post, you may want to mention this in your interview before you answer the question. If you are interviewing for a technical writing job where writing user manuals is not going to be a main part of your job duties, alter your answer accordingly.)
Project Start-up: Create the Project Plan
The project plan for the document you are creating occupies a place within the greater project plan for the product that is being released. Make sure that you do not confuse the two. This is the first stage of the document lifecycle. Within this stage, a number of tasks could take place, and a number of decisions could be made.
First, you must know what product you are writing about (this may seem like a foolish point to make, but in this case, state the obvious).
Second, establish what deliverables the documentation team will be producing. This could include, but not be limited to, user manual, help files, and white paper. With each deliverable, the purpose will usually be clear: to inform, instruct or persuade.
Third, audience analysis: discuss who will be the main audience. For example, what is the average age of your expected audience, their educational background, and their level of technical expertise as it relates to the product?
Fourth, you will decide which tasks are assigned to each person on the documentation team. This will also entail establishing timelines for the first draft, edits, second draft, and final draft.
Research/Gather Information
First, if this is a subsequent version of a software product, look at the pre-existing user manual. Second, arrange necessary interviews with subject matter experts. These interviews may take place with developers, the product manager, the marketing department and testers (more information on planning for and conducting an interview with subject matter experts in a future post). Third, and probably most importantly, use the product yourself.
In this stage, you may also want to read the proposal for the product and any brochures or other marketing material that exists.
Create the Document Plan
(Note: do not confuse this with the project plan.) You will create a document plan for every deliverable that your team agreed to produce during the project planning stage. Essentially, a document plan is an outline that you can write as a table of contents (though the exact wording will no doubt change when you write the actual table of contents for the document).
I include in this stage: Design the Structure of the Document, as it is very closely related. In many cases, you will be using existing templates. However, there are numerous formatting considerations, such as how many levels of information you want to include in each section, and where to place notes, tips, warnings, and other related information.
Create a Style Sheet
This is a hugely important step, and shows the company you are interviewing with that you know what it takes to produce consistent, quality documentation. Most organizations will likely have a company style guide and will probably also defer to a larger style manual (such as The Chicago Manual of Style). I won't go into details regarding style guides and style sheets at the moment, but ensure that you are familiar with the logic behind using a style guide and style sheet, and know what different aspects of a document would be included in a style sheet.
Write the First Draft
At this point you start writing. You start filling in the outline with the information that you gathered during the research stage. You do not get hung up with gaps that you detect in the information that you have collected though you should note the relevant places where you are missing details. The goal at this stage is to get the information down. You may want to throw in a few comments here about how you set personal deadlines for yourself and get the work accomplished in a timely manner. The inability to produce is something that plagues writers of all types, and technical writers are no exception.
Perform the Technical Review/Edit
At this stage, someone who is familiar with the product will review the document to ensure that it is technically accurate. If there is not a dedicated editor, prepare a review sheet with space to fill in the reviewer's name, and the date and the time of the edit.
Implement Recommended Changes and Write the Second Draft
You now implement the changes provided to you by the person who reviewed your document. There may be a further round of subject matter experts to fill in gaps in the document. After you finish writing the body of the document, you will then write the table of contents and other front matter material, and the index and other material that goes at the end of the document (such as glossaries).
Perform a Usability Test on the Document
Now, if you have the time, performing a usability test on the document itself, is something that can help you catch any problematic language or gaps in the document. Mention usability tests in the interview only if you are familiar with how to prepare for and conduct a usability test.
Perform Final Edits
First, you should perform a self-edit on your document based on your style sheet and a related checklist which you use to confirm the consistency of the document. Just a quick note on the checklist that you use: it will address issues such as format and structure of the document, terminology related to the software (i.e., when a specific button or part of the user-interface is referenced, it is always referenced in the same way), style, and grammar.
Next, the copyedits will take place, followed by a proofread, and then the final sign-off by whomever is responsible (lead technical writer, in-house editor, or product manager; different organizations are different in this regard). The legal department will then take a look at the document as well.
Then, the document will be sent to the graphics department so that they can lay out the document, and add screen shots and other visual components that may be necessary (Note: in many smaller organizations, this may be something that the technical writer could be responsible for.)
One last check should take place to ensure that no errors have been introduced by the graphics department (a very, very real possibility, if not likelihood!).
Send Document for Printing
Finally, the document is sent for printing, or if the document is only to be in digital form, it is generated. When the product is shipped, there could be last minute updates included as inserts with the printed document and/or as .txt files included in the digital release of the document.
Summary: The Lifecycle of a Technical Document
A summary of the above steps:
—Project start-up: create project plan for the document
—Research and gather information
—Create the document plan (outline)
—Create a style sheet
—Write the first draft
—Perform the technical review/edit
—Implement recommended changes
—Write second draft of document
—Conduct usability test on document
—Perform final edits
—Send to graphics department
—Final check
—Send document for printing
Two very important qualifiers to keep in mind when you prepare for this likely question at a job interview for a technical writer:
—Do not confuse this with a question about the lifecycle of a document in an agile development environment. Some significant differences exist.
—Do not confuse this with a question about the lifecycle of a software product and how and where the writing of the user manual fits within that process. A related but different question (and one that I may cover here later)!
Finally, remember that this is a very idealized version of what really takes place when a document is being created. In the real world, changes to the product, changing deadlines, staff shortages and any number of other unexpected occurrences can result in a slightly different process, or steps being omitted. However, if you are familiar with the process, especially for those with little or no experience, it at least demonstrates to the organization you are interviewing with that you know the importance of planning and organization (often, skills that are almost as important as your writing ability).
Good luck in your job interview!
0 comments:
Post a Comment