Hefty deliverables are unnecessary when working with a startup or agile team. I’m not a fan of templates, but documentation can be useful once in a while. Here’s a detailed look at one thing I make semi-regularly that keeps everyone informed as the product moves forward.
Take screenshots of a popular flow
After you’ve defined the problem and devised a plan, pick a common user flow and document it from a customer’s point of view. Try outlining the steps in your signup flow or checkout process.
Get screenshots of every page in the flow. (I use LittleSnapper for full-page screenshots.) If your team has a designer, ask them for any comps or templates before looking at the app itself. These reference images may help you find dusty corners that other people forgot.
Ask your engineering team for access to the testing or build environment. You may need special access or provisioning to see each page in the flow. If you’re reviewing content for a checkout process, be sure to ask for test credit card info.
Work through the flow several times, taking special care to break any form fields you can to see error messages. Once you’ve gathered all of the screenshots, make a new Pages or Word doc.
Make a basic copy document
I normally work in basic HTML, but I have yet to find a better way to do this part because of confidentiality stickiness. Since this document will serve people who love tracking changes (i.e., product owners and legal folks with expensive houses), I recommend dealing with the word processor pain. You could also try Google docs for this, but it might not be ask easy to pass around with the right formatting.
First, make a table with two rows and three columns: Screenshot, Content, and Notes. Then, duplicate the table for each page of the app flow. If your checkout process has 30 screens, you should have 30 part to the document, each with its own table.
Once you have a blank template, save your work, take a deep breath, and dump those screenshots into the pages. Title each page to match its screen. Finally, add a cover page, page numbers, and table of contents. When you’re done, you’ve got a clear copy document that outlines the flow and includes fields for revisions and notations.
Challenge and revise the content
Now’s the fun part. Get to work editing the content. Make it consistent. Make it friendly. Take the engineering speak out and make sure everything fits your brand. Fill in holes and remove the nasty bits.
If a screen’s title is unclear, overly wordy, or full of jargon, revise the title on its respective page in your giant document. Make the document say what you want displayed in the app. If you can include HTML tags (h1, h2, h3), it might help clarify things and your team will appreciate it.
Get approvals and go live
Once the content is ready, follow your normal process for getting approval. You may need to revise the document a few times to incorporate feedback.
When everyone signs off, accept the changes. This may seem like a no-brainer, but engineers aren’t used to looking at layers of Track Changes bits all day. Hand off a clean document and be there to answer any questions and validate the content as it moves into code and testing.