In their recent article ‘How to design ‘Applied filters’ (42% get it wrong)’ the Baymard Institute proposed essential features to make filters user friendly on desktop.
1. Ensure the user can easily find any currently applied filters
2. Make it clear which criteria the currently displayed product list is filtered by
3. Allow the user to easily deselect applied filters
4. Provide the user with additional context when selecting new filtering values
5. Help the user infer how much of a filter type’s ‘range’ is currently selected
As more customers are turning to mobile to browse and shop online, we think it is important to look at filters on mobile. In this article, we have looked at how filters are implemented on mobile across the e-commerce sector, considering if Baymard’s recommendations should be adopted for mobile.
This article will look at the following fashion websites: Topshop, Asos, Missguided, New Look and River Island, and compare them to the following grocery websites, Asda, Morrisons and Sainsbury’s.
SimpleUsability hosted a panel debate as part of the 2017 Leeds Digital Festival. Facilitated by Dr Lucy Buykx, one of our Senior UX Practitioners, and with a panel drawn from a variety of sectors, each at different UX adoption stages, the event drew a sizeable crowd keen to discuss, “Is UX research still too slow for agile?”
Shan Beerstecher, Digital Transformation Manager, Skipton Building Society
Adrian Berry, Product Owner, myhermes.co.uk, Hermes
Sophie Dennis, Lead User Researcher, NHS Digital
Phil Stevenson, Senior Digital Proposition Manager, TD Direct Investing
Lucy Buykx kicked off the event by explaining that at last year’s Leeds Digital Festival the same subject had proven incredibly popular, with attendees likening it to a therapy session for those trying to reconcile agile and user research. As agile is becoming more embedded in organisations, the topic is even more relevant hence the re-visit 12 months on.
The panellists got started by introducing themselves and sharing their experience and thoughts on whether UX research is too slow for agile.
First up was Sophie Dennis who has worked with the NHS since January 2017 and has a range of experience from previous roles within the public and private sectors. She’s had a variety of design research and delivery roles doing variations of agile. She said the challenge is introducing design and research together and how do to reduce the cycle time of design sprints.
Adrian Berry from Hermes stated his team are fairly mature in agile and that although UX is a relatively recent concept, they are now finding that UX and agile come together to help them with rapid prototyping. When testing, be open-minded as to what might come out, dismissing preconceptions is really important to eliminate any bias.
Shan Beerstecher from Skipton Building Society admitted they wouldn’t go as far as calling themselves agile yet and have only just brought in the concept of UX and UX design. She mentioned that agile can often jump a step and that sometimes you need to take a step back to pull out the user journey before making a prototype or an agile sprint plan.
Phil Stevenson from TD introduced the term ‘Agile revolution’ to the session but said he has been trained in traditional waterfall methods. They have only just started applying a UX function within the last 2 years with a “let’s see how you get on with this” approach. He went on to explain that often senior stakeholders or project owners think agile means ‘faster and cheaper” but actually, the experience of agile can be more like ‘frustration, confusion and anxiety.’
Tell us about a project where you have successfully integrated UX and what challenges you faced.
Adrian said Hermes are currently working on new functionality whereby labels can be printed in store as part of a ‘one parcel, one price’ simple proposition which Royal Mail don’t offer. To do this, they conducted rapid prototyping whereby they would spend 3 or 4 days coding, test and retain the learning. He emphasised the importance of being prepared to build something and be prepared to throw it away and retain the learning!
Phil has worked with his team at TD on the portfolio page, one of the most important pages in the TD user experience, critical for conversion success. He talked about his experience with agile whereby they followed a Google design sprint approach. They used every potential sort of data to get started creating personas, defining the user and identifying the problem to learn more out of the process. He said the real eureka moment for them is when you see someone going through a page they have designed, and getting stakeholders to view this research is critical.
However, he went on to say that the stage of testing and designing they did on the portfolio page took a long time and so did not meet stakeholder understandings of agile – “fast, iteration and cheap”. Despite this, he concluded that although the perception was that they were slow and that the work took a lot longer than anticipated, the end product was of an infinitely better quality than what might otherwise have been the case.
Shan then went on to talk about her experience of the ‘grid card problem’, whereby users need a grid card to log in to their account. She said the main challenge for her is communication within the team and having to go through 5 or 6 committees in order to get things approved, makes the length of a project far from agile. The challenge is to convince people to ‘STOP and think, does the customer even want this?’.
Sophie Dennis stated that she has experience with a “formalised agile” process, and that the aim was to bring research and design a lot closer. She supported Shan’s point that you need to ask the question ‘is there any value in this product’. The challenge is how to fit the ‘plan, do, analyse’ approach in a 2 week agile sprint window. She said a more efficient method may be to think ‘What do we need to learn now, and what do we need to learn within the next month or so?’
Where is agile and UX heading?
It appears that regardless of organisation, there are common themes regarding selling the value of agile and UX research within the team and with senior stakeholders.
As the session drew to a close, Lucy asked the panellists what their next steps are and where agile in UX is going. Shan said for them it’s about working out how to gather all of the data and customer insights they have and to make decisions more quickly and that the agile fight will continue!
At Hermes, Adrian believes it’s about bringing the connection between stakeholders and the customers closer because often stakeholders are aware of what customers do, but not why.
Sophie Dennis said at NHS Digital, the next step is to get methods spread more widely and scale up but the problem with healthcare is that everyone is a user, and therefore a highly subjective point of view.
Phil concluded the session by saying that UX isn’t the responsibility of one team, it’s about getting everyone to understand who the user is and all getting together to solve the problems.
In order to do this everyone, regardless of role, needs to see the benefit in it. But it’s sometimes hard to prove the value until you can say ‘look, here’s what we did, here’s the feedback, how about we do it again?’
Lucy concluded with a take home message that what we do in digital should not be about closing down choices but about opening them up.
How do you describe what you do for a living?
Digital marketing executive? Ecommerce manager? UX/UI Designer? User researcher? Customer insight manager? User experience lead?
Does this change depending on who you’re talking to? Chances are, you have a different answer to this question whether you’re networking at a conference, catching up with old friends, or making small talk with your great aunt at a cousin’s wedding.
> Read more
UX Mentors, is an annual Manchester-based event for students who want to get started in a career in UX. It is organised in conjunction between Sigma and Manchester Metropolitan University (MMU). Last week I was delighted to join the team of mentors that included User Experience experts from Sigma, Mando, Autotrader and Shop Direct for the 2017 event.
This year the theme was the Google Sprint, and sprint we did, as we aimed to move through the 5-day process in around 6 hours! The process, as described in the book by Joel Knapp, is an end-to-end process from defining a key problem to solve, through rapid ideation and design to validation with users. Although we were not able to do every step, the Sprint model provided a great format for getting hands-on experience of a number of key UX techniques.
We kicked off the day with a brief, including objectives, scope and target audience, and drew up a user journey map. The brief was to design a mobile app to help low-income people with budgeting. My team drew on their experiences as students to develop a quick persona and draw up the journey of how such user would get started on the app, and then identified pain points and opportunities to design a solution. The team were enthusiastic and full of ideas all day long so this technique, which was new to all of them, helped keep focus on the user’s needs and their pain points that an app could aim to solve.
Moving quickly onto ‘day 2’ we jumped into the Crazy-8 exercise to individually sketch out lots of design ideas for potential solutions. Then the most difficult part of the day – each team member had to choose just one of their ideas to create a 3-stage sketch to share with the rest of the team. Pitches done, ‘day 3’ got the team using Dot-voting to select the best ideas to carry forward to the prototype. This semi-anonymous and democratic method proved a hit, with everyone waiting in anticipation for the decider to place his final casting votes.
As ‘Day 4’ dawned, we shifted from ideation to testing mode, a more familiar territory for this mentor. The team changed roles and split into ‘makers’, who got stuck into making the paper prototype, and ‘testers’ who wrote the script and planned the testing session. Although Knapp advices against using paper prototypes, they are still powerful tools for testing design concepts, with the added advantage that everyone has the skills needed to make them.
The team discovered how hard it was to switch modes to focus and create a prototype from the ideas they have previously agreed on. As an enthusiastic and bubbly team, they were generating new ideas thoughout the session and inevitably the prototype grew larger with more pages and design ideas. UXers know this problem well, as the appeal of new design ideas over old never goes away, so the limited time of this exercise was of real value to the students. As last few minutes ticked away like the Countdown clock moving into the blue zone, the students began to understand the impact of scope-creep on completing the project.
While the makers were doing their best Blue Peter, two members of the team were developing the script for the user test session to follow. This was another activity new to them, so I gave them some pointers on task and question wording that would help them get feedback on the key design elements they wanted to test. The advice that helped the most, as the interviewer told me after the test session, was to include the research objectives at the top of the script because they helped her focus on getting the answers she needed through the session.
Finally we got to ‘day 5’ and the mentors switched roles and tables, and served as users for a different team’s user testing. The team who interviewed me were fully engaged in the session, the interviewer walking me through the tasks, the ‘computer’ making the paper prototype interactive and the rest of the team observing and taking notes on what I found easy or struggled with. I was asked some insightful questions and I think I surprised them with what I didn’t initially ‘get’.
User research tests your ideas with the people that matter. Even hardened designers know it’s can be a blow to your ego when you see users struggle on something you have invested time and energy on, and something that seems so obvious to you. For the student teams, some of whom had never been through the process before, it was a great way to learn first-hand how important it is to test ideas early before you commit even more time and resources to your project.
The day wrapped up with a great talk from Joanne Finch of Mando giving some great advice to get their careers started: get networking, build your skills, document your learning, try something new, and always ask for feedback.
By working through the Google Sprint process, students had a chance to get hands on with a wide range of UX techniques and we as mentors got to meet and share some of our knowledge and experience with some great people who hope to be future UXers soon. A day like this is a win for all involved, so congratulations and thanks to Chris Bush, Richard Eskins and Rick Threlfall for making it happen.
Onboarding screens are designed to introduce users to how the application works and what main functions it has, to help them understand how to use it. As a user experience practitioner, I have experience testing onboarding screens with users and often get asked by clients what is the best way to implement a good onboarding experience to introduce users to an app. Onboarding can be a challenge to get right, especially when trying to meet both business requirements and user needs. The business wants to show users the key features and unique aspects of an app but often in user testing we observe users simply moving through onboarding screens without paying attention to them.
So what to do? In this article, I’ll share learning from our experience testing onboarding screens with a review of the different ways which apps implement onboarding to engage and educate users on their app.
So, let’s start with the don’ts
- Don’t use too many words. We’ve seen in user testing that users find wordy onboarding screens unengaging and this often results in users not reading the information or forgetting this information when they arrive on to the app. Consider the amount of information you are presenting your users with and try not to overload them to avoid them looking for a way to exit or skip.
- Don’t include too many screens… or too few! Think about the length of your onboarding process, too many screens result in users swiping through without paying any attention to the content. On the contrary, although users want a short, snappy, engaging welcome to an app they still need enough information to understand how to use the app and what the benefits of using it are.
Here’s an example of how Duolingo avoid the don’ts we have listed above. Duolingo gets the user to set a goal (how many minutes of practice per day) to get started on the app. This avoids a lengthy onboarding process whilst still providing an engaging experience for the user. It does this with the appropriate number of screens and provides enough information to introduce the user to the aims of the app.
On the other hand, here’s an example from Pinterest which although getting users started straight away by asking users to select 5 or more topics to follow, does not explain how to use Pinterest or what the key areas of the app are. Therefore, it doesn’t include enough information to fully introduce the user to the key functions and benefits of the app, leaving them unsure of what the next steps are.
And now for the do’s…
- Do keep content clear and concise. Users don’t want to read huge chunks of onboarding instructions, and they won’t as we’ve seen in our user testing sessions. Give clear points which focus on the main features and benefits, with one benefit or instruction per slide.
- Do ensure the onboarding is progressive and contextual. One way to ensure the experience is kept in context is to walk the user through the key features of the app on their first time opening the app. This will help the user to remember how to do it next time and avoid them swiping past some screens which tell them this key information. We’ve seen in user testing that users find this type of interactive process much more engaging and informative.
Here’s an example of how Snapchat keep their content brief whilst still providing a progressive and contextual experience for the user. Snapchat walks uses through the interface to guide the user through the steps for the first time, encouraging users to try out these interactions in the context of where they will use them in the future. For example, how to take a photo, followed by how to add a caption. This approach allows users to learn features much more effectively than a static screen with a bunch of instructions that users must memorize for later.
- Do use familiar gestures or provide instructions on how to interact with the app. Apps use a range of familiar gestures to interact with them, including swiping, zooming and tapping. We see users trying a variety of these and sometimes it’s a bit like a guessing game for them. Introduce these gestures to your users, especially if your app uses uncommon gestures (like swiping left rather than right), make sure you include relevant instructions during your onboarding screens.
Here’s an example of how Trainerize provides users with interactive onscreen instructions which appear in context. For example, it informs users how to interact with the page and moves users on to the next step after they have performed the action onscreen. As well as providing an engaging onboarding experience, it will increase users understanding of how to interact with and use the app.
- Do include a skip button. Sometimes no matter how engaging or interactive your onboarding screens are, users still want to skip them to get started and learn the app by playing. Including a skip button gives your users the freedom to do this and is important for users who may have already encountered the onboarding screens previously.
As well as presenting users with a progressive and contextual onboarding process by presenting the user with one feature at a time, the example from Waze below shows how it also allows users to skip the onboarding screens by clicking the cross.
- Do research your user’s expectations. Remember to think about what kind of app you are presenting to users and ensure to meet their expectations of what they need to know or do when opening your app for the first time. For example, our experience testing fitness apps has discovered that users expect to input personal information so that the app can track their exercise levels and weight changes.
The example from Fitbit shows how it gets users started by asking users to input some personal information regarding their height, weight and age. This meets users’ expectations for a fitness app as they would expect to have to enter this key information for the app to track their exercise levels and weight loss. This form of onboarding can engage users with the app as they have inputted personal information, thus have a sense of commitment to the app.
The take away
Onboarding can be a challenge, especially when trying to meet the needs of both the business and the user. As we have seen in this article there are a few take away points to bare in mind when building a successful onboarding experience. Ensure your onboarding is progressive and contextual, use familiar gestures, get users engaged straight away by creating an interactive onboarding experience and consider adding a skip button for those users who just want to learn by playing! Whatever you decide, make sure you test your designs with your users before they go live!
The anticipation for a new Nintendo console was long overdue, so when I heard the announcement in October 2016 about the release of the Nintendo Switch, I knew it was something I had to get my hands on. The Nintendo Switch is a gaming console with a new concept; allowing a quick transition from a home console system to a portable on-the-go gaming experience. The Flexibility of three different modes; TV, Handheld and Tabletop mode mean you can take the console anywhere, and play with anyone. Providing new gaming user experiences makes it stand-alone from other gaming consoles.
The user experience of playing the Switch in TV mode has a sense of familiarity. In order to play games in this mode, the console is put into the dock, and linked up to the TV via HDMI. The games appear as they would on an Xbox, but with the Switch you have the flexibility in choice of how to hold and use the controllers. The Joy-Con controllers for the Switch have a unique controller design; they detach from each side of the console to make either one game controller or two separate pieces that can be used independently. This allows users to configure controllers for the best experience for different games.
For example, as you can see in the pictures, when playing a game such as ‘Just Dance’, users can detach a controller and use it as an individual piece, allowing them to wave this around to follow the dance moves.
In contrast, ‘The Legend of Zelda: Breath of the Wild’, is a classic adventure game, and therefore the user experience is best with a one-piece game controller.
The Joy-Con controllers also have a feature called HD rumble, which offers users a haptic user experience, to feel different types of vibrations through the controllers. Games like ‘1-2 Switch’ have been specifically designed for the Switch, to incorporate these features into game-play. On a game called ‘ball count’ users estimate how many balls are in a box by tilting the controller and ‘feeling’ the balls move around in it. The closest player to guess the amount wins.
One downside of user experience on TV mode is that the games are designed for a smaller screen in Handheld and Tabletop mode, so switching to play the game to a larger screen such as a TV, causes the frame rate to noticeably drop and the game appears to lag compared to other modes. I found this can be off putting and for some may defeat the point of being able to play in different modes.
The unique feature about the Nintendo Switch is the new user experience element, that allows users to take this console anywhere and continue gaming on the move. by switching it into Handheld mode. To do this, you slot each Joy-Con controller into the side of the console to make, what appears like, a Wii U gamepad and then remove this from the dock. There is no need to shut down the console and reboot it to switch modes, as the game switches instantaneously, undisrupting the flow of gaming from one screen to another.
As a daily train commuter to and from work, it is great to be able to pick up from where I played the game the night before, and continue playing this on a journey. The Switch is also very quick to load, after turning the console on, no time is wasted waiting for the console to turn on and select a game, meaning users can get quickly engrossed in the user experience.
Another feature that enhances the user experience is the touch screen element that the Switch has on the user interface, which replicates a tablet like experience to navigate through the menu, select games and change profiles. Although most games on the Switch do not incorporate this touch element into the game itself, it is something I hope to see on games in the future.
A drawback of playing the game in Handheld mode on the move is that the Switch has a limited battery life and can’t be charged independently. The Switch can only be played for around 3-6 hours in Handheld mode, so users need to be wary about how many hours they can fit in gaming, without the console running out of battery.
Tabletop mode combines the mobility aspect offered by Handheld mode, as well as flexible controllers. What’s great about this mode is that you can take the Switch to a friend’s house or to family gatherings, and continue gaming together with multiplayer. This new user experience encourages multiple game play, as opposed to the familiar solo game play at home in the TV mode.
At the moment though, the kickback stand that props the console up on a surface is not very stable, especially when placed on an uneven surface. This limits where you can play in Tabletop mode, as standing the Switch on a surface like a bed or a sofa may cause this to fall over.
Overall, the new concept of the Nintendo Switch is something that is unique in design, and provides a fascinating new user experience for gaming. It has only been a couple of weeks since release date, and the advantages of being able to play games in various modes are evident. However, at the moment, there are a limited number of games available for the Switch, meaning we can’t see the full potential of the gaming user experience. Despite the drawbacks it currently has, we look forward to how Nintendo will fix these, as well as the games revealed in the coming months.
As a User Researcher, I often get to watch a product develop from an early stage low-fidelity paper prototype, to a final stage high-fidelity prototype, before the design gets developed into a live product. Therefore, I understand the importance of continually testing through the different stages of a product, and how valuable this can be for teams developing products.
Prototyping is a draft version of a product which allows users to explore ideas and the intention behind a design, before the designers invest time and money into further development. Prototypes allow us to show users what the experience will be like, from a ‘show’ don’t ‘tell’ perspective, presenting the opportunity for problems to be discovered early on, and therefore allowing time to change the design to ensure a good user experience.
> Read more
There is an ongoing debate around whether quantitative and qualitative methods are better. Quantitative research is good for finding out ‘How many’ or ‘How often,’ as it measures the incidence of findings in a given sample size. The findings are quantifiable and help make informed decisions about the impact of future developments. However quantitative research does not allow us to probe and understand why. Qualitative research on the other hand, uses a wide range of methods to gain insight into underlying user needs and behaviour which is not available in quantitative research. This can provide a sound base for further decision making. However, the in-depth approach of qualitative research limits us to small sample sizes meaning results are not quantifiable.
> Read more
Following on from our tips on building prototypes for testing, here we share some of the challenges which can come up while testing a prototype and how best to work around them.
Conducting usability testing can be challenging, especially when testing prototypes. This is because prototypes are not fully functional websites or applications and the level of detail within prototypes can range from simple paper prototypes to high-fidelity pre-launch prototypes. This article will discuss the challenges we face when testing prototypes from the point of view of a UX researcher and it will provide some tips that can make prototype testing more successful.
> Read more
In our roles as user experience practitioners, we are regularly asked to test with prototypes, ranging from low fidelity paper prototypes through to hi fidelity pre-launch fully interactive prototypes. Clients often ask how their prototype compares with others, and how different aspects will work with or affect the testing. So, here’s our top 5 tips for building a prototype to get the best out of the research.
Content and design
Let’s start with the content and design of the prototype. Although the level of detail that’s included in the prototype varies depending on the fidelity, at all fidelities the content and design needs to support what you are trying to find out.
> Read more