When it comes to designing user interfaces, testing is as important as any other step in the design workflow. It should be a top priority. But how vigorously should you test your concepts, and how often? Who else should be testing them?
Answer: vigorously — often — the more testers the better.
Even if you’re only testing internally (i.e. with your team), a user is still a user and they should test in as many browsers (if designing for the web) and mobile devices as they can.
Wait…So We Aren’t Talking About Prototyping Tools?
Yes and no. While prototyping tools are useful for validating concepts and collecting feedback on user flows and interactions (the same way design handoff tools can also be used to collect feedback on static designs before handing them off for the final time), there are some things you can’t test in a prototype.
Prototypes are only a simulated version of your website or app — they’re not built with real code, and they don’t always run in a real web browser, or as a real app, meaning we have little idea of how they run in terms of performance. Although, if you are testing prototypes in real devices you will at least be able to test the user experience by actually interacting with the app.
After prototyping with real hands and handing off the design for the final time, we still need to test the user experience in a native environment (i.e. a real browser, or as a real app). Lets discuss why, and in what conditions a prototype will suffice.
Designing for Thumbs, Not Mice
It’s pretty easy to design a layout that looks like it has an optimal user experience when it’s resting on the Photoshop/Sketch canvas, but when it comes to life in a real device the user experience can quickly fall apart. Why? Because we’re designing for thumbs, not mice, and it’s shockingly easy to forget that sometimes. And that’s why prototyping tools exist.
Luckily we don’t need to build the real thing to test whether our mobile UI is designed for human thumbs or not, so prototyping tools, in this case, will suffice. Lets take a look at what needs to be considered in terms of designing for thumbs.
1. Mobile Users Sometimes Hate Clicking
Even though we understand more about user experience than we ever did before, a lot of the mobile web is still pretty inaccessible. We now know that tap targets need to be larger on mobile devices so that our fingers can tap them with ease, and we know that main navigation links are more accessible when situated near the thumb. When your design accomplishes these two things, clicking is less of a chore for the user, but even then, scrolling can sometimes feel more natural (this is why infinite scrolling on mobile is more acceptable than it is on desktop).
Prototyping in real devices lets the tester use their thumbs, and from that you can gain a better understanding of how they like to browse your website/app, by clicking or scrolling.
2. Native Device Hardware
Some things behave differently in a mobile device — file choosing for example. Mobile apps (and to an extent, mobile websites too) have the ability to access device hardware. You can't test device hardware with a device so I rest my case.
But the question is, why would you want to? Mobile operating systems acknowledge that mobile users have different needs when it comes to interactions, so they offer alternative ways for users to advance. Lets say that you're uploading an avatar: on desktop this would be no issue, but on mobile you'd have to leave the website or app and possibly lose the form data you've already inputted. If not, it's still a bit awkward regardless.
Having the interface directly access the device camera could help the user upload their face without leaving the app.
3. Don’t Forget About Performance Testing
Looks aren’t everything. In fact, one of the reasons flat design exists today is because skeuomorphism was too heavy in terms of webpage loading times. People want access to the web right now; even a few seconds is too long to wait, and this is one situation where prototyping tools simply won't do.
No, for this you need the real code. You need to test that code (the very code that makes up the finished app that your actual users will use) in a real device to see how well it performs.
Performance is deadly important. Search engines will even rank a website lower if it takes too long to load, but as well as that, users will quickly give up if your app keeps them waiting.
Besides that, there are other things that behave differently in a test environment. Animations for example. Prototyping tools are excellent at sampling animations and transitions, but how they act in a test environment can be very different from the production environment. Production animations can appear choppy depending on the efficiency of hardware in the device.
Conclusion
So there you have it, 3 reasons why you should test mobile user interfaces in real devices, and in some cases, real hands as well. My ultimate tip would be to iterate quickly — the more testing milestones you create, the more opportunity you have to listen to feedback and improve!
