Using responsive design? Re-visit user research questions for better results
Your design fitting on mobile screens doesn’t mean it fits mobile user needs.
Responsive Web Design is a fantastic tool that can solve resolution headaches, but with it comes a need to re-visit basic user research questions.
The best way to think about “Responsive Design” is like water: it will fit into whatever you pour it in. You don’t have to re-design your application in whatever resolutions your clients want: the design can adapt to whatever they need.
However, with this power comes the need to think about mobile needs: after all, all the information that fits nicely onto a desktop screen has a lot less screen size.
So it’s often best to go back to the basics and ask the same user research questions you would at the start of any project.
The strengths and weaknesses of responsive design
Responsive web design is fantastic at addressing one fundamental problem organizations face: they don’t have the resources to develop mobile and desktop designs for their websites.
Responsive design allows them to (mostly) translate the same ideas and content into a mobile experience, but stopping at this stage often isn’t enough.
After all, you have much less space to work with, and some functionality or ideas don’t translate well to mobile.
Companies tend to take two options when it comes to the mobile experience with responsive design:
The second option is almost always the better approach, but one burning (and often contentious) question comes: what content do I not show on mobile?
This is where asking those basic user research questions comes into play. Because many times, trying to answer those for mobile can yield important insights.
Refocusing on mobile
Few people would intentionally design a mobile app requiring users to type paragraphs of text regularly.
Or have the user craft precise workflows or designs that require them to zoom in constantly and out of a canvas. But that’s what can happen if you just let Responsive Design take your desktop offerings and adapt them to mobile.
What you offer users on mobile devices may involve different users, tasks, and focus compared to what’s available on desktop, so it helps to quickly re-visit your basic research questions to see if anything’s changed (and what to prioritize).
Who are the intended users?
Believe it or not, it can sometimes be expected for your primary user group shifts from desktop to mobile. One typical example of this is products aimed at older adults. For example, a family member or a caretaker may be a secondary user group when designing a web portal for seniors on a desktop. But they might shift to the primary user on mobile.
This is because there are physical impediments that may make it harder for seniors to interact with mobile websites, like small screen sizes and clickable buttons, but a younger caretaker may not have those issues.
As a result, it’s helpful to re-examine your user personas through the lens of the mobile application. One thing to help you with this re-assessment is to take a moment and fill in the following sentence:
We believe [Persona/User group X] will use our mobile website to do [Task Y] because of [Reason Z].
Trying to fill in the blanks, as simple as it might seem, can sometimes show that perhaps the functionality you’re trying to push won’t work for your users.
Is it true that your “New Users” persona will use our mobile website to “Create a Workflow document” when doing that on a desktop is 10x easier? Probably not.
Re-visiting your user personas helps answer the first part of the question, but there are other questions to help you answer the others.
What’s the intended purpose and user journey?
Often, you might find that the typical user journey shifts when thinking about mobile. Mobile offerings are typically focused on the latter stages of a user journey, such as purchasing or re-visiting products.
You might buy tickets to an event on your phone (or scan your ticket at the door to gain access to the event). Still, suppose you want to compare different events, dates to go, and other additional information that happens earlier in the product cycle. In that case, likely, those options are better suited for the desktop.
Understanding what tasks are better suited for mobile devices allows you to ‘trim the fat,’ which is incredibly important in avoiding the most common pitfall for mobile design: visual clutter.
For example, mobile doesn’t do the following tasks well:
Typing a lot (it’s always faster to type on a keyboard)
Exploring things nested in multiple menus
Creating accounts/Logging in (can take twice as long to create/enter passwords)
Navigate a complex menu/category choice (mobile means harder to click tiny buttons)
etc.
Unless vitally important, it’s often better to cater to the mobile device’s strengths, even if the mobile offering provides a slightly different purpose.
But there’s one last question you need to ask about mobile devices: How do your interactions translate?
How do your interactions translate?
Mobile flowchart apps tend to be pretty terrible. Even large companies, like Lucidchart, often fail to create engaging and functional mobile applications. While some of the problems are due to flowcharts not being a great offering on mobile, the other part is that interactions are much more cumbersome on mobile.
Most flowcharts on desktops use one simple modality: Drag and drop. Users drag a shape over to where it’s needed and drag connector lines with other nodes.
This is easy and precise with a mouse but terrible with your fingers. Your fingers often cover the canvas and are imprecise, so you can’t quite see where you’re putting something.
This is why mobile flowchart apps tend to use other gestures, like tapping. However, users often have to tap to select a menu to create a shape, tap again to choose a contextual menu, and then tap again to enter text.
It’s much less efficient, and users are likely not to engage that heavily with it.
As a result, think about what interactions your website requires on the desktop, and consider if they translate over well to mobile.
We can see, once we reviewed these questions, we get a statement that isn’t a good indicator for mobile:
We believe that [New user personas] will use our mobile website to [Create a new flowchart] because [it’s less precise/efficient/etc.?]
Asking these questions shows us that this might not be the right task to focus on for mobile and that we might need to consider what else the mobile app might focus on.
Focus on the basics with mobile design if you don’t have the budget
Many companies have a shoestring budget to try and put together a mobile design. That’s why responsive design can be excellent in ensuring that your website translates decently to mobile.
But it’s better to offer limited functionality well than to try and cram everything onto a small screen. That’s why it’s essential to re-visit the basics of user research when thinking about mobile. Doing so allows you to find the right fit for your mobile users.
Kai Wong is a Senior UX Designer, Design Writer, and author of the Data and Design newsletter. His new book, Data-informed UX Design, explains small changes you can make regarding data to improve your UX Design process.