User interface design

Good user interface design is not that complicated, but you have to pay attention.  So, for example, user interface inspections are a great tool for validating an interface design, and they’re simple to do – get some users of the program, sit them down in front of the screens, and watch them work through it.  Notice when they get confused or lost.  That’s really all there is to it.  You can ask questions like, “OK, what are you looking for on this page?”  “What are your assumptions?”.  Find out what some of your users are thinking and wanting when they use the program, by watching them and talking to them.  This is not rocket science.

But it is rare, and when it isn’t done, the resulting user interfaces can be incredibly frustrating to learn and use.  I have some rules that I find useful for creating good programs, but they are odd rules because they are not things you can just do.  To get anything out of them, you have to commit to them, and continually re-commit.

1) Center the program on the user experience.

One thing this means is that we begin the project by describing use cases and interfaces.  This is commonsense, and it follows a long tradition that says “think about requirements first”.  Programmers talk about “use cases”, and use the concept of use cases, but often this is done haphazardly.  The use case list is on the backs of envelopes, and the screen designs are block drawings with what it’s fair to say is not a lot of detail.  On a small project, the idea of having a published list of use cases, that is intended to be complete, with written descriptions and linked to a complete set of detailed screen designs – this requires a lot of discipline.  At the beginning of a project, what’s most salient in programmer’s minds is the technologies that they are going to have to learn.  So they describe that use case, and a few others, and immediately start tackling the technical challenges.  This isn’t irrational, but it generally means that there is never a complete, considered list of use cases, and there isn’t really any design of the screens – they are “designed” as they are being coded.

This is one of the advantages of agile programming.  It lets you have your cake and eat it too, in that you can develop a small group of use cases in a logical order – starting with interface descriptions and proceeding through code and test.  So you can follow a user centered process and still address technical questions early.

This rule – center the program on the user experience – is always new.  For example, as code is finished, we want to do code reviews.  It’s often useful to start a code review at the user interface level.  We ask what is the use case?  Why is this code being activated?  Get that clear in your minds.  Then look at the code.

2. Be proactive about getting user input.  Do UI inspections.

You’re going to be listening to users sooner or later – why not take the initiative and do it early?

I don’t know why people don’t do this more.  If the program is seen as a user experience, you have to do user interface inspections – that’s just a matter of basing your design on evidence.  So why doesn’t everybody do it?

Really, it’s just outside of the path that programmer’s minds take when they start thinking about a problem.  They will be responsible for the code, and they are hired to solve code problems, so that is what they think about.  Unless a management decision builds in the user voice, it won’t guide the design, and what you’ll get will be a bunch of menus grouped according to some pattern, with the command you want just not there.

There is one caveat here – I have seen projects in which a “user” is added to the design team, and that person takes a leading role in actually designing the interface.  There is no reason to assume that such a person will take the needs of all the users into account.  If that person is opinionated or status conscious, she can bring office politics into the design in a destructive way.  Watching and consulting with a variety of users is better than obeying one of them.

3. Be complete in your description of use cases.

A name is not a description.  A lot of programmers are very sketchy in their descriptions of use cases.  I don’t know what to say about this.  The thrill of solving intricate puzzles gets old.  Writing programs that work for people doesn’t get old.  Write out the use cases.  Draw the screens.  Get down to the details.  Use paper.  It’s better to have details on paper than a fancy screen prototype that leaves things out.


Leave a Reply

Your email address will not be published.