How do you define interactions in a mockup?

Question

I'm both a programmer and a UX/UI designer. When I design things, I generally make static images of what the interface will look like. The problem is, most UI's aren't static; they change and resize from user input. Of course, I know exactly how the interface should respond to such input, but for large projects the client and other programmers have to be able to take my mockups and understand the interactions. So how do you show in a mockup how your design interacts and responds to the user?

Answer 1

The best way to describe interaction is to model it with an interactive prototype.

There are various prototyping tools such as Axure or the one we're developing, Handcraft. Whichever one you use, the point is that they allow you to show your client, peers, etc. what happens when you interact with elements in the mockup. You'll get much better results using a prototype to show interactivity than you will with a clickable mockup, however. It's possible to show basic state changes with mockups, and there's a phase in the design process where this can be useful, but there are some things that are hard to describe with static images, such as animations (vital in certain situations), responsiveness (a key element of interactivity) and in the case of native or web apps, the "feel" of using that particular platform.

37signals talks a lot about how they skip wireframes and go straight to HTML. I wrote a blog post a few months ago about a talk they gave in which they described their process.

However, if you want to enrich static mockups, Jakub Linowski's Interactive Sketching Notation is a good starting point for a UML-like way to describe interaction:

See Pros/cons of PSD vs HTML mockups for a similar discussion:

If you're building a web site or application, HTML mockups are far superior because you're designing the mockup in the format as close to the final product as possible. This allows you to set expectations much more easily, it constrains you to just what's possible in the final product, and it affords much greater flexibility.

Answer 2

When an interactive mock-up isn't an option, try text. You can add numbers that point at parts of the static image or wireframe, and then provide interaction notes for each number.

     

Above: an example of a pointing number.

Answer 3

If you don't have the option of something like Axure (or another interactive prototyping tool or even HTML or Flash), I think your best bet is to wireframe the "standard" or "default" view, and then show in additional wires the alternate states of particular modules.

In my experience relying on text-based annotations to convey the changes is usually insufficient -- I've done too many projects where perfectly annotated wireframes were misunderstood or built incorrectly because clients/developers/etc. missed important textual details that would've been better captured visually.

Answer 4

I know this one is half a year old, but since nobody has mentioned it yet, I will:

Bill Buxton has written a book called "Sketching User Experiences" which deals with interaction design's "sketching" problem - how can we convey interaction concepts and patterns in an explorative manner, i.e. quickly and low-cost, but not too abstract?