Communicating Interaction

I think interface design, the design of visible items on a page or screen, is pretty well understood. Whether you learn it viscerally through art school, by repetition through design school, or by rote through some digital design program, the basics have been well understood for some centuries, and apply perfectly well to print, broadcast or interactive designs.

Interaction design is still being developed. Sure, some basic underpinnings go back to maybe the 1920s, but designing open-ended systems like we mostly work on anymore (web and application design) is still evolving. There are not even universally-accepted job titles and document descriptions.

I can, without stretching at all, say that I have been designing interactive systems for 15 years. By no means were the first years all good – or even highly-conceived but misguided – but for probably the past 6-7 I have come to certain understandings which have begun to prove themselves enough they are beginning to become Laws of Interaction Design. At least for me.

Artifacts and documents

Out of design work (and from now on, design means interaction design) are produced a number of documents. In some contexts I will call these "artifacts," which is a wonderful name for the superset of every sort of file that is saved for a project.

But increasingly I have become certain that design produces documents, and a key test of whether something is a "document" is that it can be printed. It doesn't actually have to be printed, but that fact that it can, and that it preserves the essence of it's communicative ability when printed on paper, makes it a document worthy of carrying design.

There is probably a little of my love of paper in there, but really it's all pragmatic. I have worked with plenty of teams on site, or with clever electronic distribution systems. And with too many remote teams I never see. And either way, amazing amounts of paper seem to get created. All too often, outside of your control. Beautiful animated renderings are printed on old, letter-sized black & white lasers, marked up, and faxed around. Yes, faxes are still in common use by your client.

And this works well for people. Even the Nintendo DS generation is comfortable writing on paper, shuffling, comparing, attaching Post Its®. You are, all in all, better off internalizing this, and designing for paper consumption.

And, yes, there is prototyping

In much the way no one seems to know what a persona is anymore, prototyping is being turned into a monster, that seeks to do far more than it really should.

Prototypes are functional models. They may not be very functional, and almost always should not be. Stub data, single happy-path flows, comped graphics. But they are functional in some way. To build a functional anything, you need a design. Quick, try firing up the lathe and making something out of metal. There is design before prototyping, always.

So admit it, and use prototypes for their proper use. Explore design ideas, test them out on users. Run them by marketing and brand. But please do not give them to developers and expect anything like it to come out the other end.

Drawing Interaction

I strongly feel that design is tightly coupled to actually putting ideas on paper. For GUI of any sort you need to draw to execute the design, as well as to communicate to the consumers.

So, my design tips for interaction drawing are very closely related to mindset issues. Keep these in mind during design, and be sure to depict them when drawing. If the two activities are one and the same, all the better.

1. You must think...in states — Forget the site or app, forget the screen. For interactive systems, especially as refreshless-dynamicism increases, the state is most important. If something changes – due to context or user input – the screen is going to change, and you need to depict that. It's easy to go overboard; don't worry about transitions, for example, just limit yourself to states where the user is most likely to interact with the application.
2. Show your moves — Arrows are your friends. If a link goes somewhere, add an arrow, and send it over to that state or screen. If it's too far away, just label the end point in your naming scheme. However you do it, everything needs to link up. The business owner, developer or tester should be able to run their finger or hiliter along your diagram and follow every path, link, action and interation.
3. Call a button a button — This is a task done at the wireframe level. Wireframes vary a lot in fidelity; simply the fact that we're showing this much interaction makes them a lot too detailed for many folks. But the key is that they are not final design. Use this to your advantage. Don't be coy about what is a link, or a button or a pulldown. Make sure everyone knows they are links, buttons and pulldowns. Use the common, learned vocabulary of such interaction items, such as my mobile design elements to make clear, even cartoon-like representations of everything on the page.
4. Show it all off — If it's under your control, and the user interacts with it, show it. For mobiles, there better be a softkey menu attached to each screen. If there is time before transitioning, show it graphically on the flow arrow. Make sure everything is there, on that page, and is at least recognizable without too much reading.
5. No one reads anymore — I can count on one hand the number of testers who have come back asking for clarification on the wording of a detailed design document. And only once did a developer ever ask the same. These are complex systems, so you will make errors; the fact no one asks about them means no one is reading it. If they are not reading it, they are not designing and developing the technical systems correctly. Make your drawing talk for you. It's an interactive, graphical interface system, so you ought to be able to depict it graphically. Notes are fine, but it should be clear from graphic representations generally what the note will say, and that there is a note to be read for clarity.

Artifact errors

I'd love to be able to chat about all of this in a manner intended to get pure and perfect design. But I want to emphasize again it's all practical, and intended to get your design produced.

A recent product I designed had a key feature that was so simple it was not immediately clear. The primary path to perform the action was automatic; the user did it without even really explicitly trying. There was a sort of backup path, that was somewhat convoluted and difficult, to address some special cases. But the way I depicted it, this difficult path is the only one really visible on the design document. It took a long time to make the product owner happy again. Eventually he was very happy, but this looked like a huge error on my part.

I tend to call these "artifact errors." It wasn't really an error, but appeared to be so due to documentation. In this case, it "just" annoyed the client. What if it slipped by them, and was instead not well understood by the developers, so this key feature was essentially left out?

I learned my lesson, again, and have tweaked my document creation process to try to depict such non-interaction interactivity more clearly. I hope. It's a constant learning process, and every time I think I know enough to sit down and write a book, some project comes by and throws a wrench into the works again.