What is generative research?

Generative research is an exploratory technique used to understand users’ experiences, needs and behaviours and generate insights to support design and delivery. The goal is to identify problems to be solved first, rather than jumping straight into solutions and validating the idea with users afterwards, which risks teams building the wrong thing. By gaining an in-depth understanding of users’ motivations and challenges, teams can build empathy with their user base and explore solutions that meet user needs.

Generative discovery can take different forms: 

Interviews: At the Department for Health and Social Care we conducted video interviews with overweight people with comorbid health conditions to understand barriers to accessing weight management services. This helped us to understand the needs of a wide range of users and make recommendations for improved signposting into digital services.

Contextual interviews: At the Ministry of Justice, we visited prisons to see how staff accessed and used data, to help understand how to replace a legacy reporting service. This allowed us to see user challenges first hand whilst using existing tools, and understand the environment. Is it noisy, what technology are people using, what workarounds do people use, and how could they be turned into opportunities for a new service?

Observations: At Pret a Manger, we visited coffee shops to observe the flow of customers, and to help understand how new digital services would intersect with in-store processes. If your prospective service has an offline touchpoint or will be used in a specific environment, immersing yourself in the environment and trying out services can help you to design a service that solves a whole problem for users, on and offline. In this example, seeing the flow of customers in store meant that we were able to make recommendations for how collection points could work for a new online ordering and digital messaging service.

Ethnographic research: At Jio we shadowed broadband installers in Mumbai to understand staff and customer experiences of broadband installation. This helped us to identify opportunities for new digital tools that track installation. We created customer journey maps to better understand the challenges faced by end users, and support the design of a new app for installers. 

Surveys: One to one conversations are the preferred method for generative research so you can dig in with follow up questions and see context. However, surveys can be used to supplement this information and gain insight from a broader range of users. At the Department for Health and Social Care we also sent out a questionnaire with exploratory questions, which enabled us to gain insights from a broad range of users that were harder to reach through interviews. 

Common questions

I’m replacing a legacy service, do I need to do this?

Yes, often working practices have evolved around systems rather than actually supporting users to do what they need to do. Investing time in some formative research helps to uncover unmet user needs and pain points, ensuring existing inefficiencies are not baked into a new system. 

Can’t we just do prototype testing?

It’s tempting to jump ahead to prototyping solutions but there is a risk of making assumptions about the right problem to solve and partially deciding the solution. Once you start down this road it can feel much harder to go back from here once money has been spent and stakeholders are invested in an idea. It’s easy to come up with ideas; the trick is selecting the good ones that solve real problems and add value. Generative research will give you the evidence and confidence you need to choose the right solution.

Even if you have a couple of different ideas to solve an assumed problem, there are risks in showing users multiple prototypes and asking which they want most. Cognitive psychology has taught us that humans don’t have reliable insight into why they make the choices they make, so we can have little confidence in asking users what they want and why. 

We have a few ideas already – can’t we just get started?

David Travis and Philip Hodgson share a useful anecdote illustrating this issue in a brilliant book called ‘Think like a UX researcher’. In a consumer study, people were presented with four pairs of identical ladies’ tights labelled A, B, C or D. All of the tights were identical but the majority of users chose option D. This was because of a known position effect, where people have a tendency to choose things from the right hand side. More interesting is the fact that people were able to give reasons for why they had chosen pair D, for example that they were better quality or they had more elasticity.

By exploring needs, rather than wants, through carefully curated open questions and observations we can start to uncover users’ challenges. This helps us to be confident that the solutions we’re proposing will solve real problems and delight users. In the example above, if tights are our ‘product’, we haven’t learned if people actually need to buy tights, because we forced a decision upon them in the research. We can conclude that if people want to buy tights, they want them to be good quality with good elasticity, but what if the solution people needed wasn’t actually tights? Perhaps the real problem is something else: keeping legs warm, dressing modestly or making a fashion statement. We won’t know unless we ask open questions. By giving people a solution before we fully understand the problem and asking them to choose A, B, C or D, we limit our opportunity to identify the right thing. 

