At Spotify we aspire to make a great product for everyone in the world. When you think about it, that’s a lot of people! If everyone everywhere lived the exact same way, this would be a lot easier to achieve. But the reality is, our users have very diverse everyday experiences that impact how they use Spotify.
When we were developing Spotify Lite, the small, fast, and simplified version of the Spotify App, we quickly learned that we needed a way to ensure we were building for everyone. We came up with the Designing and Building for Constraints Heuristics tool as a way to test products with the billions of people around the world who face technological challenges at the top of our minds.
Users who find it harder to access online products are “access constrained”, which generally describes three categories of limitations: device, data and network constraints. The tool focuses testing on these areas and provides a scoring scheme for stakeholders to identify areas for improvement.
Understanding constraints
Populations who are new to the internet often face many or all of these constraints, plus some other ones — such as language barriers, learning to use new technology, and primarily using one (mobile) device to access the internet.
Of the main three categories, the most common challenges that access constrained users face include:
Device constraints
Low storage
Using devices with low storage space can get in the way of users downloading and keeping everything they want.
Device Performance
Describes users who experience slow speeds or crashes.
Battery life
Relying on devices that frequently run out of battery
Data constraints
Price
When data costs are a big part of users’ monthly spending.
Data plans
Regularly running out of data and having to choose between the extra expense or going without data connection.
Network constraints
Limited access
Not being able to connect to the internet at all for prolonged periods.
Connectivity
Unstable network connections that frequently disrupt what you’re doing.
Speed
Limited network speeds that increase loading times.
We’ve done research and design work with users who have access constraints for many years, and in order to build and design better products for these users, we developed this toolkit, which outlines some important things to think about when creating for this audience.
The toolkit contains a list of principles (or heuristics) that you can use to evaluate or plan solutions. It’s divided into five sections:
Each of these five sections can be completed individually. You can choose to apply all of them, or only the ones that are most relevant to the problem at hand.
How to use the toolkit
First of all, assemble a group of evaluators! Completing an evaluation together will give diverse perspectives and help you when it comes to making decisions and plans.
For each heuristic in the toolkit, there are a list of questions that help you evaluate your solutions. Each heuristic is marked with the access constraint it applies to. You can skip over the constraints you don’t want to focus on, though they’re often connected. There is a scheme to help you set a score for each heuristic. The scores should help you find the biggest problem areas.
Here are some examples of heuristics:
Sufficient UI Contrast
Some devices have low contrast screens, or you might find that users dim their screen to the lowest setting to conserve battery. Additionally, users may be operating their phones in bright sunlight. All of these factors make UI contrast very important. In Spotify Lite, we tested the concept of having a “day mode” with white backgrounds and high-contrast text, to see if this made the app easier to use in these conditions.
Value vs Storage
Users on storage-limited devices are likely to judge whether an app is worth downloading/keeping based on the size it occupies. The device may be their primary computational device, and has to store everything they care about — so only the most essential services will make the cut. When we built Spotify Lite, the goal was to keep the app as small as possible. We managed to build a version of Spotify that takes up just 10 MB of storage by prioritizing required features — an example of this is making it so users only download the fonts needed for their device language.
Getting set up to test
In order to test if your solutions work for access constraints, you must test them under the correct conditions. While the best thing is testing on location with actual users, sometimes it’s necessary to simulate the same conditions. Here’s how we do everyday testing:
Access constrained devices
A device with these specifications should be sufficient to show a broad range of possible constraints, but make sure to test your solutions with a variety of screen sizes.Screen size ~4 inchesScreen resolution: ~480 x 800px Memory: <1.5 GB RAM Storage: < 8 GB CPU < 1.3GHzHas SD cardHas dual SIM*
*Dual SIMS are sometimes used to get better deals on phone plans — for example, a dual SIM lets you use one operator for phone calls and another for data. Users may switch between different SIM cards on the go depending on what they need.
To accurately reflect performance, install a couple of apps (games, social media apps, etc) and open them. Keep multiple tabs open in the browser (news sites are great for slowing down phones). There are apps that help you auto-fill the storage to reflect users with many things stored on their phone.
Broken screens are another common device constraint. Obviously, breaking a screen on purpose is a bit radical but if you happen to find a cracked screen, hold on to it! Dim the screen all the way down or enable battery saving mode to simulate low battery conditions.
Data
Buying a pay as you go SIM card is a great way to understand how much data is used through different activities on your phone. Many Android versions also have ways for you to track the data usage of your app in settings, so that you can understand how much data it’s using.
Network
The easiest way to simulate slow networks is mobile data set to 2G, which you can do in Android system settings. Walking around indoors and outdoors with your network set to 2G will help you experience different network conditions.
You can also turn airplane mode on and off or put the phone in a microwave (don’t turn it on 😱) while things are loading to simulate sudden network loss.
A word of caution
Trying to simulate the experience of a user who has a very different everyday experience to you is a good way to get started creating better experiences for them but mistakes and biases can easily sneak in.
Here are some that you should be aware of:
Perceptions of data, device and network constraints are relative. A phone that seems slow to you might seem fast to the owner, and vice versa. When evaluating your product, always compare your product to other products under the same constraints, rather than your product under different constraints.
Avoid making assumptions about users as a result of their constraints. Constraints are just one factor that affects a diverse set of users. Being access constrained does NOT mean you...
are more or less technologically savvy
are also financially constrained
are trying to “improve” your situation
consider yourself constrained
are less likely to pay for services
These are just some potential biases to consider, you can read more about uncentering your design practice.
By remembering these users, and using this toolkit in your design practice, we can all be part of making the internet more accessible for everyone in the world.
