Chapter 1: Introduction to Usability and User Interface Design

Usability is the most important quality of any app. It doesn’t matter how good a feature is if the users don’t know how to get to it or can’t figure out how to use it. In the cutthroat environment of the mobile app market, users almost always have alternatives. If an app doesn’t feel right or if users can’t figure out how to perform the main tasks, they will very often uninstall it without giving it a second chance.

The user interface is users use and view your app. Everything that lies beyond is reflected in the UI. If your killer feature provides the next generation cloud communication (or whatever the most awesome capability of your app is) but isn’t intuitive, you risk wasting hundreds of hours building something that users won’t even try.

Getting the user interface right requires investment into design. This chapter introduces concepts and ideas that make it easier to understand the importance of that investment. It also explains key concepts of the design process and provides some ideas for making users a more integral part of your design process.

Considering Technology versus design

User interface design is not an exact science. It also doesn’t happen automatically. It requires effort and a budget. In my professional career I’ve mostly worked for tech-driven companies, so-called developer houses. Almost my whole career I have had to fight to include design considerations in the application-building process. In almost all cases my request for hiring or involving designers has been either rejected or badly misunderstood. In some companies a designer is thought to be a person who draws icons. In some other companies designers are seen as waste of time and money. In these companies, the engineering team or the product management team often created the design; sometimes it was designed by accident. Although various projects lead to various results, the design was always lacking. The products we built felt easy and intuitive to use to the engineering team, but the team struggled to understand why users weren’t able to get their work done as they expected. The technical team often said something like the following: “That button is clearly there. The users should be able to figure out how to use it. They must be stupid!”

I’ve also worked for companies on the other extreme. Everything was design driven. Early customer meetings were attended only by designers, and technologies were selected without properly consulting the technical knowledge of the team. The design was often implemented in Adobe Photoshop and InDesign without much consideration of the technical feasibility, which ended up driving the technology teams into difficult situations whereby they weren’t able to provide what the design promised.

Neither of these extremes work. In both cases the result is far from what it could be. I have also had the fortune to work on projects where everything was just about right. Working with a designer or a design team that understands that software engineering is not simply coding and having a developer team that appreciates the craft of user interaction design and visual design can lead to stunning results. A team where designers and developers work together can produce results that are much more than the sum of the components.

My message to developers—Users don’t think the same way you do! There are people who have studied user interfaces and have created professional designs. Don’t think you won’t need them because you do! Knowing how to use a user interface that you’ve built doesn’t prove anything. Users who can’t use the same user interface are not stupid. They can’t use it because the user interface is badly designed. Designers understand architecture of the user interfaces. They also understand how to test and verify that the design is good. Trust your designers. They don’t propose changes to the user interface design because they’re mean or want to make you work harder. They want to change the interface because the changes will make the user experience better.

My message to designers—Software engineering is not just about coding. In fact, coding is just a small part of what developers do. Building successful software requires careful planning, architectural design, object relationship design, modular component design, database design, planning for maintainability, deployment, quality assurance, and much more. If you know how to write scripts, that’s a good start. But writing scripts is not software development. Building production-quality software based on a Photoshop user interface wireframe is not simple; it takes time, planning, and especially experience! Trust your developers. They are not taking so long to build a screen because they are lazy. They take the time to plan so the application runs smoothly and is maintainable. This way the whole team can keep tweaking and perfecting the app’s user interface together, and the changes won’t be overwhelming.

Understanding the Mental Model

It’s time to change gears a little bit and think about apps from the users’ point of view. What is going on in your users’ heads when they see your app for the first time or when they continue to use it? This section introduces a very important concept called the mental model.

A mental model is a model that users form of your app’s functionality inside their heads. In fact, people do this with everything. When we learn to drive a car we form a mental model of how the car works. The model doesn’t have to be technically correct for it to benefit the driver. The fact that in modern cars, for example, the steering wheel is not directly connected to the front wheels doesn’t matter. We can keep thinking that it is. We can think that when we turn the steering wheel there are set of gears that turn and make the front wheels turn. Because this model, although technically simplified, helps us understand and simulate how the car will behave when we can use it. Our mental model is consistent with the real-world effect of turning the steering wheel and so don’t have any problems with steering the car. We think we understand how it works, and we’re happy.

People use apps the same way. It is important for users that they can simulate the app functionality in their heads to predict what happens and when. The mental model is one of the most important concepts of user interface design. The user interface design must support your users’ mental model. The app must be consistent and predictable.

