|By Matt Lacey
In this article, you will learn why it is important to take users’ potential differences into account when creating your application, as well as what things are important to keep in mind during the design process.
People aren’t all the same
People who use your app are different from you, and categorizing their differences requires that you think about them in groups. Other differences exist that you should consider as well.
Many people who create apps ignore these differences, but that’s no reason for you to do the same! Don’t blindly copy what others have done before in other apps. Instead, focus on what’s right for the people using your app. You need to consider differences in their:
Disability is a term that has many connotations. It can have negative implications and can result in discrimination. It covers physical, mental, emotional, and developmental impairments that affect people from birth, or as the result of an event during a person’s life.
Rather than use the term disability, it can be more helpful to think about inclusivity or universal accessibility. Using these terms can help us to think about how we can create something useful, and usable by more people, instead of concentrating on their differences or limitations.
By being fully inclusive, we can avoid discriminating on a wide range of factors that extend beyond an individual’s abilities, but also includes knowledge, education, culture, location, gender, and age. It may not be possible to make something that’ll work for everybody all the time, but by considering all people, we can make something for the broadest spectrum.
To make your development task simpler, you may try to argue that those with disabilities are beyond your target audience, but there are three potential issues with this argument.
- Many countries have laws preventing such discrimination. Similarly, many large companies and governments also have policies about only using suppliers and services (including apps) that are usable by all.
- There’s a moral argument against discrimination.
- Not all disabilities and limitations are permanent. Some apply to people at certain times or in certain circumstances. Table 1 shows temporary situations that could potentially affect anybody and comparable permanent situations. If an app doesn’t have any capability for accessible use, then no one will be able to use it all the time.
Table 1 Examples of how many temporary and permanent situations can affect a person’s ability to perform a task, but the consequences for handling them can be the same.
|Having a cold or the flu||Limited speech capability or speech affectation||Limits the ability to rely on the accuracy of speech to text interpretation for input into the app.|
|Using app in noisy environment||Deaf or hard of hearing||The audible output from the app can be missed and shouldn’t be the sole mechanism for communicating from the app.|
|Using app in bright sunlight||Blind or visually impaired||Can’t rely solely on communicating information through displaying it on a screen.|
|Broken finger or sprained wrist||Arthritis or other condition affecting fine motor control||Limited ability to interact with items on screen or perform precise gestures.|
|App in unknown language||Limited education||Avoid issues by replacing complicated text with icons.|
Inclusivity should form part of the discussion around the context of your app, as it can have fundamental and conceptual implications for the building process. Your aim should be to focus on creating something that more people can use from the start, rather than adding considerations for those who are, in some way, different towards the end of the process. It’s harder to add such support to an app that already exists, and it’s normally faster and cheaper to build in accessibility from the start and meet the expectations and needs that more people have for your app.
To illustrate: Meet Mitch. Mitch is a developer who built his own app recently. Mitch overlooked making any special considerations for people who need them because he didn’t have any such requirements and initially built the app for himself. Based on feedback he received after launching, he went back and changed some of the colors in the app as some people with color blindness (or color vision deficiency) had difficulty reading parts of the screen. He also added support for the text in the app to reflect the system text size settings on the device as some people needed the text to be larger to be able to read it comfortably.
Like the person who expected Mitch’s app to respect the system setting for the size of displayed text, we all have expectations about how things will work, based on our past experiences. We expect that the things we use now will work like the things we’ve used in the past. And when using something again, we expect that it’ll work in the same way when we use it later. It is, therefore, important to understand expectations to provide an intuitive experience for the people using your app.
You’ll recognize the icon in figure 1 and probably understand that it shows that something should be saved. The image represents a floppy diskette and is still used in PC apps. The apps that ran on old PCs informed much of what happened in the early periods of mobile app development, but the evolution of apps over the last few years means that many such influences are no longer relevant – but even so, they persist.
Figure 1 A traditional save icon doesn’t make immediate sense to many people using a mobile app
Such a save icon makes little sense for people who came straight to mobile apps and never used a PC (younger people, people from less-developed parts of the world who may have never had access to a PC, etc.). The need for the icon can even break some expectations. For many people, it isn’t unreasonable to expect the app to save information automatically. Why should a smart device need an instruction to save something? If it’s smart, why wouldn’t it know to do this automatically? Furthermore, why the image of a physical disk when saving in the cloud?
PC apps had a large influence on the expected experience of mobile apps in the past, but this is no longer the case. The device and the other apps that come with it set expectations for any installed mobile apps.
Expectations also extend to the content of an app. Consider a game about managing a farm. No one would expect the inclusion of all the different animals pictured in figure 2, but which animals are appropriate to include depends on people’s different opinions and expectations – based on religious and cultural reasons. Similarly, in some countries, having some animals on the farm for food rather than as working animals may be as out of place as having rice as a crop. Never forget that expectations can vary wildly – take nothing for granted!
Figure 2 Different people will have different expectations about which of these animals are appropriate in a game about farming based on cultural and religious beliefs or societal conventions.
The enterprise is a special case when it comes to managing app expectations. There’s often a necessity to balance a consistency with existing software and the expectations of staff based on their use of apps outside of work. Unfortunately, the creation of much existing enterprise software has focused on functionality over usability. This focus contrasts with popular consumer apps, which typically make usability a much higher priority. There’s a growing expectation amongst people using enterprise apps that they should offer an experience comparable to that which they get from the consumer-focused apps they use day-to-day.
Our experiences have taught us that most of the time things work, but they’ve also shown us that sometimes things don’t work or don’t work the way we expect. When it comes to failures, bugs in software or other exceptional circumstances, we need to consider expectations. Our actions when things go wrong can leave an impression on the people using our software. If we know how a person will react when something goes wrong, we’ll gain insight into how to prioritize meeting those expectations. And even though we should always try to minimize bugs in an app, there are times when this is more important because of expectations. Having had to deal with scenarios like the one in figure 3, I’m very aware of this.
Figure 3 Errors in code can cause negative emotional reactions as well as showing other problems
Our expectations influence what we want from an app in many ways, but the biggest expectation is that we’ll be able to achieve our desired goal from using the app.
As different apps provide different value, different people can also have different goals regarding a given app. The definition of value is broad, but goals are targeted.
A game may give value by entertaining and helping people pass the time, but different players may have different goals. Some may want to play to completion as quickly as possible. Their goal is to complete the game and then move on to another. Others may look to gain expertise in the skills required to do well in the game. Their goal is to be as good at the game as they can be. Others may want a quick way to satisfy a need for some mental challenge as they pass the time. Their goal is to achieve satisfaction from completing a challenge. A great game will make it easy or hard to achieve these different goals.
As another example, where the value from a social networking app is defined as being able to help connect with friends and acquaintances, this may translate into many differing goals. A person using the app may want to keep up with everything done by a specific person, or persons. Another may use the app with the aim of finding out what’s been happening in the lives of people they haven’t been in contact with for a long time. Or a person may want to use the app to keep in touch with family in another part of the world. In each case, the architecture of the app affects how easy it is to meet a specific goal. It could provide a generic interface that allows the person using it to achieve each of these goals, but the generic nature may make it harder to achieve a specific goal when compared to an app created specifically to accomplish said individual goal.
With many different potential goals for using an app, it’s important to define the goals that the app is trying to help people achieve. It may not be possible to design for all specific goals, and it’ll be necessary to decide which goals the app will help people achieve. Figure 4 gives a simple way to visualize this. You may identify goals which the app doesn’t help with. Knowing this is important, as it identifies limits and will help identify whom to target when promoting the app. Alternatively, you could create an app that serves people broadly by providing value in a generic way that might not target a specific goal. Such broad functionality may give value to more people, but a person with a specific goal may get more from an app which focuses on helping achieve that goal specifically.
Figure 4 Design your app to achieve the goals of the people using it.
Hopefully this article has broadened your perspective about the (potential) perspectives of your prospective app customers, and will enhance your design process. If you would like to read more about creating great mobile app experiences, download the free first chapter of Usability Matters: Practical UX for Mobile Developers and other Accidental Designers and see this Slideshare presentation for more details. Don’t forget to save 37% with code intmobux at manning.com.