When I begin designing an application or a web site, the first questions I have (after getting a handle on who the user is) are task based and center around the following:

  • What does the user want be able to do with this?
  • What are the most common tasks that will be done here?
  • What are the least common tasks?
  • What is the normal sequence of events for the user (not the computer)?

While I start making sketches of general topic areas and tasks with pencil and paper, I switch rather quickly to working on two computers: one with the design on it and one with the beginnings of the user documentation. As I write the “how to” documentation based upon the in-process design, the weaknesses of my original design become apparent and I go back and forth from writing text to designing the software until it all flows. The maxim I try to follow in user interface design is “If you can’t teach it, it’s poorly designed.”

Include Writers

Having writers involved in design discussions and brainstorming sessions can be very useful, whether the writer is a “designer” or not. While many technical writers may not be able to design from scratch, almost all of them will be able to see ways to simplify designs and make things more apparent to the user. I may be a bit biased because I got started in user interface design while working as a technical writer for a progressive R&D company that believed in writing the documentation before coding! We had to imagine (and hence begin to design) how the task was to be accomplished before it existed anywhere.

Task-Based Approach

Even with this background though, it is easy to get lost in the trees and not see the forest in front of you! This was brought home to me in a recent project when I was tasked with writing the online help for a piece of software that was already built. The initial description of the project was “Make sure every screen and dialog has some sort of F1 help associated with it.” Of course, the documentation was holding up production because it had been put on the back burner while all the programming was going on rather than trying to do it in tandem. I discovered a rat’s nest of separate dialogs intertwined in such a way that I continually got lost as I was writing. I would suddenly happen upon a dialog that I hadn’t seen before or, even more fun, discovered three dialogs that were gotten to from three distinct paths but which appeared almost identical. But what did I do? I got lost in the trees and kept blindly trying to make the help make sense when the design did not.

Another writer that had been working on different parts of the same help system and was responsible for doing all the mapping of dialogs to help IDs about died when she saw the rat’s nest of help on this one topic! When she saw three different IDs for what she saw as a single dialog, she thought I’d really lost it! But when she saw the software it became clear that it was as bad as it looked from reading the help. The programmer couldn’t see the problem because I didn’t have a task-oriented document that would have shown how the user had to jump from here to there and back again to do a simple task. The other writer’s first comment to me was “Why didn’t you start writing the task-oriented sections first so we could use those as ammunition to get the user interface changed in the next release?” Uh, well.because I got lost in focusing on the original task: “Make sure F1 brings up help describing each dialog.”But she was right. Had I started writing the help from the direction of “What is the user going to do with this and how are they to accomplish these tasks?” the help would have been far more useful even with (or especially with) the poor design and it would have been much easier, I hope, to convince the programmer that the design needed a serious overhaul.

Programmer and Designer Relationship

Too often, programmers sit in a vacuum coding and designing without much more than a basic Marketing Requirements Document that defines a very high level functional specification. The programmers make sure the set of defined tasks is done, make sure it works on multiple platforms and integrates with other sections of code, but no one steps back and looks at the design and asks if it’s usable, simple, as good as it can be, and so forth! Is it a design that users will not notice (a high mark in my book because it means the user is concentrating on getting their job done and not even noticing the software!) or is it something that causes the user to spend time thinking about using the tool rather than getting their job done? Just as the writer is dependent on the layout person to present words, the programmer should be dependent on the designer to present the functionality. Or even better: they should all work together.

Conclusion

So, what is the moral to the story? Add usability requirements to MRDs. Make usability a requirement and have designers, programmers, and writers work together to create software that not only meets the functional goals, but allows users to get their jobs done without fighting the software.