How to conduct generative research

Successful generative research should follow the steps below. You can read about these steps in more detail in this blog post.

1. Identify your goals – what are you trying to achieve?
2. Create an interview plan to meet these goals
3. Identify users from each subsection of your target audience 
4. Run the research including interviews and observations 
5. Analyse and synthesise the data into themes
6. Create actionable insights from the analysis

How to make sense of the data

You’re going to generate a lot of qualitative data through the research and this can feel overwhelming. Avoid analysis paralysis by remembering the goals you defined in step one. To make sense of data, you can run a ‘thematic’ analysis. You’re looking for:

Commonalities in the kinds of things users say – this can help you identify the biggest pain points or opportunities. 

Differences in what different groups of users say – this can help to establish different personas for your target product or service. There are a number of practical ways to collate and sort this information, including: 

• Capture insights in a spreadsheet, and turn them into Post It notes using a digital whiteboard tool such as Miro, then start to group them into themes
• Use a specialist digital tool such as Dovetail to tag the data and identify themes.
• Go old school and stick insights on Post It notes on a big wall

Whichever method you use to collate data, start by identifying big themes like ‘pain points’ and ‘plus points’. Perhaps the pain points theme can be broken down into further subgroups, like time management, technology challenges or quality of data. 

The words that users choose are important here, so try to flag some of these in your analysis, as they can help you understand the mental model users have of the problem area. Natural language can be really helpful in the later design phase to produce content and name new products and services in a way that resonates for the target user.

Analysing findings can easily take double the time taken to run each interview, so it’s important to budget adequate time to explore data.

How to turn insights into something useful

Your insights can help you to identify the needs that must be met to solve users’ problems. You can communicate these as user needs or as jobs to be done. Be careful not to solutionise at this stage; it’s important to get to the roots of the problem before trying to solve it. Involving your team can be helpful in identifying appropriate actions from your insights. 

A well written user need communicates the problem to be solved without solutionising. For example, as an events planner, I need to know how many people will be attending my event two weeks in advance, so I can plan how many staff I need to run the event.

When you have the problems formulated, you use techniques like ‘How Might We’ statements to start generating ideas. Let’s imagine we have found through research that users are reluctant to buy from smaller retailers online because they are worried about the returns process. Turning these problems into statements can highlight opportunities for a product or service that we are confident meet real user needs.

You might also want to map these user needs visually to bring the information to life for the team. This could be as personas which communicate user needs for different types of users and user journey maps which can show the experience at different touch points across a given task. 

Insight: some customers are nervous to shop online with small retailers because they are worried about the time and costs associated with the returns process
How might we: How might we create a fast and seamless returns process?
How might we: How might we provide all the information users need to feel confident in placing an order knowing that they can return it if it’s not right?

Can we design something yet?

At the end of this activity you might find that people don’t really need to solve a problem in the area you were expecting. Don’t be disheartened, money has been saved on building something that wouldn’t add value and you can now use the insights to pivot to a different area with confidence

If you identify a problem to be solved you can start sketching ideas for solutions at this point. For every solution you and the team come up with to solve the problem, cross reference it against how well it meets the core user needs you have identified, as well as technical feasibility and complexity to deliver. 

You can do this in a simple table, working as a whole team to formulate potential solutions and weigh them up against their feasibility and potential to help and delight end users.

The next step will be validating these ideas with your end users through the opposite of generative research- evaluative research. Methods like prototype testing and A/B testing can help you to validate with users that you have got the solution right. This can then be fine tuned through ongoing feedback loops with your end user. 

This sounds long winded, do we have to do it?

Generative research can help reduce the risk of delivering something that users don’t want, or missing the opportunity to identify solutions that would add the most value. By spending time gathering insights and evidence about user behaviour you can build confidence in the solutions you are proposing. You may feel reluctant to commit to the cost of a discovery but this can be done with a fairly small team. It may be easier to justify when you consider the alternative costs of building the wrong solution, lost revenue, reputational damage, staff inefficiencies as well as development costs incurred by staffing engineers, QAs, maintenance and support for the wrong solution.

