The terrible tale of Alice the tech writer

8:05am

Alice is under pressure from the product team to deliver final approved copy by the ship date, even though there are still software UI changes being made.

8:30am

She begins to incorporate the changes and corrections from a folder of hardcopy and email notes she’s been collecting for weeks.

Monday 2:00pm

Alice would like to improve the manual.

Monday 2:00pm

But she has no first-hand data to work from. She makes her best guess on improvements to make.

Tuesday 8:30am

A diligent and experienced writer, Alice calls contacts in technical support, QA and marketing to see if they have any end user feedback. Eventually she hears back from all three saying they’ll get back to her in a few days.

Tuesday 11:00am

She sends an email with a PDF for the draft version and asks the customer support and QA teams to review the relevant sections.

Wednesday 9:00am

Still no word from her customer support and QA contacts on the user feedback they’ve promised. Alice sends them a second gentle reminder.

3 days and counting

Friday – 2:00pm

The QA team returns their review draft with comments in the PDF, but they have forgotten to review some sections. She never hears back from customer support. But who likes to review 200 pages of PDFs? Alice is forced to finish the manual update without the benefit of user feedback she was really hoping for.

7 days and counting

The following Tuesday 10:00am

At the product team meeting, she learns that engineering made additional UI changes that affect the guide. Because of batch publication process constraints, she cannot extend the deadline. No chance to incorporate the customer feedback or UI changes now.

She groans in frustration. She starts her new folder of notes and changes for next time… Definitely NOT fluid.

Now see what happens with Fluid Topics

2:05pm

She pulls up the guide she’s updating and it has lots of great feedback users wrote and sent directly from the reader interface.

Tuesday 8:20am

Alice also reviews user analytics data. She notes the sections in the documentation that users refer to most often so she can focus on the most relevant topics.

9:35am

One click and Alice lands in the relevant sections. She agrees the documentation could be enhanced. But there is also something else, users don’t understand the menu options on some screens. She forwards the input to engineering.

11:45am

Engineering reports that they made some UI changes based on the input she forwarded. They send her new screenshots and she’s able to quickly rewrite those sections.

Wednesday 9:00 am

Alice quickly scans the installation and setup Personal Books she received from customer support and incorporates suggestions from their in-context notes.

Thursday 10:35am

Alice uploads the updated guide to Fluid Topics. Content is processed as soon as it arrives and is immediately published to the company online information hub with synchronous indexing.

10:45am

Alice identifies PDFs and other unstructured documents that should also be indexed when searching for this documentation. These documents provide a new perspective and can be easily found and examined by users.

That’s the magic of Fluid Topics dynamic publishing!

Definitely fluid.

The terrible tale of Alice the tech writer

Monday 8:00am

8:05am

8:30am

Monday 2:00pm

Monday 2:00pm

Tuesday 8:30am

Tuesday 11:00am

Wednesday 9:00am

Friday – 2:00pm

The following Tuesday 10:00am

2:05pm

Tuesday 8:20am

9:35am

11:45am

Wednesday 9:00 am

Thursday 10:35am

10:45am