What is the usual way to specify a GUI?

Question

What is the typical or most effective way to specify the design decisions and interaction patterns of a specific application's GUI?

I began to realize I do not really know what the parts of a precise GUI or User Interface Specification are.

• How do I document the design decisions, especially those I need to communicate to with the developers?
• How do I document what happens after a button press/Gesture or other interaction?

Answer 1

I'd recommend reading Communicating Design, which tells it about the specifics of how a UI is usually documented.

In general, there are layers of documentation:

• Who gets in contact with the system (context diagrams and/or personas)
• What the system is used for by them (use case listings, perhaps user stories)
• What is the flow of usage for each use case (flow diagrams)
• How the screens look like in each steps (wireframes)
• What are the visual and interaction patterns employed (pattern library)
• What is the actual visual language to be used (widget library, actual layouts)

I'd say, flow diagrams, wireframes and widgets are the most important ones perhaps.

These are built on top of each other: personas have goals, in order to reach these goals, they use the system for specific things (use cases), which in turn have a kind of flow or process (flow diagrams), the screen themselves have to look somehow (wireframes), there should be a kind of consistency between them (patterns), and these have to be implemented (widgets and layouts).

For a famous inside-organization Pattern library, look at the Yahoo Pattern Library

For wireframing, look at Balsamiq Mockups, Konigi Wireframes, Wireframe Showcase.

Answer 2

It's funny that we're very user centric about the systems we build - but not so much about the artefacts we produce.

The most effective way to specify the design decisions and interaction patterns depends on who you're communicating with and why. There is no right way - there's only a right way in some particular context.

For example if you're co-located with the rest of the product development team you may well find that the best way to communicate is by... well... talking, or pairing with developers, or by some quick sketches on the whiteboard.

If you're dealing with producing something for an outsourced team that hasn't even been created yet, and by the time it is you'll be off working on another project, then you might be looking at something like the full suite of artefacts from http://unify.eightshapes.com/

Treat documentation like any other project - do what the end-user needs.

Answer 3

These are not exactly what you are asking for, but might be useful in what you are trying to achieve -

1. Wireframing - Here is a list of Sample Wireframing tools. Although mostly wireframing is done for web designing, but still some ideas might be useful.

2. Protyping - You can try this Protyping tool and the Pencil which is something like both.

Might be a little off topic, but this discussion. can also give a little insight.