The app is easy to use if it consistently corresponds to the user’s mental model and the app is intuitive if users have an easy time forming the mental model. Everything in the user interface comes back to the user’s mental model, and each problem users experience is because of the inconsistency between the user’s mental model (the expectations) and how the app really works.

Forming a mental model

In the real world, you can infer a lot about the physical functionality of objects simply by looking at them. You know how much they weigh, which way you can manipulate them, and which way you probably can’t. With physical objects you can also experiment to determine how they function.

When using software you’re stuck with pixels. How do you make sure that all of your users understand which group of pixels can be manipulated in which way? The answer is simple in theory but difficult in practice. You need to guide your users. The interface must be logical and contain visual clues about how things in it work.

You have a lot of tools at your disposal. You can use colors, shapes, textures, 3D effects, and animations. As with any tools, they are helpful only when used correctly and in the right places. That is where the user interface design skill comes in.

Let’s look at two examples of Android apps. Google’s Play Books is an ebook reader app. Users have a pretty strong image in their heads about how books work and the app helps the users to confirm their mental models by using a transformation animation when they start to swipe a finger across a book page. Figures 1-1, 1-2, and 1-3 display a few frames of that animation.

As another example (see Figure 1-4), the Gigbeat app gives users subtle visual clues to help them understand how the interface works and so they can form a consistent mental model. You can see how, at the Gigbeat tour dates screen, the band profile page graphic is also partially visible. Displaying content partially next to the selected content leads users to think that they can view more by moving in that direction. On a touch interface, the navigation is usually done by swiping or tapping.

Platform consistency and user expectations

An extra challenge comes from the fact that every user forms a mental model differently and expects different things. Some users are familiar with certain user interface concepts whereas other users have never seen them. Users come from different cultures and different backgrounds. They have different experiences in software and software platforms. A life-long Mac user, for example, is going to expect the user interface to work differently from a life-long Windows user.

For example, Microsoft Windows users expect that double-clicking a window title bar will maximize the window. The functionality is not intuitive, but users have learned it and now depend on it. It is therefore very important to maintain functional consistency between apps on a platform.

Tip: Users expectations are an important part of the mental model-forming process. If your app follows all the platform guidelines, users are much less likely to struggle with your app.

Let’s look at few examples of user interface conventions that make it easier for users to get around in apps because they are widely used on the Android platform. Figures 1-5 and 1-6 show two tabbed user interfaces. Android tabs have a distinct look and feel compared to other platforms. The differentiated look is a good thing as these tabs also function a little bit differently than other platforms. On the Android platform, the main navigation method between tabs is the swipe gesture, although simply tapping on a tab also works. Due to platform consistency users know to use this functionality without you having to design a way to explain it.

Another example of platform consistency helping app design is the Android’s menu functionality. Apps that have more menu options than can fit on the screen use the Android Action Bar overflow menu. The overflow menu uses three horizontal dots (see Figures 1-7 and 1-8). Users know what the icon means even though it might not be apparent to non-Android users. You will take a much deeper look into different Android user interface conventions and component in the rest of this book.

Designing for users

Building usable interfaces to support your user’s mental model requires that the user be placed in the center of the design process. The app design must start from the standpoint of the user’s needs and keep the focus on the user throughout the whole process. In the software industry, there is a term—user centered design (UCD)—that is being thrown about pretty often, but what does it actually mean? How can you put your users in the center of your design efforts?

This section introduces some overall concepts of user-centered design and goes though some of the most important terminology. User-centered thinking is very important for the success of any project, and the concepts described here can be adapted to work in any project. The subject of user-centered design is very large and others have written whole books about it, so there is no shortage of additional sources to deepen your understanding of the subject. I hope I spark your interest in the subject, and I encourage you to seek more information and alternative views from the literature and from the Internet.

User Goals

Users don’t just want to use your app. They want to get something done. They have goals like “remember to buy milk on the way home” or “buy an Android tablet.” Users are going to evaluate your app based on how well it supports them in achieving their goals. If you identify the user goals your app supports and make your user interface support them, your users are going to be happy.

Let’s take a little bit deeper look at user goals. What is a user goal and what isn’t? In short, a user goal is something the user wants to do but does not describe any functionality of your application. For example, the “user wants to save the document” is not a user goal. A user never wants to save anything. Users want their documents to be there when they need them again. This goal might be supported by a save function, but that’s not the only option.

