Back in the day, when highly complex specification documents were written in MS Word… (not my idea), let’s just say lots could go wrong.
This was around 2012. Spec Editors had their very own version of Word with plenty of Add Ins
These were really large documents. Hundreds of pages long. Because the tool was a simple text editor, without the support of the whole document lifecyle, the process had to be taken outside. First, multiple Authors would write pieces of the document, then in went through Subject Matter Expert review and when the content was agreed upon, the last phase was validation done by Editors. The Editors did not care so much for the content but for the formatting and use of special characters, external plug ins and all sorts of surprises that would turn out wrong at the printer. Imagine printing 500 pages just to find some strange characters here and there.
And it turned out, that the Authors’ creativity in working around the process was immense. My favourite was when in order to write ± – which is special ASCII character U+00B1 and should be inserted in the document by using the Symbol function, writers typed plus „+” and underlined it! Clever, huh?
The trouble was, it took a lot of effort and a skilled eye to catch it before it went to print!
How do you prototype MS Word?
Our users were the Editors. We did proper research and understood the primary use cases they were having trouble with. But how do you prototype MS Word? There is no home page, there is no primary or secondary navigation. Experience from everything I had designed so far – apart from „empathise with the user” – was of no use.
There was a process the users followed though.
They first checked for page format, then went through all the tables, then headings, special characters, styles, figures and finally, Active Objects.
This way of working ensured higher quality – they only had to focus on one thing at a time, it also meant that they went over the same, long document many times. More often than not, getting lost along the way. „What was I doing?”
Whatever we built, had to be within MS Word. Despite that the Add Ins tab was already full, I decided that would be my starting page. This was the Editor’s tool box, they knew it. The „Validate” drop down may seem hard to find, but only if you’re not the Editor. Because we used their words, they had no problem locating it.
Some options were simple, like the A4/Letter format selection. Sure, you can go to File -> Page Format -> Select format, but that was too long and it was the first step of their editorial – of Validation – process. They appreciated it.
But the fun started with the other functionalities.
Back then I worked in Axure (I love that tool), and it had some pretty advanced animation capabilities for the time. I decided to leverage that and despite using MS Word, give the users as much automation as VBA (The programming language of the Add Inns) would handle.
Validating Tables, was a step in the process that the Editor had to review the entire document and check table by table if it was formatted correctly, centered or left aligned, did it have a label, and so on.
Here is what the experience would be like.
Although not very pretty, the flow diagram below, came in handy when working with the Development Team
I wanted to make the Editor as efficient as they could be, by providing suggestions whenever possible, undoing actions in case of mistakes and allowing them to exit at any time – after all, this was MS Word and one of its powers was total user freedom.
Validating Headings was an interesting step because it took place on a different view – which did not occur to me, that Word has more than one view, I just always thought of it as „the page”.
The „MS Word” way of doing this was 3-4 clicks longer, not to mention, the user had to calculate in their head, what the correct heading level was. Our solution proposed a heading level, or they could retreat to the manual way of selecting a different level.
My favourite use case though, was the „special characters” use case. At first, I thought I’d just replace all the special characters – there was a closed set of „candidates” with their proper ASCII codes, but I knew this would not work with the users. They would not know what just happened behind the scenes and would feel that they lost control of the document, which was unacceptable. They were the last gate keepers before documentation was approved and it was a big deal.
I chose to use animation to highlight each special character, one by one, even if the system replaced it automatically, and only stop when the user’s intervention was necessary.
Validating the concept
As you can see, I decided to use skeleton to mock a real documentation. There were many reasons behind this, I didn’t want the users do focus on content and the specs were confidential. Users struggled with this a bit, because the whole mock up looked very similar to MS Word, but without the… words.
With a little explanation, they got it just fine.
I was also very happy to learn, that my ideas could have been built with VBA capabilities, although, I’m not sure if they turned out exactly like on my prototype. By the time the tool was built, I was on my next project.
Was MS Word the best tool for this type of work? Probably not and it caused our users a lot of headache, but that’s how it is sometimes. My job wasn’t to redesign the Documentation Workflow, it was to improve one step in the simplest way possible. A low hanging fruit, as you may think of it.
Almost 15 years later, I think it was kind of an AI agent, predicting what the user wanted to do and suggesting a solution 🙂
This case study are just some of the many projects I’ve worked on over my 20+ years in software.
Reach out to me, if you think we could build something together.