Processes and Patterns

I don't know how many times I've heard arguments about the best process for designing user interfaces, particularly at large companies. What's particularly funny is that many proponents of different processes claim that their process is the best. But, if there are so many processes, how can there really be a best one? It's crazy -- there can't possibly be a single best process for designing user interfaces any more than there is a single best computer programming language for all purposes.

Design Patterns

If you're experienced at all in software, you've certainly heard about design patterns. I've previously discussed the Gang of Four's seminal Design Patterns book and Jennifer Tidwell's Designing Interfaces is an excellent book on UI design patterns. To me, these books are most effective sitting on your shelf.

I'm sure that sounds odd, but I don't think that these are reference books. The point of pattern-oriented design of any sort is to recognize patterns that you have used before (or, perhaps, others have used before) and not re-invent the wheel. If you use the pattern book as a reference book -- if you browse through it looking for a pattern that matches what you are doing, then you haven't really internalized the principles and you are just as likely to pick the wrong pattern as the right one. The fact that there are growing pattern libraries of thousands of design patterns is some indication that much of what we do isn't going to be in the book.

So, by all means, pick up these books and read them. But I really mean read them. Learn from them and then put them away. I will add the caveat that this is much more relevant in the case of UI patterns than in algorithmic patterns -- in the latter case, you could know you need a certain pattern but want a refresher on implementation details.

Back to Processes

By now you're probably wondering what design patterns have to do with UI design processes. Well, it's the same thing. The truth is that there are many different processes for designing user interfaces and the way to produce the best result is to pick the right process for the task at hand.

Don't worry, I'm not going to write a book on design processes and suggest that you buy it. But, next time you start a design project, think about how you start. Should you start by ...

• ... drawing pictures of what users will see?
• ... interviewing users and find out what they do without your product?
• ... observing users during the course of their day?
• ... making a list of every potential feature or sub-feature you can think of?
• ... drawing flowcharts of how users will interact with your system?
• ... creating a "road map" of future generations of your product?
• ... making a list of scenarios describing what your target users will do?
• ... defining a persona (or several) that describes your target users?

I'll add that I think those last two are two of the most overused starting points. That doesn't mean they're wrong, just that they get picked a lot more often than they should because they've been well publicized.

The most important part of the process is thinking about the process and picking the one that fits the problem at hand. And, certainly, don't refer to the list above, as it's woefully incomplete. If you've read this, I'll be quite happy if you put this blog post on the shelf.