Simplify, simplify!

I was asked to help out a colleague who’d got mired in an unsatisfactory project. A new system is being launched – new for some users, updated for others, and he’d been tasked with updating the online reference (called a ‘quick start guide’) from the old version of the system. That was essentially a help system created in HTML – screen shots with procedural instructions below.

He worked with one SME, produced 90-odd pages using the old format, and at the end, the project manager reviewed it, and passed it to a half dozen business training reps to review. He got a half dozen versions of ‘it needs to look more professional, it needs to look more wizzy, it should be more engaging’, plus ‘can we have a PDF version in addition?’  After a couple of attempts at doing what they wanted, but receiving no thumbs-up, he asked our manager to speak to the project manager.  This person said ‘I don’t know exactly what I want, but this isn’t it.’ I was called in to support him and see if we could reach an agreement on a way forward, with only a week or so till the deadline.

The project manager and SME repeated to me the ‘don’t know what but not this’ mantra. Worryingly she also said she’d invited two other ‘learning people’ to a meeting a few days away to contribute their opinions.

It seemed to me the last thing we needed on this project was more opinions. I started by emailing the SME and project manager two assumptions of mine for them to agree with or disagree with. One: that there were two audiences, those who’d used the old system and those who hadn’t. Two: that this was performance support & reference, not elearning. They immediately agreed with those, which allowed me to say ‘So …’ and suggest that one audience would ask ‘What’s changed?’ and the other ‘What’s this about?’ and these had to be addressed separately; also to suggest that making it ‘engaging’ was nothing to do with it. We had to answer the question ‘What is this screen that I’m on expecting of me and why isn’t it behaving as I expect?’. 

The system, an external one, didn’t have any capacity for context sensitive help, nor even for these guides to be available from within it. A person would have to either have the guide open in a separate window if they were anticipating trouble, or duck out and find it, refer to it, and return to their screen. To me, that ruled out the project manager’s preferred ‘exploratory’ solution of screenshots with mouseover hotspots where explanatory text would pop up. They’d have to retain the explanation in their heads as it’d disappear the moment they moused away to get back to the system, and they couldn’t print it.  Interestingly, all my suggestions were welcomed with open arms – it seemed they’d been longing to be TOLD something rather than asked. It was easy to get them to cancel the meeting on the grounds that more opinions wouldn’t help.

The project’s now back on track. We’ve abandoned the HTML reference pages altogether in favour of short task-based PDFs with callout text boxes pointing to the screen items they explain. The PDF is universally readable in the organisation, and automatically allows searching and bookmarks/contents. Very simple, very non-technical.

With hindsight a bit more definition at the beginning would have stopped this spiralling, in particular some definition about who had to approve it and when. The SME had been perfectly happy until the PM and the cohorts all chipped in. It would also have helped to emphasise the importance of agreeing the functionality before getting mired in the aesthetics and comparing it with ‘engaging’ elearning. Prototyping rather than completing the entire package would also have helped.