Communicating Design

I'm reading Dan Brown's new book, Communicating Design: Developing Web Site Documentation for Design and Planning (companion website at communicatingdesign.com). The book deconstructs ten core web design process deliverables, including usability test plans, strategy docs, wireframes, site maps, and flow charts. Brown highlights the critical role process deliverables play in keeping team members, stakeholders, and clients harmonized. It's not enough for a team to focus on the end product—the website, web app, intranet, or microsite they're developing. It's also equally critical to develop clear, concise documents that describe visually, numerically, and structurally what's happening, when, and why.

Perhaps a topic many regard as soporific, but one that's kept me awake at night: How can I convey the complexities of the schedule without using Gantt? How can I show dependencies in the application while keeping the schematic diagram to one page? Should I break this project apart into constituent pieces or show it all together? Do I need more detail?

My key stakeholder-slash-internal client is visual and concrete. I think in Myers-Briggs parlance she's probably an ESFP. She's not going to follow me if I speak abstractions about what a site should be and do. She needs a diagram, and she needs me to talk it through with her. She also prefers to see a design comp early in the process, which is always fraught with danger, since graphic design is optimally done as a very last step. So all my design deliverables for her and her immediate colleagues are detailed, complete, and convey visually as much intelligence as is available about the project.

Another client naturally inclines toward abstraction. She couldn't really care less about visual design. She needs a different kind of deliverable (and fewer deliverables overall)—outlines and schematic site maps work just fine for her, as do low resolution prototypes.

The point is to adapt your diagrams, designs, and deliverables to your audience. Any good experience designer knows to do that for the end-user. But the message of Brown's book is that we don't really have one client to please, we have two. Which doubles the work, but it also doubles the fun.

What's your experience developing design deliverables?

Comments

[Michael J.]

It's amazing that one author can write both the Da Vinci Code and a book on design process - that guy is amazing! ;)

[engaging experience]

Yes, that would be Dan M. Brown...

[Doug]

I'll be sure to get hold of the book; we've been wrestling with these problems without a lot of experience to guide us.

We're developing a web-based collaborative tool for creating the scenarios for cyber exercises. It has to be an iterative design, since our scenario design methodology has never been tried. We need to get something that works in front of our domain experts so they can discover what helps them and what doesn't.

We started with an excellent design proposal put together by some veteran cyber exercise developers who felt there were major flaws in the way exercises have been developed in the past. The document had nothing about look and feel; it was all about the motivation for the work and an explanation of the new methodology and, since this is government work, how it relates to various government requirements. It served, first, to get us the contract, and second, to give us developers a basic background in the domain we were entering. We had all participated in exercises, but had limited experience in their design.

During the initial period of the contract we concentrated on use case sheets, still without a visual component. The use cases identified which classes of users would be performing the action, what data they would already have to work with, what kinds of domain questions they would have to answer in order to provide new data, etc. In case you're interested, the headings on each single-page use case sheet were:
Use Case Name
Use Case ID
Narrative
Leading Questions
Primary Actor
Actor Goals
User Input
Information from earlier steps
Precondition
Trigger
Postcondition
Success Criteria
Extensions
Examples

We tried diagrams but did not find them useful at this point. Our goal was to have something that was complete on a certain level to discuss among the customer, developers and domain experts and which would show us what data and relationships the database would have to support.

When we had sufficient buy in, we worked out wireframes for each use case. Actually I worked out wireframes, while the other coder built the database. The wireframes helped structure our work and give something concrete to work with in weekly meetings. We tried out various user interface organizing methods at a strictly html level.

When we went to the Initial Planning Review with the customer, sponsor and some domain experts, the wire frames were the primary vehicle for discussion. We also had a large printed diagram showing our notion of how a scenario develops through time, who works on what, what depends on what, and how the process maps onto federally mandated standards. We could point to it throughout the review and show where the current use case and wireframe fit within that diagram. We could not count on having our customer's attention at any other time, so tying everything together in that meeting was essential.

The wireframes were explicit enough that we got a lot of useful feedback. They looked generic enough that we had not developed an attachment to a particular look and were able to incorporate the feedback easily.

In the next phase we developed a working implementation of all the input use cases, not the edit and delete cases, and ignoring all security and permissions issues. Our goal was to demonstrate the database would hang together, that we had the data we needed at each step to proceed, to prototype real alternatives for help, prompting and feedback, and to see if we had scaling issues with performance or showing the user massive amounts of data.

The "document" coming out of that phase was a working prototype. The trick, though, was how to present it. In practice, users could spend weeks entering data that doesn't seem to lead anywhere. The whole motivation for the system comes later, as all the pieces come together, relating the carefully assembled goals of the stakeholders, the descriptions of their electronic transactions, business assets and networks, the motivations, assets and methods of their attackers, and building a set of exercise events to create a meaningful and tolerable experience for the participants which can be shown at every step to be fulfilling the goals of the sponsor.

The problem is, those last screens can be overwhelming in their detail to someone who hasn't seen how the data builds up over time, and the first screens can seem pointless without knowing where you're heading. We opted for a cooking show approach, where we started with a blank exercise and began leading our audience through filling in the first few screens to demonstrate the elements of the user interface. Then we switched to the "baked" version of a completed scenario and proceeded through the screens to show how the data built on itself and connected over time, without making people wait while we typed in data. The final scenario screens were very impressive in this context.

The only other thing I'd like to say about communicating design in this project was our use of a wiki. Since we had gotten buy in around use cases, we retained the use case names and numbers. Each use case appears as a screen, or set of related screens, with a title you can click to bring up a wiki page for that use case. This organization allowed our in-house and external domain experts to begin filling in background about what users should be thinking about to answer the questions in the use case. They could talk about what would be important to consider in different kinds of exercises. We're hoping this will let us get away with designing the tool for the core types of exercises we're targeting, while telling users how they might bend it to encompass exercises with different scope, scale and intent. The wiki/use case combination so far has been marvelous at keeping the user interface and user documentation development linked to the smallest degree necessary.

[engaging experience]

Doug—

Thanks for your amazing account of a successful work process. I would love to see your deliverables sometime, though I assume, given the national security subject matter, they can't be shared. The "cooking show" approach for the client presentation is brilliant, as is the wiki/use case combo. Great ideas we all can use.

Meg