Take the 2-minute tour ×
User Experience Stack Exchange is a question and answer site for user experience researchers and experts. It's 100% free, no registration required.

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?

share|improve this question
add comment

4 Answers

up vote 21 down vote accepted

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:

interactive sketching notation

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.

share|improve this answer
1  
Another tool that is available for interactive mockups is Flash Catalyst. Though I've never used it myself, so I can't vouch for its effectiveness. –  Lèse majesté Nov 10 '10 at 1:25
    
Thanks for the write up. Very comprehensive answer. Although I am primarily a Flex/Flash developer, going straight to a deliverable has some great benefits. –  Jonathan Dumaine Nov 11 '10 at 2:14
    
@Lèse I haven't used Catalyst yet either, although I suppose I should give it a try at some point--me also being a developer, I'm entirely scared of the code that it "generates" for use in Flash Builder (roots from Dreamweaver's generated html/css markup). –  Jonathan Dumaine Nov 11 '10 at 2:15
    
Update: I tried using Catalyst. It's a complete waste. It's actually less useful than Flash Builder's design mode in my opinion. You can only use it to convert artwork into components, not an application. There's no way to visually make Groups or Containers. –  Jonathan Dumaine Nov 15 '10 at 22:17
add comment

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.

     alt text

Above: an example of a pointing number.

share|improve this answer
    
+1 - I was going to suggest this very answer ;-) It's how I do my first cut at wireframes when I need to communicate interaction to the client or team. It's also very useful for programmers to begin technical design. –  jameswanless Nov 8 '10 at 6:58
add comment

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.

share|improve this answer
add comment

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?

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.