For someone coming from a more technical background understanding, user goals are like use cases. A use case describes an app’s single usage situation. A goal is the description of why the users want to do something.

Table 1-1 shows some examples of how user goals should be formalized using a fictitious college planning app. The table includes badly formalized user goals and reasons why they are bad as well as correctly formalized user goals that match the same situation. Note that the differences in good and bad are subtle, but the bad ones might cause designers and developers to think about features and certain user interface solutions ahead of time.

Table 1-1 Example User Goals for Fictitious College Planning App

Not a User Goal	Corresponding User Goal
User wants to save a document (implies functionality).	User wants to have the same document available when she works on it later.
User wants to see a notification when a new email arrives (implies functionality).	User wants to know when new emails arrive.
User wants to open a calendar view with lecture times (too specific).	User wants to know what time a certain lecture starts.
User wants to see a calendar (too abstract).	Contains multiple user goals.
User wants to use search to find a lecture (describes functions).	Probably contains multiple goals. One of them could be that the user wants to determine whether he knows somebody attending a certain lecture.
User wants to add new reminder to his calendar (describes functions).	User wants to remember an appointment before it starts.

Don’t talk about features

The first thing to do is to change the language and terminology about how you talk about your software project. You must stop talking about features and start talking about user needs. Avoid designing the user interface by accident. If, while still in the concept phase, you start talking about features and how the software should function, you need to take a step back. Users’ needs must come first. Be careful to avoid sentences like “Hey, I think we should add a Save button here!” A possible result of that sentence might be a user interface feature that is useless or confusing to users. Think about the user goals first!

Determining user goals

It is easy to say that you should have a list of goals in order to start thinking about the features and the design of your app. But where does that list come from?

User goals should arise from user research, domain expertise, and an understanding of the problem the app is trying to solve. User research is sometimes not possible or not feasible so you might have to rely on more informal means. Consider doing ad-hoc user research by having a short chat with your friends over Google talk or Facebook.

Writing down the user goals you feel are the most important does act as a very valuable discussion starter. A list of initial goals can be an extremely valuable tool especially if you are building an app for a customer. A complete list of user goals is a non-technical description of the app’s functionality. It is something that is extremely easy to discuss without any need for technical knowledge or lengthy documentation. A user goal is one or two sentences and a question like “is this important to you?”

To build the user goal list, simply write down what you think is important based on your expertise. Then talk to your customers, domain experts, users, and anyone else you think can contribute. Then you need to reorganize, rewrite, and prioritize your list of goals. By the end of that process you will have something that describes what users can achieve by using your app, even though not a single feature has been designed.

From goals to features

A very important point to understand about usability is how app features relate to user goals. Each feature of any app should cater to something users want to do. Simply adding features without thinking about its user goals is likely to result in a confusing user interface and a lot of wasted hours building features that will never be used.

In theory, every single feature of an app should be traceable to a user goal (see Figure 1-9). In practice that is not always possible but it should be a target for the team. Adding features without thinking about the user goals introduces feature creep to the app. More features don’t make apps better especially when the features aren’t well thought out. A good example of feature creep is almost any Office productivity suite. The Office suite providers have been piling features on top of features for years, and the apps now require special training to be used.

Figure 1-9: In the end your app should not have any features that aren’t traceable to a user goal.

No App will do everything; pick your battles

Don’t try to do everything. Start with key user goals and expand from there. An app that fits perfectly with a smaller set of user goals is much better than an app that tries to do everything poorly. At the start of the project write down what your app is going to do and especially what your app is not going to do.

If you’re building a note-taking app, for example, decide what kind of note-taking app it will be. Is it also going to be a to-do-list manager or a word processor? One app can’t do all of that. If you decide that no, your app will not be a word processor, write that information down. You won’t support users who want to write a book using your app. Your app will help people take basic notes. These kinds of decisions help you concentrate on the key issues and help you build a more focused product that supports your users’ key goals. Create a list similar to Figure 1-10 to make it clear to the whole team and other stakeholders what you are doing and what you’re not doing.

Tip: Deciding what not to do is as important as deciding what to do.

Figure 1-10: With few written words you can limit the scope of the app and help the whole team understand what the app is going to do and what it is not going to do.

You are the expert; users are not designers

