This is a set of defaults for teams to use, but is not mandatory if teams have good reason to do something different (see What this is — and is not).
This section covers the research and analysis needed to interrogate an initial idea or business opportunity and inform subsequent design activities or the definition of requirements such as "Users should be able to save their progress" or "How do we improve our cross-sell conversion rate?"
Starting from existing knowledge or doing a small amount of research or analysis helps you validate opportunities to ensure you work on the right things and so avoid waste.
Don't start from scratch
By the time we join, most clients will already have gathered and documented some information and may have previously conducted research or analysis. Examples include customer satisfaction surveys, business process flows, technical architecture diagrams, analytics, Business Intelligence reports and competitor analysis, and these are all helpful starting points in identifying knowledge gaps to explore further.
Start by gathering together existing information and analysis.
Keep it lean
To minimise waste and avoid 'analysis-paralysis', keep your initial research and analysis as lean as possible. Do just enough to decide on a direction of travel and identify the main challenges you may encounter without attempting to map out every detail or step of the journey.
The best outcomes are achieved when everyone in the team has a common understanding of the problem-space. Ensure that your research and analysis is representative of all relevant users, stakeholders and any technical or organisational constraints, and takes into account those with the most challenging needs.
If you do not understand who your users are or what they need, you can't build the right thing. That is why you should start any new engagement by learning about the people who will use the product you are building, through research and anlysis. Be sure to include internal users or people who provide the service in your research, such as call-centre staff or caseworkers. Not only will these people improve your understanding of internal user needs but they often have rich insights and empathy with the customers and users they serve. Maximise your research findings by understanding and applying a variety of research methods to gain specific insights.
Here are a selection of techniques that span the range from qualitative to quantitative and attitudinal to behavioural. These characteristics are compared in Qualitative vs. quantitative and Attitudinal vs. behavioural.
Qualitative vs. quantitative
Qualitative involves the direct observation and study of participants and help you understand people's motivations, thoughts, and attitudes. It often provides deeper insights into the unique experiences and needs of individuals which in turn can create a greater degree of empathy within the team. Examples of qualitative research methods include interviews, diary studies and moderated usability testing.
By contrast, in quantitative research, the data about the behaviour or attitudes in question are gathered indirectly by asking people or measuring what they do using approaches like surveys or user analytics. Quantitative research can provide more statistically significant insights about shared behaviours and differences of a group or demographic.
You should use a combination of qualitative and quantitative methods.
Attitudinal vs. behavioural
This can be summarised by contrasting "what people say" versus "what people do" since very often the two are quite different. The purpose of attitudinal research is usually to understand or measure people's stated beliefs, whereas behavioural research seeks to understand "what people do" with the product or service in question.
Generative vs. evaluative
Generative research occurs early on in the solution development life cycle as a way to ensure customer problems and opportunities are understood, with the goal of informing the development of solutions. Once solutions or ideas have been developed in response to generative research, that's when evaluative research will occur to identify whether the solutions successfully solve customer problems or address opportunities.
Business analysis entails understanding and organisation's goals, needs, structure, processes, policies, and operations. By gaining a clearer understanding of each of these areas, you identify areas for improvement and develop solutions which are aligned with an organisation's goals, that acknowledge and cater for important dependencies and constraints, and that support organisational change.
Technical / systems analysis
Technical, or systems, analysis refers to understanding the technology landscape a new or replacement service might exist in. This might involve reviewing the technical architecture, technology stack, release process, technical design and governance process, integration points or stakeholder landscape. By delving into these areas you be able to determine which constraints you need to influence (soft constraints) or work around (hard constraints).
If you are working with an established organisation, or are looking to replace or improve an existing service, there is a good chance there will be some relevant data sources that can help inform the design of a new solution. It is also be useful to understand where your new solution will need to read or write data from, such as a database or data lake. Data analysis entails identifying, collecting, evaluating and sometimes and connecting relevant data source to understand trends and patterns in the data, as well as constraints and opportunities.
Competitor / market research
Looking at how others have solved a similar problem can give you a valuable starting point from which to base your designs. There are lots of vendors and tools available to support in-depth competitor research, however, simply using your competitor's products and services yourself, or inviting your users to, can generate valuable insights and ideas. Depending on the competitiveness of the respective market, it can also be useful to understand your competitor's strength and weaknesses, to form a benchmark which you can evaluate your solution against. While competitor research can provide useful input into your product strategy, it should not act as the primary driver:
"Customers don't leave us for our competition; they leave us because we fail to meet their ongoing needs." — Marty Cagan, Silicon Valley Product Group
Having gathered some valuable information and context you should be in a better place to understand whether there is a valid problem or opportunity — and the potential value of addressing it.