How do you design a user interface (UI) to be understandable and easy to interact with? In this series, I’ll give some thoughts on good design, combined with examples.
This series is intended as practical UI design advice for small teams or individual developers. Many larger teams or companies have UX staff who can advise or run the process of UI design. Typically, a UI design process would be involved as part of the feature development process, something like:
But many teams don’t have access to a UX expert. The ‘UX team’ dot points above will be replaced by developers or product managers with a much wider focus. If that applies to you, then this article is practical advice to go from an initial concept (whether that’s a UI mockup, or a first-version UI created by a developer as they implement the feature) and refine it. It may not be the approach taken in a large corporation, and it won’t address graphic design or ‘good looks’ until the very final blog post, but these steps will teach you principles or give you guidelines for creating something both modern and highly usable by your users.
We’ll start with an example of a bad UI, one based on a real-world dialog I saw recently. For the sake of this article, let’s assume this UI is either a draft / first-run UI created by a developer as the feature is being developed, or is the first wireframe or mockup of a UI as you create the specification for an upcoming feature. It may also be an existing UI that you want to improve.
However the UI is arrived at, throughout this series we’ll improve it, examining useful principles you can use to either improve your own UIs or create great new ones, in practice. If it is an existing UI, this refines it; if it is a mockup, this illustrates practical approach to the review and refinement process to arrive at a final mockup and behaviour for your feature.
What do we mean by UI design? And does it overlap with UX?
UI design is simply designing a user interface. UX is a term for ‘user experience’. Effectively, UX is the overall effect of using an application. Was it clear? Frustrating? Pleasant to look at? (Note those three things all speak to different aspects of the experience - clarity, intuitiveness or understandability, and graphic design.) It’s a broad term, but ultimately you want your application to have good UX in that you want your users to feel happy using it. Providing an intuitive flow to your application is key for new user adoption and retention, and well thought out UX provides that. That’s also a reason why a growing number of companies perform UX testing with focus groups during their application development cycle to ensure a good user experience.
UI design is a key part, but is not the whole, of good UX. This series focuses only on designing your user interfaces.
In addition, this series focuses on practical UI refinement, and on usability. Shiny good looks are left to the very last post.
Let’s begin with some basic principles that will be elaborated on through the series. We will look at specifics as we go through the series and improve the example ‘bad’ dialog in practice.
Some higher-level principles are:
The last two points are related to ‘intuitive UI design’, something often mentioned, meaning a UI that users can pick up and understand without preconceptions. A large amount of what is ascribed to making a UI ‘intuitive’ is in fact not a new concept easily understood; it’s familiarity, meaning people ‘intuitively understand it’ not because of some magic design that makes it truly intuitive, but because they already know how to use it, even if they don’t realise that.
Almost no-one invents truly intuitive new paradigms; it happens maybe once or twice a decade. Many of the criticisms of current UI design trends, such as Material Design, revolve around removing cues that provide familiarity.
When the iPhone was released, Apple had in-phone training to teach users the new paradigms. Many things were intuitive: they were modeled on physical interaction (skeuomorphism), such as buttons being 3D and looking as though pressable, or lists being able to be flicked to scroll.
‘Pull to refresh’, one of the most common mobile interactions today, was invented in 2008 by Loren Brichter for Tweetie, a Twitter client. It’s a great example of a non-skeuomorphic interaction paradigm, in that in the real world lists do not have items appear at the top, but scrolling to the top of a time-sorted list is the obvious place to discover more recent items.
I recently saw a friend, an Android user, pick up my iPhone and try to go ‘back’. For a few seconds, their thumb hovered over the bottom left of the screen and they audibly said, ‘ah…’ in a confused tone, before hitting the Back button on the top left.
Is this an intuitive UI? From learning, from use of Android, they expected to go back through interaction on the bottom left of the screen. There are a few interesting things to unpack here:
The last point is one of the most significant criticisms of current UI design trends: removal of subtle indicators. This isn’t always a problem - consider toolbars in desktop apps, where in the late nineties, starting with Office 97, they were rendered without 3D borders by default. Later, even the mouseover 3D borders were removed and today it’s common for them just to highlight with a solid colour when moused over. People have learned that images in a horizontal row are usually clickable, so any toolbar today is ‘intuitive’.
Many current trends have images in many random places, some of which can be clicked and some cannot. There is no way to visually tell the difference. That is unintuitive design.
In this situation, the iOS button is both standard in all system apps, and has text. Both of these mitigate the loss of visual indication of interactivity from earlier iOS designs where interactivity was indicated by drawing it like a physically interactable item, a button. (This is called skeuomorphism: physical metaphors in digital, 2D UIs.)
This is Google Calendar’s popup window when clicking on an event:
It has a title, and some details in smaller text.
There is also a row of buttons to interact with the event in a number of ways at the top: close, delete, email, and a hamburger item to see more: a toolbar, a familiar interaction.
How do you edit the event?
The Edit button is nowhere near any other interaction. It is halfway between the title and details, and has almost the same background colour as the title background, making it hard to visually spot - it does not stand out.
What’s wrong with this?
A better design would place the edit button near other interaction but, recognising it is the most important and likely to be clicked of all interactions, make it more prominent:
Here, Edit is an action on the toolbar like all other actions. It is found when looking at the list of interactions: it is no longer standalone and needing to be discovered separately. Because it is the most important, it is placed first, and it is annotated with a text label so it is clear - you do not need to interpret the pencil icon to know what it does.
The original is a great example of an unintuitive UI: a specific interaction needs to be learned, and you cannot apply rules you already know (toolbar buttons in a row, look for interaction with other interactions) to this case, nor is it visually distinct or called out. It is a once-off, unique action, camouflaged.
Those principles may sound good, but describing visual design in words is not as useful as showing it implemented in practice to turn a badly designed UI into a clean, modern, understandable and intuitive UI. Over the next couple of posts, we’ll look at an example badly designed UI and improve it, following the principles above.
The following image is inspired by a real-world dialog I saw recently. This screen, as shown below, has been anonymised and has an entirely made-up purpose: it is a dialog to export books to file, with various formatting options. Have a look:
This UI presents a list of books. For the selected one, a list of chapters; then some formatting options, and some fairly standard dialog buttons. It is not complex. Yet, looking at it, a user might have a number of questions:
Questions like these indicate confusion. This is a simple UI, with only a few controls, yet it creates uncertainty. You want to empower your users, and make them feel they understand what they’re interacting with and what they’re doing. A dialog that causes questions is a good indication that the UI is suffering from some design problems.
We will use this dialog as our starting point, and improve it throughout the series.
Next post, we’ll see some guidelines on how to analyse a UI and discover an underlying structure that can be clearly presented. That structure can then be reflected in the UI design. The ‘bad’ UI mockup we have will be refined.
Until then, the exercise of asking questions about a UI is a good one. Try picking one of the dialogs in an app of yours, and approach it trying to know nothing about it. What questions, like the above list, can you come up with? Pretend you’re tired, have not yet had a coffee, and are unfamiliar with the app -- and see what questions you might ask.
Update Oct 3: Part 2 of this Great UX Design series is published. Read it here!
Reduce development time and get to market faster with RAD Studio, Delphi, or C++Builder. Design. Code. Compile. Deploy.
Start Free Trial
Free Delphi Community Edition
Free C++Builder Community Edition