7 common reactions you will hear and how to tackle them by taking a practical research approach.
If your job title has anything to do with design, there is a good chance that you would have experienced the need to do some form of user research as part of your creative process. And if you happen to work with or for a group of people who have limited understanding of the design process, then I am pretty sure you must have had your moments of frustration.
If it is a battle to sell design , it is a war to sell research.
For last 8 years I have fought some wars on my own and by the looks of it there are more to come. From a job title saying ‘Design researcher’ to ‘UX designer’, from a corporate to a start up to a design agency to freelance and finally a corporate again, I have experienced different levels of design maturity within the teams. But to a large extent the challenges are similar in each one of these setups. If you are lucky, you might be part of a dedicated research team or at least have access to one. Even then it’s not always a smooth road taking your research to far corners of your company and making an impact with it. It’s partly our fault as well when we also fail to understand our ‘other users' , namely POs , developers and everyone else who should listen to what you have to say, but not are not entirely abreast with fancy jargons of our design world :). What I have realised over the years is that sometimes we have to let go of our (designer)ego and bend some rules for the benefit of end user.
I have summarised some common reactions I have heard over years from my non designer colleagues(and sometime fellow designers as well) and my learnings from my successful and unsuccessful attempts to initiate or utilise user research in my teams. Each learning is accompanied with a real life project example (marked as 👉).
1. “We don’t have time for it in this sprint. Let’s do it later ”
You will not always have the liberty of time. So be smart with what you want to do. If people don’t your argument or are indifferent to it, just do it anyway. Be street smart (literally). Catch users you can find on your office floor, cafe , front desk etc. I personally find it awkward to venture down to public places for research, but if you have the talent then go for it.
Make research inherent part of your process and if need be make it discreet.
Don’t worry much about the number of users you get. Some research is better than no research. You can do research also just to validate your hunches as a designer.
👉 Designing a tool to make people aware of importance of having sufficient buffer savings
I was given this task to redesign the existing tool at ING which calculates how much buffer savings a user should have, based on the personal situation. The current tool had a high drop out rate and very low conversion to start a new saving goal or open a new savings account.
To speed up the process I went through the existing flow with team members to see where the current experience lacks. Then we made a quick design to use as an artefact during research and tested it out with office front desk and cafeteria staff. In total we spoke to just 5 users for 40 mins each, but it already gave me plenty to work with. It was not just a usability test but a way to gather insights using designs as a medium of conversation. It was easy to ridicule or praise the screens and then talk about the deeper reasoning behind their choices. A sample outcome from this quick research :
Everyone had a ball park amount in their head. What we were showing was mostly way more than their expectation . This was putting them off and they wouldn’t believe that they need this much buffer. It’s too big a hurdle to take any action.
Some more insights like these were good enough for me to come up with a new design for this tool and it eventually led us into a more strategic discussions on how to make such tools more contextual and relevant.
2. “Research is boring. Design is more fun.”
This one is for my fellow designers who believe that the divine act of creation is what makes us unique and is way more interesting :).
Research can be as creative as the real design process.
You can always ‘design a research’ like you design products. Keep things flexible to make it more fun. A typical research process can also have 4–6 phases like a typical design process:
Discover : What are the right goals and questions to research on ? Know what you don’t know
Define: How are you going to do the research ? Who will you research with ? Will you just talk or show some designs or use some artefacts to stimulate conversation. It is where you can go creative by thinking of new ways of stimulating responses.
Refine : Test your research with family / friends / colleagues. See if you are getting the desired quality and quantity of results and iterate.
Execute: Do the research, also starting with a few users and refining if necessary before doing it with the rest of them.
Analyse : This might be the most important step if you have a lot of data to process, but if are doing a small scale study, you might already have your wow moments in the last step.
Transform : This is where the real magic start to happen, when your wow moments start materialising into tangible ideas / design recommendations.
👉 Laptop innovation for Indian context.
One of my very first assignments at Samsung was to investigate laptop usage in Indian context and suggest new innovation opportunities. We went through all cycles of research as mentioned above, interviewing over 35 users from different segments across 4 cities in India and conducing multiple expert discussions. Some snippets from the research process :
Define: We designed different research methods for different target groups. To capture the desires of young students we designed a fun ‘Design your laptop’ exercise, where a group was given props to assemble their laptop of dreams and present it to rest of the students. For families, we went for the traditional in context ethnographic study. A family laptop in India is a shared commodity and used more like a desktop pc. It was imperative to see the environment in which laptop was kept and used.
Analyse: Each research insight was used for brainstorming ideas ranging from product design concepts to new service solutions. Focus was to come up with innovative ideas to tackle very peculiar Indian needs.
3. “We already know so much. Why do we need research for ?”
Before starting the research make a brain dump. There is already a lot you and your team members know.
Realistically , it’s impossible to stay unbiased during a research.
It’s better to know your biases before hand and form proper hypothesis from them. This will ensure you research outcomes are of better quality. It’s also important to manage expectations of stakeholders. Don’t promise hefty outcomes from your research. If your team thinks they already have a good understanding of users from their own experiences, still use research as a means to validate them. Also, do a detailed desktop research to add to brain dump. Collect as much data as possible from both internal and external sources to kick off a topic. You will be surprised how much data you will find in your own backyard. It’s highly likely in a corporate setup that some team somewhere has already worked in past on something similar.
👉 Design of new account aggregation features complying to new PSD2 directives
It was primarily a technical project at ING, where my squad (old school team) was exploring how a new legal framework PSD2 can be implemented. I was part of the group which has been working in the domain of daily money management for years. They had a lot of product and online user behaviour knowledge, but they have been part of very few real customer conversations. When I joined the project to flush out some first screens (YES, it still happens in 2018 !), I wanted to align the team members on where do we stand right now and what aspects of consumer behaviour we don’t fully understand.
We used one of the standard persona used within the company to make a day in life scenario and plotted all our insights, questions, ideas and hypothesis on it in a half day workshop.
This made the team to realise that there is still some value in talking to customers to further understand their daily money management behaviours and how aggregation can provide more value.
4. “We should also ask users about our new features during the interview. ”
Make a short list of goals you want to achieve from your interviews. Your team might be tempted to make most of the opportunity they get to talk to user and they might ask you to get a stamp of approval from the user on the ideas they want to implement. Keep your interviews simple and focused on listening to user first, rather than forcing them to say what you want to hear.
Treat your interviews like an free flowing informal conversation. Asking for opinions usually result in fake and sugar coated answers.
Also if your conversation is more open, it will be difficult for others to misuse research. It might happen that a user ‘yes’ or ‘no’ is etched on stone without giving a thought to the reason is communicated as a gospel of truth within the organisation. In that case, research might do more harm than good. If your conversation is going well and is engaging enough, you will know if your features are going in right direction.
👉 Conversational UX research
At ING we were exploring how we can engage with our users better using conversational interaction, mainly chat bots. This was a side project (the so called 20 % project) for us and we had to deliver something tangible in real quick time. Since this topic was new and vague (and still is), we had to start with user research with a focus on certain user segments and strategic directions. We also had a lot of ideas already which we wanted to test, but still to keep the study open and lean, we as a team grouped all that we wanted to understand into 5 main clusters. This helped us to keep a clear focus on what we want to achieve in each user research session without biasing the users to judge our ideas.
5. “Do we have enough data to support this ?”
Use data for iteration, use stories for inspiration.
In companies, especially in agile team setups, we don’t focus enough on stories (not to be confused by the ‘scrum user story’). This is one area where you as a designer can add value. Most of your stakeholders will anticipate black and white answers from research, user’s likes and dislikes, usability issues and other traditional measurable metrics.
A good user research should also bring out stories which reflect something profound about users and could act as an inspiration for you and your team to think big about your product.
Use data to make feature level decisions and refinement of products. Story can be anything from a quote, an interesting tale of events or merely a powerful image of user or the product environment .
👉 Research for a diabetes management app
I was consulting with a startup working on a diabetes management app for Indian consumers . I was roped in to help the team revamp their consumer mobile app. The product had a vision from it’s co-founders and a wish list of features. But no one had ever spoken to the end user i.e a diabetes patient, to understand if all these features even fit their needs, wishes and behaviours and if they were missing something in the big picture. I did start flushing out screens, but constantly asking questions on the validity of the ideas itself, which eventually led them to believe that we really miss user stories and deep emotional understanding of this topic. I went out to talk with users with the co-founder of the company which helped him hear these stories first hand. Some stories which inspired the team :
Story 1: “If I talk about my sister and other family member then they felt that it should not have happened at this age. It is still ok to have it after 50 or 60 but not at this age of 36–42. Our own people feel sad. So the way people look at you, think about you and eat around you changes”
When someone is diagnosed with diabetes, it impacts the whole family. In India families are very tightly knit and everyone gets impacted because of one diabetic in the house. From food habits to daily routines, everything tend to change. But this also means that you are never alone in your fight against diabetes and your partner or kids are always there to support, remind and if needed police you to keep you away from harmful habits. This led the team to think of diabetes care as a family activity and not just an individual’s own responsibility. A new companion app was designed to help family members track the vitals and poke for medication etc. We also strongly believed this could be a more effective way of behaviour change, where we were facing in some cases decade old habits which could prove deadly for a serious diabetic patient.
Story 2: “I don’t want to create an issue of my diabetes in front of people in a social gathering. I will eat whatever is there to eat.”
People in India are not always very open about their condition. In the pressure of negative social reaction or any judgement, people stay to remain muted about their issues. The users of this app needed a space where they can talk about their condition and it’s hardships freely. The feeling that I am not alone, helps user psychologically. This inspired us to have a concept of community on the platform moderated by a diabetes coach or a doctor to give advise and let users exchange information and ideas on how to tackle this disease, without any inhibition.
6. “We got lots of insights from the usability study ”
An observation is what you see or listen and insight is what you make out of it.
The term Insight is used very loosely now a days in context of research outcomes. In my experience the first (and the easiest) research outcome is an observation, which is usually(and wrongly) shared or presented as an insight. If there is time pressure or the researcher does not dig deeper, the research outcome could lead to obvious results, hence undermining the process itself. In a 6–8 user research , if you get 5–10 ‘real insights’ you did really well. Don’t try to fill up 20 pages with insights, because they are not insights but merely observations.
If it’s too obvious it’s not an insight.
Not that the observations are not important. These really help in setting up the context and will make your story more interesting. In some cases these observations are important to define immediate product improvements. But a good insight will immediately tickle a lot of near and long term ideas and it will be something which will have the potential to drive a whole new product vision.
👉 Investment return calculator
ING wanted to present investment as an alternative to customers who have their money stashed in saving accounts, which for last few years gave almost no returns. The feedback was not very promising and conversion to real investment accounts opened was quite dismal.
During the research, we saw some obvious usability issues with current tool, but there were few insights which helped us understand the real barrier which users face before taking a jump to invest. Example of how an observation could lead to an insight
Observation 1 : Users want to understand the logic behind the return on investment shown in the calculator.
Observation 2 : Users want to play around with input, but are not sure of what to fill in in the fields like risk, duration of investment.
Observation 3 : Almost no one checks out the details of investment product or intent to call the advisor to discuss more after doing the calculation. (This was unfortunately taken up by the team as a usability problem, but there was a deeper reason not to click on these buttons. This misinterpretation of user tests deserve a separate article)
From these 3 observations , we deduce the following insight.
Handhold users, slowly till they are ready to invest : Users lack the knowledge and confidence to start with investment. They need time and plenty of guidance to understand the topic and make right choices.
Insights like these helped the team to try out a radically new design and rethink the whole idea of how we have been building such calculators.
It was not just about making the call to action more visible, but motivating users enough to find the button and click it.
Although, we are still working on this problem, as it’s a deep behavioural bias against investment, but as a team we have a fresh approach to solve this problem, which is deeply rooted in the user understanding.
7. “How did you infer this ? We spoke to just 5 users”
Insights will always have an element of your imagination. Don’t be afraid to extrapolate stories to predict the latent needs.
Avoid generalisations but, be brave with predictions.
With qualitative data, it’s hard to say anything with complete conviction. Use your designer’s hunch to derive insights from common patterns or data. There will always be someone who will question the source of truth and how did you conclude a particular insight. User stories come handy in this case. Reiterate the focus of your research is to sense latent user needs and not to create a matrix of user’s likes and dislikes.
👉 Investment calculator (again)
If you have read the example from the previous point ( if not, please do), you might think how was this insight derived. Is there a clear logical deduction from the observations. Answer is NO. But that was my interpretation of the facts. The insight touches upon basic human traits like we are risk averse and scared of change. If you can get some quantitative data to back your insights or some proven scientific findings to support your interpretation, use it further make your case stronger. But again I had only 2–3 insights of this kind. If I would have tried too hard to churn up new insights the result would have been less convincing. Also, these insights were meant for a certain group of users. Not everyone is scared of investment. So choose your target group / persona as well before doing research and deriving insights from it.
I hope this can help my fellow designers / researchers in their routine work. I am very curious to hear more success/failure stories and how can we further improve the knowledge and acceptability of user research within organisations.
Source link https://uxdesign.cc/user-research-but-why-2d399182637b?source=rss—-138adf9c44c—4