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 …

When creating web and mobile application UIs, what is better: "Flat Design" or "Skeuomorphic Design"?

It depends.

Yes, I know, that's a cop-out, but not really… There are benefits and drawbacks to both, and what your are designing and who you are designing for is just as important as the design "style" ("Flat" or "skeuomorphic") you choose to use.

"Flat" design is a good approach if you want to focus on and provide clean simple UIs, but "Flat" design can sometimes be harder to understand because the familiar visual cues that users expect or look for aren't applied. This is especially true when you are redesigning something that has a "history" with the user. Exhibit A: The tiled UI in Windows 8 strips away the standard conventions users have "learned" over the years, increasing the potential learning curve and cognitive load for the user.

Skeomporphic design provides real world visual metaphors to the UI that can help the user better understand how the application works, thus reducing the time needed for users to "pick up" how the app works (a good example of this is the Notes app in iOS). The flip side to that being useful is when it is done as simple visual "skinning", which does nothing to add value to the user and can come off as garish and out-of-touch. Exhibit B:  The "reel to reel" player view in Apple's Podcast app. How many users alive today ever even SAW a reel-to-reel player in the real world before? Heck, the only reason I recognized it is because I worked in radio in college. It's a visual treatment that is, at best, "neat" – at worst it's a hipsteresque affection.

You can do good work using both styles, and design trends moving away from Skeuomorphic design doesn't mean it's "bad." Bad design can be done in ANY style or approach… Skeuomorphism is just not the trendy style it once was, but it's no better or worse than "Flat" design.

See question on Quora

Should companies with in-house UX teams evaluate their own work or engage external UX consultants to do so?

Bringing in an external consultant to evaluate a team's work is a BAD idea, for several reasons. First off, the consultant can be the best UX professional in the world who makes the most cogent points possible… but he or she will still be considered an "outsider" by many of the in-house design team members. This isn't a criticism, this is human nature: We all have something called "in-group bias", which is the tendency to favor your own group over another. The opposite is out-group bias where, people from a different group are viewed more negatively and their opinions ignored or criticized. An outside consultant is by it's very definition "outside" the group, and having that person be involved in a critical review activity… well, it could end badly (or be ineffectual at best).

I'm a firm advocate of "peer designing" where two designers work together on a project, and this way the design evaluations are a natural part of the design process.

When it comes to formal design evaluation, I maintain the best way to do this is through a design audit against an agreed-upon set of metrics/heuristics… but is done by people IN the team, not outside of it. Keep in mind the personalities at play: I'm my own worse critic, so I beat my own work up in addition to getting feedback from my peers… but not everyone can "detach" themselves from their own work and accept criticism well.

Another obvious way to evaluate designs is to test them with users (making sure the person who designed the work shouldn't facilitate the test, to prevent any unintentional bias).

See question on Quora

What are best practices for participatory design sessions?

Participatory design is a great way to have an engaging conversation with users about a particular task or situation. The main thing to remember  about participatory design is this obvious point: Users aren't designers. During the design session they are going to sketch out screens and workflows, but those artifacts aren't important: the thoughts behind the designs are.

My best practices:

It's a conversation, not a classroom exercise.

Don't look at participatory design as an assignment you give your "students." Consider the design activity an opportunity to have a conversation about the design problem/scenario. You need to do X – how would you see doing X? What process makes sense to you? If you need to enter information to do X, what would it be?

Be clear about the problem space/scenario.

Your time with each participant is important and valuable (they are taking time out of their personal and professional lives to meet with you). To get the most out of that time you need to be clear about the design problem and scenario you will be working on with the participant. Keep that description simple and obvious, to prevent confusion and ambiguity.

Don't judge.

Again, don't judge the designs or the participants – many of them will be very self-conscious about their design and drawing abilities. Don't criticize, even in a joking way. Be positive. And there are no bad ideas… even if the participant comes up with a contraption that would embarrass Rube Goldberg, don't let the participant know that.

Encourage, but don't patronize.

While you shouldn't judge, you also shouldn't be condescending. Be positive and polite but don't overpraise – it can come off as phony and turn off the participant.

Have someone take notes.

Have an assistant to the side take notes and (optimally) video and audio record the session. If the participant is not comfortable being recorded, just take notes. But the key is to capture as much of the conversation as possible. As the facilitator, you shouldn't be trying to capture everything as you go, you should be responding to the participant – again, it's a conversation.

See question on Quora

What is the next frontier in mobile UX/UI design?

Three things that are going to be a big focus for mobile UX/UI designers in the years to come:

Voice Interaction: Accessing information from your mobile device or the cloud through speech is here now, but we "turn it on" to do so. I expect this to change in the future, and that your mobile phone to always be "on call" and "wake up" when spoken too. I also expect the information and functions that will be accessed through voice commands to become more complex, useful and proactive: think "digital butler." Not a lot of "UI design" here, but a lot of UX design thought needs to go into making these experiences work seamlessly and well.

Smart Devices: See the "digital butler" note above, and think "service design" for end-users… smart devices that learn suggest and help (sending a text to someone if you are running late for a meeting, for example.) Again, more process and AI workflows than UI.

Extending and/or tethering: Think "wearable computers", with devices like the Pebble wristwatch that connects to your mobile phone via low-powered bluetooth, allowing the user to make calls or see messages on his or her wrist. Also think about how mobile devices can engage with devices or locations in your home (opening a grocery list app when you stand next to your pantry for a long while, or "talking" to your smart TV while you are watching a show). Lots of potential UIs that need designing here…

See question on Quora

What user experience means to me, and how I approach the design process

I may sound like Pollyanna, but to me user experience design is a way to make the world a better place.

OK, so it's not like we UX folk are curing cancer, or finding new sources of energy, or stopping world hunger… but what we do makes a real difference in people's lives. If you can make an application or design a system that makes people's day-to-day existence just a little better, reducing stress and/or saving them time and money… that's making things better, one small interaction at a time.

One of my most successful design projects was redesigning the way people signed up for electronic bills through their banks, letting them "go paperless". By simplifying the process and better explaining the value to customers, we increased adoption by a significant amount. This lead to costs savings and increased profitability for my company and it's clients, but also reduced clutter in people's lives and saved thousands of acres of trees that would have been turned into billing statements otherwise. A big win all around.

How I design starts and ends with the same thing: data. Sherlock Holmes famously said "I can not make bricks without clay!" referring to his inability to solve a case without facts, and I have a similar need. Who are the users? What is the core task they are trying to accomplish? What are the business goals of the group I am designing for? Where do they use the app/function I am designing? And so on. I can't start without knowing some key things like the above.

When it comes to how I approach design, I use a "rigidly flexible" process. The general process is consistent – research, sketch, test, refine, document – but the tactics change depending on the project and timeline. I've written a lot about these tactics here and on my blog josephdickerson.com, and instead of repeating myself recommend you check my writing out for some specific details.

And finally, when it comes to design tools, it's not the specific tools that make you a good designer… it's how you use them (and making sure the tools "fit" you). An amazingly talented designer who uses a tool that is difficult to use or doesn't "suit" him or her can produce bad design, because the tool "gets in the way." Try out as many tools as you can to find the ones that work for you.

See question on Quora