Discovery is a way to understand what the best problem to solve is and identify the most valuable ideas to progress, in order to reduce the risk for what you choose to invest in during the design and build.

We recommend approaching a discovery from three key angles – Desirability, Viability and Feasibility.  We’ve seen this result in a more robust outcome that teams can feel confident taking forward. 

However discoveries take all different shapes and are set in different contexts, and can be useful at  different stages. The recommendation above applies well when evaluating new ideas for example. Understanding what you want to get from a discovery is the first step, what is it that you hope to learn? 

 

In this article I will explore some different types of discovery including:

• Strategic Discovery
• Value Proposition Discovery
• Product Discovery
• Feature Discovery

to look at why we do discovery, what we do and who is involved. 

Strategic Discovery

A strategic discovery can be helpful if your teams lack alignment and direction about what to do next and how to get there. This could be in relation to changes in the market, a need to move reduce operational cost or a desire to grow and improve.  By understanding your  own problem space and collaborating to uncover challenges and opportunities, it’s possible to find clarity.   

Scenario: we have a long running, successful service for our customers and now  want to increase sales,  introduce digital tools for operational staff and improve our customer experience.

• Strategic Discovery would explore the current ‘as is’ situation, reviewing the existing customer experience and identifying pain points and opportunities.  By understanding  users and their needs, we use this insight, as well as stakeholder feedback to explore the problems to solve and visualise an ideal experience to act as a ‘North star’.
• In Discovery, interviews with employees would consider their current workflow and highlight ways that digital tools could help and provide a better  experience when completing tasks. It is likely to  include a review of the current  technical architecture and platforms.
• Competitor research can provide a broad view in discovery of what others are doing, to understand the market direction and take inspiration or define how to stand out. Identifying clear KPIs to measure would be included.
• Discovery would examine the sales pipeline from start to finish to understand the multiple touchpoints and channels a customer might engage with before converting. Customer feedback and engagement data can provide insight into where the opportunities lie.

A strategic discovery would be led by a product manager, user researcher, service designer and technical architect, with engagement from other business teams and senior stakeholders. 

The outcome of this strategic discovery would be a clear, shared vision and set of outcomes that the business can work on together to achieve over time. During this process the main enablers and functionality required this would be identified. This would show the role different teams might need to play across the organisation, from operations to digital to marketing to legal. 

Value Proposition Discovery

A Value Proposition discovery is well worth considering if you have a new business idea and want to evaluate it.  It’s a chance to  explore how commercially viable it might be, do your users want it, is the time right,  and what will it take to build and maintain it. Discovery helps you test your hypotheses and drastically reduces the risk in progressing.  There are no shortage of ideas out there, however choosing the most valuable idea to progress right now is the hard part.

Scenario: we have an idea for a new value proposition that we hope to bring to market.  We want to create a subscription service for customers and increase customer retention.

• Discovery would include looking at subscription engine products, integration and licence costs. As well as fraud and risk management, data governance and security, teams would also want to explore operational support and technical readiness.
• Discovery would involve research – competitor research  to review how others model their subscription service and what their offer is to customers.  With customer research to understand what problem we are trying to solve, as well exploring expectations, behaviour and needs in relation to the new  service. 
• Discovery would include working with finance, legal, operations, customer services and trading teams to explore price points, costs and business viability of the proposition design. Service designs would visualise how different teams would deliver a service like this, exposing complexity and dependencies early..
• Discovery would be a time to pilot the idea with customers and employees to test and learn what works and what needs refinement. This might include conducting technical spikes and creating proof of concepts to test assumptions, this will  de-risk the technical approach as well as ensuring  a great customer experience.

This type of discovery would be led by a product manager, user researcher, service designer, working closely with a UX designer, an SME and a technical architect, with engagement from other teams in the business and decision-making from senior stakeholders. 

