This week at NUX Leeds, UX Director at Lion & Mason, Andy Curry shared with us UX enthusiasts why he thinks we should all be doing more field research, or essentially ‘Getting out of the office!’
This type of research is often overlooked because of the amount of time and cost required to organise research for such a small sample. But, Andy shared the power of field research, and the potential it has to transform a project, to help us understand why he loves it so much. So without further ado, Andy walked us through the 6 key reasons why we should all love it too.
> Read more
Are you concerned about conducting research too far in advance that it might make the insight become invalid? Or gathering insight prior to launch but then not having the resource to implement the changes?
These are the kinds of concerns we hear regularly from clients when user research is considered. The budget will only allow for one round of research, so the timing of that research becomes a worry.
But the reality is, there is no bad time to test. All too often, research is reactive rather than pro-active. Once a problem occurs, alarm bells ring and one big piece of research is commissioned. However, in order to adapt to changes in behaviour and pre-empt problems, we recommend breaking research down and gathering customer insight little and often. Below we look at the entire design process from discovery through to post-launch and suggest how research could be implemented at each stage of the process, as well as addressing some key concerns.
This is usually the point at which you’ve decided you want to understand the user’s needs. You may have a product in mind and want to understand the user needs it could address. Or you may have a product that’s live and want to understand more about how it’s used and could be improved. Some of the key things you might want to find out at this stage are:
- How does your current or proposed product or service solve the needs of its users?
- Learn about your users and identify groups amongst them
- Validate assumptions you have about users and their needs
To do this there are a series of research methods you can use. These can be broken down into research with users and desk research which require varying levels of time and budget:
Research with users
- In-depth and contextual interviews – requires no development, and allows you to understand user wants and needs
- Competitor usability testing – understand the user experience on competitor sites to raise opportunities and problems to avoid
- Personas – based on research, personas allow you to identify the profiles of your users and represent their needs, motivations and frustrations
- User journey mapping – involves identifying user goals and visualising the process users go through to reach this goal. Again, requires no development or functionality
- Competitor analysis – identifying what your competitors are offering, how your current product compares, or understanding gaps in the market
But unfortunately, investing in research early in the design process is still a concern for some clients. A common question we receive is:
What if the research is too far in advance of launch that findings become obsolete?
There’s really no such thing as research being too far in advance. Only by testing early will you be able to validate your concept and understand the changes that need to be made. These will then help to shape your program of work and understand where additional research should be gathered to support development. Even at launch, you might have come on a long way since that initial discovery research, but you wouldn’t have got to where you are without it.
By this point, you have a clear set of goals and any assumptions have been validated. With a concept in mind and some evidence to support the user needs, stage 2 involves considering content, getting some lo-fidelity designs in front of users, and reiterating those designs until refined.
Some of the research methods you may use at this stage include:
- Card sorting and tree testing – focus on information architecture, and allows users to input into the organisation and structure of your content
- Designing and testing prototypes of increasing fidelity – involves the iterative development of prototypes (from lo-fidelity wireframes, to fully functioning prototypes), to refine designs
- Targeted research focussing on single features – full development of a single feature in order to observe user interaction and refine accordingly
By this stage, the prospect of moving forward can seem quite daunting. You have lots of elements that need addressing but you’re unsure how to prioritise, and how much to chew off at once. A concern we often hear is:
What if there’s too much to change before the next sprint? How do I prioritise what we design and test first?
Although daunting, the key at this stage is to plan ahead. Consider what needs addressing and order these issues based on how likely they are to impact the user experience. From this, you’ll have a good idea what to focus on first. If you’re still unsure, discuss your ideas with your team, or even with us – based on the results of research or an expert review, we can help you to prioritise what to work on.
As the final stage before your new product goes live, this is when you should be testing the full user journey to uncover any last-minute tweaks or bug fixes.
At this stage your research methods may include:
- Full user journey testing – in-depth usability sessions allow you to assess the full flow, and identify sticking points
- Eye tracking – used in usability sessions to observe natural interaction with the interface, helping you to understand how users navigate the page and make journey choices
This should identify some of the high priority fixes that may need to take place before launch, but also some less severe issues which can be built into a backlog and addressed post-launch. With that in mind a key concern at this stage is:
What if I don’t have the development resources to make recommended changes before launch?
If research has been taking place throughout the development process, then, in theory, there should only be minor changes needed at this stage. But we know things don’t always run as smoothly as anticipated, so in these situations, it’s a matter of prioritising the work. After delivering a project at SimpleUsability we often work alongside clients to make recommendations and help to prioritise how and when these recommendations should be implemented. This way you can get those essential problems fixed and begin building a backlog of issues to work through post-launch.
Now your product is live, but there’s likely to be some teething issues that need addressing, and you might want to start working through that backlog. Your product should be a working progress, so conducting research little and often can be useful to check everything is working as it should and test any new changes that might be going live.
For this reason, the most appropriate research methods at this stage are:
- Regular usability testing – to check the end to end user journey is still working effectively, and explore use with different user groups and functionality
- Eye tracking – to observe natural interaction with the interface, understand how it’s navigated, and what is missed
- Expert review – evaluating your interface to understand likely problems encountered by users
- Competitor analysis and benchmarking – identifying what your competitors are offering, and understanding how your current product compares
With regular use of these methods, your product should be constantly improving. However, post-launch research often raises concerns relating to cost when the live product seems to be functioning perfectly fine. For example:
I know my site is working now, so why should I test if it’s not broken?
‘If it ain’t broke, don’t fix it’. Unfortunately, this is something we usually hear when research is believed to be wasteful or unnecessary. In reality, no one should be waiting until something is broken to fix it. With competition and innovation at its prime, you should constantly be pushing to make your product better. For example, competitors may be implementing changes, and the industry may be shifting, so you don’t want to be at the back of the pack.
We can’t ignore internal concerns and constraints, but getting your peers on board and conducting research little and often is an essential way to stay in touch with users and improve your product. It’s important that research is not just reactive when a problem needs to be addressed as this will require a lot of hard work and will be expensive to fix. Instead, research should be a routine part of your design strategy, implemented across the discovery, iteration, pre-launch, and post-launch stages. It doesn’t have to be days of testing with a fully functioning website, just little and often should provide the feedback you need for success!
In our last article, we considered when it’s appropriate to reuse your research participants. If you’re wanting to run a number of rounds of research or gather insight over a prolonged period of time, then reusing participants is probably appropriate, and a research panel could be an efficient way to gather your participants. However, as something less common in user research, you might be unsure whether this is the right method for you, so in this article, we provide some of the advantages and disadvantages to recruiting a research panel to help you decide.
If you’re looking for guidance on how to recruit research participants, the internet is your oyster. But when it comes to understanding whether you should reuse your participants, you’ll find little advice on best practices. However, here at SimpleUsability and Research Helper we have 17-years experience recruiting participants and are happy to share what we’ve learnt. This article will outline best practices for reusing research participants across the contexts of different methodologies and different project needs.
Should we reuse participants?
Whether we should reuse participants is something that often gets asked by clients. “Should we invite the same users in for each round of research so that they can see our product improving” Or, “should we make sure we recruit a fresh set of eyes?”
There are a lot of questions to ask when considering whether to reuse participants or recruit a fresh sample, and the outcome is likely to depend heavily on the methodology you are using or the type of product you are testing. So first let’s have a look at the general principles that apply to re-using research participants:
When you should not reuse your research participants
- If the participant has taken part in a research session within the last 6 months. You want to avoid developing ‘professional participants’ who anticipate the types of problems they think they are expected to find and lose the fresh perspective needed. Both Nielson Norman Group and MRS recommend that participants should not be used more than twice in one year so we find that waiting 6 months before inviting a participant in again prevents them from becoming research masters.
- For iterative tests when the focus is on the ease of use or first exposure to the system. If a user has previously engaged with an earlier version of the site, system, or app, it’s likely they will remember things from the session, so will not approach the new designs with a completely fresh perspective. Avoid reusing participants where this is the case.
- Research on a similar topic. Even if the system itself is different, sometimes users may recall their previous experiences if the research is of a similar topic. For example, if users have previously completed research for home insurance, we would avoid inviting them in for another session relating to any kind of insurance.
- If the participant has previously been excluded from a study. Whether this is during the session itself or when you come to analysis, participants sometimes need to be excluded due to their dishonesty during the recruitment process, limited feedback during the session, or inappropriate responses. It is always important to record which users have had to be excluded, and a good idea to avoid inviting them in again.
- If the participant has previously been unreliable. We’ve all had times when our circumstances change unexpectedly and we have to cancel our plans. However, if a participant makes a habit of cancelling their sessions last minute, you might as well save yourself the hassle and avoid reusing them in future.
When you could consider reusing your research participants
- When carrying out research on an internal system. In certain cases you may be limited to a particular user group. For example, if evaluating an internal system, your user base is restricted to people who work for the company and use the system. In a situation where you can’t physically find alternative users, you will have to go back to the same participants to gain feedback on new designs.
- When your research is targeted towards a restricted target audience. You may want to see how your product addresses the needs of a particular target audience. For example, when testing for accessibility your audience is already restricted, so when coupled with limited time and resource, it may be difficult to avoid reusing participants. However, where possible we would still recommend avoiding anyone who has been recruited within the last six months.
- For studies on the same system that do not focus on ease of learning. If you’re looking to see how a system works over extended use, or how iterative designs can improve it over time then you might want to reuse the same participants. However, it would be best practice to still include some new participants to ensure learnability is not affecting the research findings.
Based on these general principles, our recommendation would be to avoid reusing participants when research is taking place more than every 6 months, or for systems requiring fresh user insight. However, as we’ve highlighted, there are exceptions where reusing participants is appropriate, such as if you are dealing with a restricted user base or wish to carry out a longitudinal study. Ultimately, these guidelines should be considered on a project by project basis in order to decide whether to reuse participants or recruit new participants for each round of research.
Often thought to be a contentious relationship, Bolser and SimpleUsability came together for a presentation for LDF 2018 to share how User testing and Agile can be integrated throughout a project lifecycle.
Our presenters were Dr Lucy Buykx, Senior UX practitioner and Amy Martindale, Lead UX practitioner from SimpleUsability, together with Bolser’s Hanneka Kilburn, Head of Design and Theo Wrightman, Scrum Master. SimpleUsability and Bolser work with some of the world’s biggest brands providing complimentary services: SimpleUsability is a behavioural research agency, who have evolved a robust and insightful UX research methodology built on trusted psychology principles and innovative technology and Bolser are a full stack agency who have adopted an Agile framework with Scrum since 2013.
> Read more
A homepage is something that any internet user will be familiar with. Whether it be landing on a banking site to set up a new account, or arriving on a travel site ready to book a holiday, the homepage and subsequent landings page are our first touch point on a number of online sites. Not only do these pages have to make a lasting impression on users and signpost them in the right direction, but a homepage is also an important hub, allowing users to come back if they got lost or want to navigate to a different area.
However, a lot of homepages fail to follow some of the basic requirements relating to appearance, information and interaction. So this article will highlight some of the fundamentals for homepage design, and how these can also be applied to landing pages.
> Read more
In June 2017 I walked out of my final exam as an undergraduate to an email offering me the job of a UX practitioner at SimpleUsability. A week and a half later, I began my journey at SimpleUsability, training as a practitioner and jumping feet first into the world of UX. So here’s a snapshot of my first six months and what I’ve learnt so far.
Why user research & why SimpleUsability?
Studying a research-driven degree in Human Geography meant that although my career path was never obvious, what I soon learnt was that research forms the basis of what we know and people are ultimately at the centre of everything we do. Although it’s an obvious observation, this was my first step towards where I am sat today.
Having had my first exposure to user research during a summer internship in my penultimate year at University, I quickly realised that this was the job for me. My final year as a student was accompanied by a search for a graduate role in the realm of UX, and this is when I stumbled across SimpleUsability. Instantly drawn in by the prospect of better understanding users, assisting the development of clients’ platforms, and of course working with state of the art technology, I knew that this was an opportunity I could not miss out on.
From day one, the small and close-knit team was something that stood out to me here. Teamwork is really at the core of what we do, as together we create a smooth service delivery; from the initial development of a proposal, then to the selection of users by our in-house recruitment team, right through to project delivery. Although we work on projects individually, we would not function without the constant communication and support.
On-the-job training at its finest.
Next, I realised that my training at SimpleUsability was not going to be weeks of shadowing and endless reading, I jumped straight into learning to moderate my own sessions with the company’s unique methodology, familiarising myself with the tech, and getting stuck in at multiple stages of the end to end project cycle. Straight away my voice was heard and I was on my way to becoming a valued UX practitioner within the team.
What makes us unique.
As my time here has continued, I have also learnt that what we do is very unique. Firstly in terms of the level of quality and care involved in every stage of a project lifecycle. Then secondly in terms of the range of different project types we deliver and the assortment of sectors we work within. One week could involve running usability testing on a grocery shop, and the next, validating personas in gaming. So with expertise spanning a vast range of sectors and project types, our breadth of knowledge enables us to tailor our core methodologies according to the needs of the business and importantly, the users.
User-centric in every way.
That brings me onto my next point, users really are at the core of everything we do. Our unique methodology begins with a natural user journey accompanied with eye tracking, and is followed by a post-task retrospective interview, including targeted but non-leading questions. This allows us to get the most natural response and feedback from users which is unaffected by any business expectations or hunches. The outputs can therefore be presented back to the clients based on evidence of what users actually do, rather than what we think users might do.
And my experience does not stop in the past and present, as we are constantly thinking into the future here at SimpleUsability. Developing ideas about how we can improve our services to be more flexible according to an increasingly agile industry, and really getting our noses stuck into new ventures as the digital world advances.
Don’t forget the yurt!
Lastly, I guess an important think to note is that we really know how to have a good time. From a team trip to York beer festival, to a Christmas party in a Yorkshire Yurt, there is a never a dull moment in the offices here.
So I guess to summarise, my first six months have been a blast! I’ve been faced with new challenges every day, learnt more about the world of UX than I could ever imagine, and I’m able to contribute towards improving digital platforms for everybody on a daily basis. So here’s a big thanks to the great team here and I’m looking forward to what the next six months holds.
In today’s digital world, our online presence is expanding and so too are risks from hackers and phishers. So with this continual expansion of the digital world comes a need for improved security.
But as security measures have improved they have also become more complex. Multi-factor authentication is now commonplace, and logging into online platforms is no longer a walk in the park. It takes concentration, accuracy and an awfully good memory. So with these advances in security, the usability of getting rightful access to our products and services has tended to suffer. However, this is not something that is going unnoticed amongst us UX professionals, as alongside security advocates, we have recognised that we must find a balance, because as Jared Spool points out ‘if it’s not usable, it’s not secure’.
> Read more
This week at NUX Leeds, Lee Duddell, UX director at WhatUsersDo kicked, off his talk by engaging the crowd with two simple questions: ‘Who has too much UX budget?’ and ‘Who does too much UX in their company?’
As expected, no one jumped to respond. Lee had hit the nail on the head and identified two of the biggest hurdles for most of us ‘UXers’: a limited UX budget and consequently, a substandard amount of UX taking place. This acted as a good opportunity for Lee to tell us his thoughts on the 10 biggest enemies of UX in reverse order and how they should be killed to overcome these two great hurdles.
> Read more
Help features are typically only used as a last resort. Whether it be an electronic appliance or a web application, most users will not read instructions until they feel stuck, and even then they might not. There are two key reasons for this:
- Firstly, due to prior experience users often regard help as unhelpful. Masses of text and pages of irrelevant FAQs have led them to simply ignore it.
- Secondly, as usability continues to improve, users are learning to rely on their own intuition. They expect to be able to self-serve and navigate through a website themselves, so requesting help seems to have become associated with ego depletion.
You might wonder if that makes help features redundant, but we know that users still need help. So the challenge is finding a better way, or ways, of providing it. In this article, we will discuss the helpfulness of some familiar help features from the perspective of how the user gets the help – is it pushed towards them or do they need to seek it out and pull it for themselves? We call this Push and Pull help:
> Read more