We talked to Derek Olson of Foraker Labs and Chandika Bhandari of Seattle AppLab in an hour-long webinar (view the full recording here) November 4th about the challenges of designing usable mobile sites and apps and our solutions for improving mobile UX. Below is a recap of the Q&A segments.
Q: On breastcancer.org, do mobile users behave differently from desktop users, or is user behavior more or less the same?
Derek: Yes, they do behave differently. When we first started working with breastcancer.org more than a decade ago, we actually saw the behavior pattern change between daytime users and nighttime users. People would get home from work, and you’d see a lot of diagnosis-related activity at night from people who may have just received the diagnosis.
Nowadays these people are in their doctor’s office, and they may even have just gotten out of an appointment, including that one where they hear for the first time those very scary words – “you have breast cancer” – and they get right on their smartphone and start researching what’s going to happen and what this thing is. So we definitely see more emphasis on early diagnosis probing, questions from people who are new to the disease, on the mobile side.
Q: Do you know of the most requested features for mobile applications by health plans or in the health sector generally?
Derek: My experience in that sector is limited to what Foraker has done and things I’ve seen out there in the world at conferences and such; but one thing I’ve noticed, very commonly, is tracking applications or websites.
For example, we just turned out a web application with a responsive design to help children stay more active; so they can track their steps with a pedometer, and those get graphed so they can see it with their parents and also track their progress through ‘healthy eating adventures.’ On the breastcancer.org site, we also have folks tracking their treatment progress and so on, so I think that’s pretty common, you know: helping people keep track of their health-related activities or their progression through a treatment or experience with a disease or some other health event.
Read more: UX in healthcare tech
Q: Why is the number one UX challenge doing user testing? What’s stopping people?
Derek: It seems a little silly, doesn’t it? But on the desktop side it really boils down to things that have always been in play: budget, time, know-how, buy-in from stakeholders.
I hear a lot, “Why do you have to test it, don’t you guys know what you’re doing?” And I point to the automotive industry and talk about the engineers at Audi: they’re very very good at what they do, but they would never build a car and put it in a showroom for sale without having driven it for tens of thousands of miles and crashed it and tweaked it and tuned it until it’s…an Audi. Something they’re proud of. And software is that complex – we need to test it with our audience but sometimes those realities get in the way.
And it’s even harder on mobile – the smaller screen, the diversity of devices, trying to get somebody to hold the thing in their hand and then still be able to see what they’re doing. It’s a challenge to make sure you work that into your process and inject unpredictability, but it really is critical to making a product that people want to use.
Q: If I understood correctly, zooming and scrolling on mobile is, to a certain extent, positive?
Derek: It can be. I’ve seen people in testing do this automatic scroll to the bottom of the page and then zing it back up to the top and they seem to actually be unconscious of it. Apple and Google have done a great job of making that experience fun with the spring-loading kind of thing they do with scrolling – you know, it’s fun. Pinching, and zooming – it’s a neat interaction that we get to to do with our fingers rather than trying to manipulate with a mouse or keystrokes, so that’s all something that we can really take advantage of as designers and developers.
Small screen real estate has also led to some neat innovations like partially off-screen navigations where you can see that something is cut off so you know, as a user, that there must be more there and you can go and expose that.
Q: Do you have a separate team for UX and UI and where do UX researchers fit into your team and process?
Derek: Great question. We use a flavor of scrum/agile here at Foraker Labs. We have 3 teams, each of which are full stack, so they have developers, designers, UX engineers, product managers, and a product donor; typically they’re between 5 and 8 people. So we do have staffed roles for UX folks on our teams but we also cross-cut it: we have a UX & design team, and these are the same people who are embedded on our development teams but we also get together as a discipline several times a week and discuss what’s going on in these various projects, what’s our challenge with recruiting subjects or how should we design a usability study to get at a certain question that came up on one of those teams. So yes, we do have them on our teams but we also talk quite a bit with each other in that separate UX & design team.
Q: For Android – HTML or native UI?
Chandika: That, I believe, is the wrong question to ask. Instead, I would first ask “Who are my users? What am I trying to do?” And based on that, you make the decision. Building a native app gives you more power and more direct access to the platform. Using web basically allows us to reuse. So from a cost perspective, you might want to think about mobile web, but the question really cannot be answered until you decide how you want to position your mobile strategy.
Q: How can we cope with performance issues and old browser adaptation on mobile?
Chandika: The question here is really how many different versions of browsers we have on the mobile web. Android has its own browser, Safari has its own browser, Microsoft has theirs. And obviously there have been many versions of the operating systems that come with those browsers, but the problem of mobile web compatibility is actually not as bad as desktop from version to version, within each platform. However, mobile Safari does behave differently from mobile IE, for example, or Chrome.
So in terms of performance, I would say that less is better – I’ve seen a lot of people who have basically done responsive websites that basically just fit their websites into mobile, and sometimes that can be a bad thing. Because if you put more stuff into your mobile web app, it’s going to be slow.
So I would say, in terms of compatibility, you do have to test it against different devices, and services like TryMyUI actually help you target the right set of people with those devices and those versions. There’s no silver bullet – you do have to go through the process for each one. I would always remember this one rule that I tell my clients: You cannot have any action that takes more than 3 to 5 seconds on the mobile web, because the attention span is just too short.
Q: How many users are recommended to drive a user test for mobile?
Chandika: For each scenario, we basically target the kinds of people that will be using that particular feature, and then we’ll decide the different configurations in which we need to test them, and we try to capture 60-70% of that. On average, I would say 5 to 6 tests per scenario is what has worked for us.
Q: Can we see an extensive demo of TryMyUI Mobile on a device?
A demo video of TryMyUI’s mobile testing solution can be viewed here: Mobile User Testing Example Video.
Q: Are all features of TryMyUI Mobile that are available on iOS also available on Android?
Ritvij: Yes – in fact, Android is a little simpler to set up than iOS because for Android you don’t need the SDK, the only thing you need is the app, and that allows you to just start testing as soon as possible.
Q: What is your biggest security concern when it comes to mobile usability? How can we improve app security without impeding usability?
Derek: There’s a couple of ways to look at that, but with UXRecorder, and I’m sure this is also true of TryMyUI Mobile, there is a security angle related to getting assets off the device and back to the mothership, so to speak – we use some out-of-the-box stuff like Dropbox and iTunes to get files off the device, so that helps mitigate the risk there. UXRecorder is a browser, essentially, that also does recording for mobile websites (not for apps), and TryMyUI has their mobile web solution and for apps they’ve also taken the SDK route which makes a lot of sense to get around Apple’s prohibition against letting one app record another. But we have had some issues with browser-based security because people have staging sites that have basic authentication and obviously you want to keep your stuff secure before you put it out into the world, and so we’ve run into challenges getting the browser we’ve built in UXRecorder to play nice with some of those measures.
Chandika: Well it is tough, but the best defense is probably controlling the sources of leaks. That’s part of the reason we signed up with TryMyUI, because we get control over curating the users – we know who those users are, we know where they live, we have their information at a pretty detailed level so we can go after them if there’s a leak; more importantly, we can just make sure users are doing the right things in the first place.
Another thing that TryMyUI does is it allows for internal testing, so instead of having an office with a bunch of devices and machines in a glass room, you can have people do it in their own offices, for example. And that allows you to do the tests internally without actually leaking out to the public. That’s one of the reasons I love TryMyUI so much.
Ritvij: Starting off with TryMyUI, something I was very insistent about was that we needed a quality base of testers, and I think that’s really paid off for us, because we’ve been extremely strict with tester recruiting – we only recruit about 1% of tester applicants, and we continuously judge their performance, so that’s really allowed us to gather and mold, over time, a really nice nest egg of amazing testers who are really good at giving qualitative feedback.
So in terms of addressing security concerns, when someone comes to us and says “We need to test this prototype, and we don’t want random people seeing it but we need it tested somehow” – that’s really a key issue people face, and we recognize that, and our solution is we’re leveraging this high-quality group of testers to launch our Trusted Tester program very soon, to basically make it so that testers will take on a greater deal of accountability in terms of signing non-disclosure agreements and confidentiality agreements. That’s the first step we’re taking, because it’s so crucial for you to test the usability of your website and your app in early stages and we want to facilitate that as best as possible.
Read more: All about our newest mobile user testing solution
Trymata