The outcome of this type of discovery would be for the business to be able to make a confident go/ no go decision about a new proposition, with a clear understanding of the investment required, dependencies, the time to market, the customer behaviour expected,  and the teams needed to deliver this proposition.

Product Discovery

The  Value Proposition Discovery approach can also be applied when levels of engagement are lower than expected for a product you’ve already created, or users aren’t engaging as expected, resulting in a lower completion rate or low ROI.  The temptation might be to keep adding more features and continue in the hope that users will eventually come;  another approach might be to kill the product altogether and walk away.

In our experience, pausing and spending time with users to understand their broader needs and get feedback on the product that exists today is a useful step. Feedback is invaluable and no matter how brutal it may be, it provides a much clearer view of how the product is perceived and used today. Research can uncover  what’s missing, where the friction is, whether it solves a real problem and why users might be choosing to go elsewhere.  Armed with this insight, teams can make informed decisions to change direction and re-imagine their product,  remove it, or target a different user group. 

In our work with a government department, we ran a discovery to understand why the uptake of a free health related service was so low, despite the investment it had received. Conducting a broad discovery, we spoke with the target audience to understand how they access similar services; this included the providers of the service and those who fund and procure services across the country, to understand how the current service operates. Our focus was on awareness and access – sometimes you can create a great thing, but if no one knows about it, or it’s hard to access, they won’t be able to use it. We were able to make 5 key recommendations enabling the policy makers and government team to move into Alpha with ideas to test and measure.

Feature Discovery

Adding new functionality to an existing product is what keeps customers happy and enables the business to respond to change.  To avoid a solution being applied to the user experience based on assumption, a short discovery will ensure that the new feature is well designed, simple and easy to use, doesn’t negatively impact other parts of the user experience and adds value. It’s all in the detail. 

Scenario:  we want to introduce account functionality to our customers to help us connect with our users, make relevant products and services available, and provide a place for them to manage their details and save preferences. 

• Discovery would be to understand what the user needs are for the account, what are their expectations, and their current behaviour based on other accounts they have online (e.g. be able to use social log in or 2FA).  This would also be a chance to conduct competitor research and analysis to provide insight on trends.
• Discovery would include understanding the software and technical choices for running customer accounts (data protection and governance, authentication etc), conducting technical spikes or creating proof of concepts.
• Discovery would identify the KPIs and business needs that the account functionality would serve and how we would measure this.
• Discovery would provide a chance to explore a range of ideas and prototype the user experience to gather feedback quickly from users, testing any assumptions about the journey flow, content and interaction. A prototype also helps everyone have a shared view of how the new feature will behave and what the interaction might feel like.
• If any existing account functionality exists, via a third party for example, then we would also consider the migration approach, how to move existing customer data and communicate clearly with those customers moving to a new account.

This type of discovery would be led by a product manager, user researcher, user experience designer, content designer  and technical architect, with design walk throughs and research playbacks for stakeholders.  

The outcome of this type of discovery* would be to agree the scope and requirements for new functionality or a new feature to be built, and have high confidence in the user experience design.  From here the backlog can be created and development work can begin, knowing that we are building the right thing.

* In a UK government setting, this work would span discovery and alpha phases, with development happening in Beta, into Live. Outside of government, this is all discovery, going into delivery. 

At the Co-op, a major UK retailer, we designed and built an employee tool to manage rotas, including sickness and leave, replacing  the paper based process that existed before. We spent time with employees in shops, including shop staff, shop managers to understand their environment and current ways of managing shift rotas. We used prototypes to ensure the new tool met those different user needs and designed an inclusive experience that was easy to use.  Investing in time with users, led to 85% voluntary adoption of the tool across 46,000 employees in less than 6 months. 

Summary

By investing in a strategic discovery, you ensure that as an organisation, there is a shared view of where you want to get to and why – you have the bigger picture and direction. This in turn informs the teams across the organisation and provides the alignment so often craved for, joining the dots.  The teams can then discover how to release products and features that provide the most value and solve real problems.  Before a shorter discovery to explore the best way to design and build experiences to meet user needs, and deliver successful business outcomes.  

