[Part 1 of 2]
Let’s face it: as software engineers we all suck when creating user interfaces. We studied and worked all our lives to understand complex systems, so we take it for granted that other people will also cope well with complexity. That is simply not true: the complex UIs we create are the main reason why some of our projects have not been successful in the long run.
And the tired lame excuses of not having support or budget for usability are over:
So, how can you design better user interface? It's easy, simply follow these 6 steps:
Before creating an application you need to collect user stories. User stories are not features; they are high level stories that illustrate a user requirement. Here's an example:
"As a team manager, Johnny Boss needs to see a calendar with all the team member's vacations, so he can understand if there are important overlaps before he approves someone's vacations."
Johnny Boss is a persona. A persona is a fictitious character you create for each role that will use your application - these personas will later help you put yourself in their shoes. Giving your personas a fun, easy to remember name is a good strategy.
So before you create your application you should come up with 2 or 3 personas that represent your users and around 20 user stories like the one above. It’s important to keep this list short. The stories need to be very high level, and they may include examples to make them easier to understand. After writing the stories you can draw them in a process diagram. This will help to visualize their sequence. The document with the personas, the user stories, and the diagram should not have more than 3 pages.
One important thing to note is that you should do this BEFORE you think about the database. While doing this you'll often be tempted to think about how you'll structure the database tables. Another common error is to fall into the details. Avoid both - you really want to keep things high level at this point.
Another problem when creating these stories is to only gather “write” user stories - when users do something and data is changed. But more often than not users will want to use the system to “read” some information, so you need to remember to also get these stories.
How do you come up with these user stories? You don't, your users will. You just need to write them down. Interview the people that will be using your application, try to understand how they do things right now. The more questions you ask, the better the user stories will be. Then show users the stories and let them help you improve them.
After this you need to prioritize the list: which of these stories are the most common? Which of these will be used every day? Try to select only about 3 or 4 and mark them as High. These are the 20% of your application that will be used 80% of the time (the 80-20 rule). Then prioritize the remaining stories. I use a very basic categorization scheme to keep things simple: High, Medium and Low. Again your users know more about this than anyone else. Just bear in mind that different stakeholders will have different perspectives, and they all should be taken into account, but the prioritization needs to be done for the people that will actually be using the system.
The prioritization of the user stories is the most important part of creating good user interfaces.
If at any time during the project someone asks you what the top 3 user stories are, you need to be able to answer quickly. Can you do that for the project you’re currently working on?
Now, to complete one of these user stories, a user will have to navigate through the UI of your application. We call this a UI Path. These UI paths have costs, and you should understand them in order to make the needed trade-offs to create better user interfaces.
The goal is simple: The most common user stories should have cheaper UI paths.
So, what is the cost of a UI path? It is a sum of several types of costs:
Every time a user needs to find something on a screen there is a cost. Eye tracking studies have shown that the eye hops between points on a page, and while jumping from point to point the eye is essentially blind.
The most common pattern we see (in western countries) is the eye navigating from top to bottom and then from left to right along some axis, in what looks like an F pattern. From this you can see that UI elements that are on the top or to the left have lower location costs, i.e. they will be easier to find.
This is why whenever you put a list on the UI you need to think what should be the sort order. Even when this can be changed by the user, you need to carefully select the default sort order. Alphabetical is not always the best option and some common better choices are last changed or access date. But of course this will depend on the user stories.
And this also applies to all other elements in the UI. If you need to put a few buttons in a row, the most common ones should be on the left.
Another thing noticed in eye tracking studies is that the eye fixates on larger text (or text with a different style). These are usually labels, links, prompts and titles. We call these Attractors. So if the eye jumps between these attractors, what should a smart developer do? Write better ones. Use the language of the user for these design elements. Better yet, use the user data when possible. For example, the best title for a page that shows a contact information is the name of the contact. Another example: in a google search results page, the title of the search results page is the search term itself.
When there is a lot of information to show on a page, the way to make it easier to find things is to group it in clusters. Most times these will have a title as an attractor. Much like this article you are reading, if you have to find something here, it will be easier because the text is grouped into sections.
But the single best way to make something easier to find on a screen is to remove everything else! The less things on the screen, the easier it is to find them.
Wait costs are pretty straightforward to understand: these exist whenever the user needs to wait for the system, usually due to latency. Following a link will make the user wait for the server response. That’s why AJAX became so popular in the web: since these calls are faster, they have lower UI costs. But don’t be fooled, even with AJAX the user will need to wait so there is always a cost to be considered.
To avoid wait costs you could then put everything in the Homepage of your application, and that would make all UI paths cheaper, right?
Wrong! If you did this the location costs mentioned before would then skyrocket; it would be very difficult to find something on that page.
How do you solve this trade-off, then? Remember the user stories prioritization and put only the top 3 or 4 on the homepage. Again: the most common user stories need cheaper UI paths.
Do you like to fill out forms on the web? Of course you don’t, no one does. That’s because of the associated input costs.
Every time your users need to type a key on the keyboard there is a cost. If they need to click using the mouse there is another cost. Scrolling up and down in a page or drop-down has a cost. When users need to swap between the keyboard and the mouse there is yet another cost (to lessen this you should make it possible to use the tab key to navigate between inputs).
Generally speaking, to reduce these costs you need to minimize the amount of typing and clicking needed as much as possible. The less mandatory inputs you have, the better. Actually the less number of inputs overall the better, as location costs also apply in forms. Also because of that, remember to group the mandatory ones at the top since they are the most important (and place the focus automatically on the first input). Optional ones should follow ordered by frequency of filling out.
Smart defaults are another way to reduce costs. If most users will select a specific value in a dropdown then that value should be pre-selected to save clicks.
Finally, why are autocomplete inputs better than dropdowns when there is a large domain? Because in autocomplete you just need to type in 2 or 3 characters whereas in a dropdown you have to click and drag a lot to locate what you want, making costs higher.
So now you know what the most common user stories are and you know how to make their UI paths cheaper. You could start implementing the solution right now. But you shouldn’t, as when it comes to UIs one of the best techniques is to prototype.
You don’t need to prototype everything, but you should do it for the home page (where the top user stories should be) and the most important pages of your application at least.
There are a couple of good tools for this. At its simplest, a few sheets of paper, a pencil and an eraser are all you need to start sketching the screens. Don’t worry about your drawing skills; it is supposed to look rough. One of the tricks I use is to print a browser window with a blank page on a sheet of paper. That frame around my drawings makes them suck a little less, helps me avoid the blank page syndrome and gives me a sense of scale.
But if you are a real software engineer and you think everything should be solved by resorting to software, you also have options: I have had very good results with Balsamiq. It’s very easy to operate and allows me to focus on the higher level, important stuff.
Then you should show those prototypes to the users.
If you are like me now you’ll start thinking “God, I made these awesome prototypes and if I show this to someone they will give me feedback and it will ruin this great work.” Being afraid of feedback is natural; those are the exact same fears that appear when starting with the agile methodology.
My advice here: don’t be a wimp. When I fear what users might say, is exactly when I know I most need to show them what I’ve done and ask for feedback. The sooner we get the feedback the better: after all that’s why we’re prototyping in the first place!
You have taken the first three steps... but 3 more you must take if you be person of great valor. Continue down this path of UI illumination next week, with the second (and concluding) part of this rapturous article!