UX101: On user interface design

All you have learned about user research, information architecture, and interaction design is the foundation for the next step – execution. Taking all you have learned and defined and then designing screens that let users accomplish tasks and get things done. User interface design…  it’s where the rubber hits the road.

But compared to everything else you have done so far in the design process, it’s actually the easy part.

Whenever I say that many of my peers are flabbergasted by the comment. “Interface design isn’t easy!” one once exclaimed in response. “If you do it wrong the whole experience falls apart!” True enough, but it’s not like we are starting from a blank slate… We already KNOW what works and doesn’t.

How so? Because user interface design isn’t a “new” thing. Designers have been designing screens and “dashboards” for decades, and this has built a wealth of knowledge and standards we can apply in the act of interface design. Heck, Paul Fitts defined the famous law named in his honor (on control size and placement) over seventy years ago!

There are best practices like Fitts’ Law (many that I have covered in other articles here) that we UX’ers can leverage and use. On top of that are multiple design heuristics that we can follow and compare any proposed UI designs against.

When I look at younger designers try and be “original”, they often come up with user interface designs that don’t work BECAUSE they don’t use that collective knowledge to inform their designs. I state this not to discount original thought, but to properly direct it. If there are best practices on how to build a dashboard, why ignore them and come up with your own? Designers, focus your creativity to better use.

Understand your users, then start designing

So, how do you get started? A clear understanding of the user and their needs is key. This is why you did user research in the first place – don’t lose sight of that understanding. You may have already defined and documented user needs though journey maps or storyboards, but if you haven’t… take the time to do so. Even a one-paragraph scenario can give you basic context and understanding.

To make sure you are ready to start fleshing out your screens, make sure you have the answer to the following questions:

Who is this design for?

What will they be doing?

When will they use it (how often)?

Where will they use it?

Why would they use it (as opposed to another process or application)?

This grounds your design and lets you focus on the user rather than get bogged down in trivial details. The time to sweat those details will come later – focus on getting a good first attempt down.

I prefer to do my “first cut” at an interface design on paper or on a whiteboard, because it’s less “permanent.” By sketching, you can erase or throw away ideas without much angst – if you are building out designs on the computer many people invest a lot of emotional and intellectual activity in that and so they are more reluctant to “throw away” work done there. As I’ve said before, use the tool that works for you, but be careful not to be too satisfied with your initial effort… because it will change.

As you are doing this first set of sketches (also known by many as “concept designs”), leverage your experience and knowledge to create what you think works – if you want to look at how other sites or applications do things, feel free. As I started earlier, there are a lot of really good designs in the world, and you should take full advantage of what’s out there.

When it comes to what you are designing, there is a difference between content sites and applications. To state the obvious…  they are not the same thing. There are different user goals and focus for content sites – it’s about consuming vs. doing. While content sites will still have functionality, these interactive elements will be to support and supplement consumption, and should be placed and prioritized as such.  Again (and obviously), support the appropriate user focus with your design.

Once you have done a first cut at the conceptual design, this is where you get user feedback. You can formally or informally test your designs with people, and the key focus at this point is to make sure the interface design aligns and supports what users want to do and “makes sense” to them.  If you show a design to someone and they can’t tell you what they can do with it or how it works, you need to go back to the drawing board.

Detailed design

After gaining some confidence that your concept design is understandable and usable, this is when you flesh out the design and add additional detail. There are multiple tools this can be done in, from Axure to Irise to Visio and Omnigraffle. Again, use the tool that works best for you (and if you are part of a larger design team, the tool that is compatible with what they have or need).

As you flesh out your detailed interface designs, leverage one of the many pattern libraries that exist. These pattern libraries detail out scores of UI elements and rules on how to use them. These patterns are usually informed by best practices from web sites and applications, and so when you apply these elements in you are design you are going to be providing elements and behavior that are familiar to users, reducing confusion and cognitive load.

The most well-known pattern library comes from Yahoo, and some design tools even allow you to import these UI elements into your designs. Depending on the size of the project, you can even “roll your own” and build out your own pattern library as a reference for other designers and developers. As noted above, leverage what already works and repurpose design elements to flesh out your design.

After you have fleshed out your designs in detail, you will want to test them again, this time making them a interactive as possible. Many of the design tools listed above will allow you to create an interactive prototype from your designs, but if you are not comfortable with doing this it may be the time to request development build-out a functional prototype from your designs (Of course, if you are in an Agile software project they may have already started doing this).

After you have such a prototype, you test it – in a much more formal way than the earlier conceptual design. More on how to do that next …