Over time, stable product teams would be doing continuous discovery alongside continuous delivery to keep their product up to date with new features and functionality,  and perhaps more importantly, continue to adapt and to respond to change.  More on this in a future post.

Conducting discovery at these different stages will ensure that you design and build the right thing with confidence. If you are considering running a discovery of any kind and think we can help, please get in touch.

 

Over the past few years, running inceptions has become the default pattern for kicking off new development initiatives within Equal Experts.

We find that running inceptions offers the team and the wider stakeholder group a foundation from which to kick off a new piece of development, which gives it the best chance of being successful in the months that follow. 

When we first started formalising the inception process, we found that although we had many very experienced practitioners at Equal Experts, there wasn’t a consistent approach to running inceptions. Unlike earlier stages in the product lifecycle, for which tools like “Design Thinking” exist, the processes that are required to kick off a delivery still didn’t have a common language or framework.  

Our Inception Playbook is our attempt to provide that generic blueprint for knowledge-sharing and inspiration, and it is a starting point for teams that want to kick off a new development initiative on the right footing. 

Who it is for

Early on, we decided that we wanted to cater to a wide range of users: starting with practitioners who have never run or participated in an inception through to those who regularly perform them but want some tools that allow better planning and maybe a sprinkle of inspiration. We also felt that clients might be interested in framing what Equal Experts mean by ‘running inception’ and provide a helpful ‘leave behind’ post inception; so they can be more effective in kicking off projects in the future.  This has already extended to our clients taking this as a blueprint for building their own Inception capability in house. 

How it can help you

• If you have never run an Inception before, this is a ‘training’ manual to peruse.
• If you have run an Inception before, but need a refresher, this is your reference.
• If you are a seasoned Inceptionist and need practical support, the agenda, schedule blueprints, and cheat sheets are your starter for ten. 

What can you expect from our Inception playbook?

Based on the feedback we have received, we believe our first public release is valuable; it has depth, relevant details and can be used both as a training document and a practical guide.

It is reasonably polished in the sense that we have done some basic copy editing and design. We have an on-screen PDF-version alongside a digital version both of which are located here https://playbooks.equalexperts.com/inceptions

What it is about

It is worth noting that the playbook is a game plan in the sense that it is not a recipe for a single activity but an orchestration (and supporting tips, tricks and detail) of a large number of activities that altogether make up a successful Inception.

The playbook touches on topics such as

• What is an Inception, why do one and how to get buy-in into your organisation
• How to successfully plan an Inception
• How to execute an Inception
• What good looks like
• What common pitfalls and best practices are

What it is not about

Discoveries. Early in our writing, we found that there are two types of beginnings:

One is where we have a vague idea of some product or service that may provide value but are not sure about whether this is true or how this should take shape. In these cases, we would start with what we have decided to call Discovery: top-level analysis, research, hypothesis formulation and experiment to solidify the value proposition. This is very much about exploration.

Once this is clear, i.e., we have a relatively solid idea of the shape of our initiative, we now want to ensure that we are set up for success and can hit the ground running, so we do an Inception. An Inception is about validation (rather than exploration), aligning and defining (at the highest level). To be clear, we can still do all the good, lean stuff like experiment during Inception or during the actual delivery, but we will do so within the scope of delivery rather than at the level of rationale of that initiative.

In the most basic terms, Discoveries are about doing the right thing while Inceptions are about doing it right.

Our playbook ONLY covers Inceptions.

Contact us! 

We hope you find this playbook useful. If you’ve used it to run an Inception or have feedback of any flavour, we’d love to hear from you. We offer training on Inceptions, and, of course, we are pretty good at delivering software. 

‌Share thoughts, ask for updates, templates and other information, or get in touch if you are interested in working with us, at https://www.equalexperts.com/contact-us/