When you’re making software, you might be very eager to make it as functional as possible. Of course, as you add more and more functions to your software, you’ll know how it works, and how to navigate it. After all, you made it! If you’re planning for other people to use it, however, will they be able to use it too? It may seem obvious to you, but for others, it may not be so clear cut!
This is the goal of a good UI (User Interface); to make software accessible to everyone who wants to use it. When making your software, it’s good practice to keep the average user in mind and design your software so that it doesn’t confuse people.
So, what makes good UI? To answer this, let’s pretend we’re creating the sign-up sheet for a video game indie developer convention. People can sign up to the convention either as a visitor ($20 entry fee) or a developer showing off their game ($50 entry fee). We want to know their name, gender, date of birth, and country of origin. If they’re a developer, they also need to list the title and genre of their game. Visitors don’t need to list their game details; they don’t have one to show off in the first place!
When designing UI, you don’t need any special software to do it. A pencil and paper (either real or digital!) is all you need to start doodling ideas and refining your thoughts. Here is the initial design brief I drew for our first hand drawn example form.
So, how can this be improved?
First of all, something is immediately missing from this: buttons!
Specifically, a Back and a Submit button. You should always ensure that users can go back to past screens, as well as an obvious way to move to the next one. We don’t want people getting stuck on this page without being able to return!
What’s next? Let’s look at how cluttered all this looks. Good UI sorts the elements into a neat order, so users don’t have to ‘hunt around’ to look for fields to input data into. So, let’s organise the elements in a list format.
But even then, it’s would be a little messy and disorganised. For instance, why does it ask for Country and City before it asks for the person’s age? So, let’s categorise the fields under the following types: Personal Details, Country of Origin and Attendance Status. Let’s also separate the developer-only part into its own area, so visitors know they don’t need a game title or genre to fill out the form.
Now, it looks like this second hand drawn UI.
Looking better, but we’re still not done!
Let’s take a look at that strange Date of Birth part of the form. Why are there separate fields for each element of the date of birth? Wouldn’t it be better if it was just combined into one ‘date of birth’ field? We can then also calculate age from the date of birth field, so we don’t need the age field either. The ability to combine multiple elements into one is good UI design, so always make sure you keep elements that share a factor tied up and not spread out.
Now let’s take a look at the text boxes we have on this form. There’s a lot, isn’t there? This is going to require a lot of typing for our user. We can make things even easier by removing the need to type in every single answer.
First, let’s look at the Gender, Attendance Status and Payment Amount. We know these fields in particular only has a few answers to them; male, female, and other for gender; visitor or developer for attendance status; and $20 or $50 for the payment. Given the options are so low, we can present them as check-boxes. We have to make sure that users are only allowed to tick one box for each option, or we’ll end up receiving some very confusing data!
For Country, City, and Date of Birth let’s make them drop down boxes. Country will list all the countries in the world, City will display the cities depending on what the user selected in Country, and Date of Birth will be three drop-downs where people can select their year, month and day.
Here’s the interesting thing; doing this doesn’t just make it easier for the user to use. It also makes it easier for when collecting the data, too! Given how the user only has set options to choose from, it normalizes the answers we receive when they submit their form.
If someone is from the US, they use the drop-down box and select the ‘US’ option. This means we won’t be inundated with different answers that mean the same thing, such as ‘United States’, ‘USA’, and ‘America’, which would happen if we kept it as a text box open to user input. It also removes silly typos and mistakes, so we won’t have people saying their gender is ‘mail’, or that they come from the ‘Untied States’.
So, what’s next? Let’s try to take out that strange ‘developers only’ section. At the moment, we’re trusting the user to read that it’s only meant for developers, but we can go one step further and make those fields inaccessible to visitors. Good UI only shows elements related to users when they’re needed to be shown, and hides/locks them if they’re unneeded at the current time.
Let’s make the Game Title and Game Genre elements only unlock when the user selects the developer option in the Admission Status option. Then, we have Visitor ticked by default. People who are signing up as a visitor won’t worry about entering a game name or genre, and developers can unlock those fields by changing their status from Visitor to Developer.
Finally, let’s look at the pricing options. We made this easier to use back when we implemented tick boxes, but it’s still not quite right. Instead, let’s extrapolate payment information from the attendance status the user picks. When they choose one, we show the user what they’ll be paying based on if they ticked Developer or Visitor.
This is what the final form design looks like.
A lot nicer, isn’t it? Even so, you probably have a lot of ideas on what you’d do next with this form, or how you would improve it. Feel free to plan out how you’d present this form using what you’ve just learnt. If you’re really enthusiastic, you can even try creating it yourself in the programming language of your choice.
The next time you use software or play a game, take note in how they designed their menus and why they might have designed them the way they did. Would you have done it better somehow?
Learn More
8 Characteristics Of Successful User Interfaces
http://usabilitypost.com/2009/04/15/8-characteristics-of-successful-user-interfaces/
User Interface Design Basics
https://www.usability.gov/what-and-why/user-interface-design.html
User Interface/User Experience Case Studies
https://www.slideshare.net/eLuminoustech/uiux-services-web-designing-services
