It’s an all-too common scenario in meeting rooms: “our users like this…”, “typically our users do that…”, “the average user this and that…” But do you really know who’s behind that screen?
Norma and Normman - average but unique
Back in the 1940s, gynaecologist Robert Dickinson and sculptor Abram Belksie created two figures - Norma, and Normman - depicting the average white American man and woman of that time. Their study was quite impressive! They measured 15,000 people between 21 and 25 and, based on that, they created the two sculptures. In 1945, the Cleveland Health Museum sponsored a contest to find a real life woman whose measurements matched Norma. Out of the 4000-ish applicants, not a single one matched!
Around the same time, the US Air Force was trying to solve the problem of high crash rates and, after discarding all other possible issues, they decided to revise the cockpit’s design. They thought pilots might have gotten slightly larger than the ones from 1920 that the cockpit was designed for, so they started taking new measurements. A young Harvard graduate, Lt. Gilbert S. Daniels was among the people taking measurements, but he had a different theory about what the problem could be. After gathering all the measurements, he came up with surprising findings. Again, like in the case of Norma, out of the 4000+ pilots whose measurements were part of this study, no single pilot matched those averages! Not even close, in fact. Even 3 out of the 10 most decisive measurements only covered less than 3.5% of the total number of pilots.
These two examples are famous, and have been used in various contexts ever since.
But how do they apply to designing online experiences in the digital age?
End-users are also unique
You might argue that your app is specific enough, already in a niche, and that’s why you really do know your end-user. Unfortunately this is seldom the case, as we’ve seen from the Air Force example. The Air Force was already hiring people of certain physical dimensions - minimum/maximum height/weight and only males at that time.
So, what can you as a business owner or designer do to ensure you aren’t falling in the “trap of the average user”?
1. Gather as much first-hand data as possible
Talk to people! Ask them about their daily routine, try to figure out how your app will help them get through their day more efficiently. This also allows you to learn more about the context of their use. In the Air Force example, context was crucial because the combat pilots were under a lot of time pressure, having to make split-second decisions. If a warning light is just out of their line-of-sight or they have to stretch to reach a lever it could have fatal consequences. Getting to know your users and their habits will allow you to design better interfaces. Understanding the range of differences between individual users and user groups will help you prioritise and cater for various needs instead of just going with “the average that fits no one”.
2. Minimise your bias
Another reason why gathering first-hand data is important is that it helps to minimise bias. We all have personal experiences with apps, we’ve heard a lot of stories, we know if we prefer to search or browse when faced with a new website and - due to the way humans are wired - we think that other people do what we would do. Because, after all, that makes the most sense to us, it must make the most sense to everyone else as well. Unfortunately it’s not that easy, and it takes a lot of conscious effort to avoid our bias infiltrating our research attempts. We’ll never be able to completely eliminate it, but every little bit helps.
Asking the questions helps in itself, but how you ask also makes a difference, such as avoiding leading questions or facial expressions that give away what we hope the answer would be. It depends on the type of research, but sometimes the best way to gather data is not asking any questions at all, but sitting back and watching what people do instead.
3. Test your ideas
Again, the same point about involving people, but this time it’s for validation. There’s a famous quote (attributed to Henry Ford without any proof whatsoever) that says “If I had asked people what they wanted, they would have said faster horses.”. No matter how much research you do in advance, you can’t expect users to invent the app for you. They only have one half of the equation, after all. You have to do the work of reconciling user needs with business needs and once you come up with those ideas that seem to hit the nail on the head, you need to test them. Go out there, put it in front of people, see how they react, see if they understand how to use it, etc. Validate. Real people testing your app will always, always surprise you, in a good way.
I understand that coming up with an idea in-house and just rolling with it saves a lot of time up front. No need to organise interviews, no need to keep circling back to the drawing board if something doesn’t go as planned. But I genuinely believe that performing these three steps above is worthwhile because it helps you avoid the trap of the average user and save your business time and money in the long run.
Do you really know your end-user?
How to craft a feature the right way
Working on inherited code bases
reinteractive is Australia’s largest dedicated Ruby on Rails development company. We don’t cut corners and we know what we are doing.
We are an organisation made up of amazing individuals and we take pride in our team. We are 100% remote work enabling us to choose the best talent no matter which part of the country they live in. reinteractive is dedicated to making it a great place for any developer to work.
The Ruby on Rails Installfest includes a full setup of your development environment and step-by-step instructions on how to build your first app hosted on Heroku. Over 1,800 attendees to date and counting.
The Ruby on Rails Development Hub is a monthly event where you will get the chance to spend time with our team and others in the community to improve and hone your Ruby on Rails skills.
Webinars are our online portal for tips, tricks and lessons learned in everything we do. Make the most of this free resource to help you become a better developer.