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?

4 Answers 4


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.

  • 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. Commented Nov 10, 2010 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. Commented Nov 11, 2010 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). Commented Nov 11, 2010 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. Commented Nov 15, 2010 at 22:17

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.

  • +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. Commented Nov 8, 2010 at 6:58

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.


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?

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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