July 11, 2007

...Learn TDD with Codemanship

UI Design Happens AFTER You've Understood The Logic

Whinge. Moan. Gripe.

It's just one of those days...

Today I'm on my hobby horse about how user interface and interaction design fits into the software development process.

Now let's get one thing absolutely straight right from the start: UI design is not part of the requirements definition process. It's system design - albeit just the interface to the system. It is part of the realisation of the system.

And let's get another thing straight, while we're about it: use case descriptions - or "user stories", or whatever we're calling them this week - are interaction designs. They describe how users interact with the system to achieve some goal. The goals are the requirements, not the interactions.

So when we're writing use case descriptions, we are designing the system - making choices about how a user can do what they need to do using the system. And certainly when we do UI mock-ups or storyboards or screenflows, we are doing system design, too - and actually quite detailed system design, at that.

And as any great sales person will tell you, the worst time to propose a solution is at the beginning, because your solution will almost certainly be wrong.

That's not to say that we should agonise over trying to get the UI design right first time. We will still need to take our best guess and then, following a process of evolutionary design, iterate towards the optimum solution we can achieve with the time and resources available to us.

But, just as it pays to line up your shot before you hit the golf ball* (even though you will probably still need to take a few more shots to get it into the hole), in UI design it helps to do a little analysis and planning before you're ready to create your first attempt at a UI design for whatever use case you're working on.

Here's how I would recommend you do it - and this is just me, mind you:

1. Identify your users and the things they'll be using the system to achieve (usage scenarios, use cases, user stories etc). Do NOT try to flesh them out at this point.

2. For a specific usage scenario - the most important one in your backlog of work - clearly articulate the functional goal of the use case, so it is testable (i.e., agree the post-condition of the use case). You should now have a list of "effects" - things that will happen to the objects in the system (and maybe objects in other systems, where integration is required) - as a result of invoking this usage scenario.

3. Now write a stripped-down, bare-essential description of how the user interacts with the system - as if they could literally reach in and manipulate the objects directly (so no need to talk about screens or buttons or wotnot) - to achieve these effects. Make sure you tick off every unique effect during the course of the sequence of user-system interactions. It is vitally important at this early stage to describe these interactions purely in terms of the user's internal conceptual model of the application domain.

4. Sketch the logic of these interactions - what are the objects involved? What is happening to them?

5. Once you have a testable, logical and object oriented description of the interaction design for this usage scenario, then - and only then - should you consider how this will be presented to the user. A good way to translate your logical OO model into a visual user interface is to map components of you model - objects, attributes, relationships, states, operations - onto graphical symbols, creating a visual language which you could implement in your chosen technology. You could, of course, reuse a ready-made visual language like WinForms on .NET or Swing on Java. Or HTML. Or XAML. Or Silverlight. It's up to you.


A User Interface defines a visual language just like UML does

But I find off-the-shelf visualisations a little staid and unrewarding. It's the new and exciting UI's that make users gasp and potentially create the most rewarding user experiences. Give serious consideration - if time and resources allow - to creating a visual language that is as close to the way the application domain looks in real life as you can. So if you're building a VoIP GUI, why not make it look like a telephone? Or if you're creating an online betting shop, why not show race course maps instead of a boring list of race courses, and the patterned shirt and caps of runners and riders?

Once you've established a visual language through which the users can interact, you can then translate you logical interaction scenarios into physical UI designs - storyboards, if you like, that are described using that visual language.

Once you've hit upon an initial UI design, the next step is to get concrete, objective feedback about the quality of it, and iterate the UI design until you've optimised along the axes of usability you're aiming for.

Of course, if we were being really Agile about this, we would talk about UI refactoring - in much the same way that we talk about refactoring code during test-driven development to iterate towards the optimum design. And, since we're being feedback-driven to a larger degree, that would be quite right.

Alas, as yet I've not seen much that's practical or useful about "UI refactoring" on the Interweb. I think that will need some thought, though, as it's apparent that poor UI design afflicts projects of all types - Agile or Plan-driven.




* Yes, another bloody golf analogy...
Posted 13 years, 5 months ago on July 11, 2007