There will always be someone wanting to tell you which features you should add to your app. User feedback is typically littered with feature requests. Don’t assume they are always correct, but don’t ignore them either. Simply implementing user-requested features will make your software cluttered and unorganized. Try instead to find the user goal behind each request. Determine if the goal is something your app should support, and, if so, start designing the best possible user interface. Do not let your users design your user interfaces. You are the expert.

An overused quote attributed to Henry Ford goes something like this: “If I had asked people what they wanted, they would have said faster horses.” The sentence captures the whole essence of what to expect from users when asking them direct questions about features. Always ask what users want to do, not what they want. In this old example, the question is “What do you want to do?” and the answer is something like get from point A to point B faster. A visionary designer can take that information and start to look for solutions that solve the issue in better way (a mechanical car) than the obvious solution (a faster horse).

Know your users; design for real people

You are not your app’s user. Be wary of implementing features you would like. Don’t base UI decisions solely on anecdotal evaluation, yours or your coworkers.

Figuring out for whom you are writing the app is very important. Different kinds of people expect different functionality and need different user interfaces. In some cases you already know your target group, but in other cases you need to do a lot of work to figure this out. People tend to answer that they want everybody to use their software. Even if you did want everyone to use your software, designing for everyone is impossible. You need to decide who your main users are and concentrate on their goals.

Using Personas

Formalizing and communicating who your users are isn’t easy, but using personas can help. A persona is a made-up person who epitomizes one of your user groups. You could say that a persona is a concrete instance of an abstract group. Creating personas is like creating characters for a play. In this case the play is your app and the character is an example user of your app.

Your personas should be based on user research when possible. Writing down your best guess and having discussions with your customers and other domain experts should get you enough information to build a good set of personas.

Tip: Don’t use information from any one real person. It is much easier to talk about fictional persons than about real persons. You also don’t want to accidentally insult anybody who was nice enough to participate to your user research.

You don’t need to create personas for everyone who is going to be using your app. Each persona represents a group of real users. An average mobile app will probably have between three to seven personas.

Each persona should have the following information (see Figure 1-11 for an example persona):

• A made-up name (look for a random name generator on the Internet if you have problems coming up with one)

• A portrait photo

• A short description, including age, sex, education, and so on

• A list of key goals this persona has relating to your app domain

• Priority describing how important it is that this persona’s goals are supported in your app

Figure 1-11: An example persona.

Source: http://www.flickr.com/photos/yuri-samoilov/4105603525/copyright Yuri Samoilov

Once you have your personas laid out you will have a very good and concrete picture of your target users. You don’t have to think about your users as abstract stereotypes; you have people with names and personalities instead. You can use the personas to simulate your app functionality as well as decide who are the important and who are the not-so-important people for your business goals.

Now you have the personas and user goals. Use them! If it helps, print out the persona descriptions and hang them on the office walls to remind you and the team that these are the people who are going to use your app.

Getting into your user’s head

Once you reach the point whereby you have your personas and user goals listed you’re pretty well positioned to start thinking about features and design. You hopefully have a great understanding as to what you want the app to do and who the users are. Your whole team and stakeholders have a good agreement about what needs to be achieved. Now all you need to do is create the actual design. I’d like to tell you that it is the easy part but I would be lying. The design and development is the hard part.

Build the information architecture and visual design to cater to the user goals. Make sure that all the important goals are easy to achieve with the design you’re doing. Keep testing your designs with the mindset of the personas, and simulate the app with the user goals in mind. Ask a lot of questions like “Would persona X understand this?” and “How about persona Y in this situation?” Stay in the mindset of your users when thinking about using your app. This way you will avoid designing the app for yourself.

There will be moments in the design process when brilliant feature ideas pop up. They might not fit into the personas or user goals but might feel like great ideas nonetheless. Be wary of those situations. Sometimes the idea might lead to real innovation and is worth pursuing. Whenever a feature doesn’t fit the user goals, though, be extra critical of it and evaluate it twice.

Summary

The actual design work requires skill and experience. The rest of this book talks about designing for Android and the things you should know about the platform. It discusses platform-specific problems and opportunities. It explains what is possible and what is difficult to implement. It also talks about tools like prototyping and Android user interface design patterns that can help you get the design details right.

A big part of building a great user experience is getting to understand how users think. Once you can think like your users or understand how they think you are in a good position to design user interfaces for them.

If you invest time to do the research and design you will save a lot of time in the long run. Do your legwork; bug your friends and family. Make sure you understand who your users are and what they want to do. Make sure that your team knows which user goals are the important ones and which personas are the high-priority ones.