Bring stakeholders into the process and draw on their expertise
1c. Discovery research
This section will help you:
Manage expectations and get buy-in
Understand users, their jobs, and their challenges
Define the actual problem and state it clearly
Set goals and key performance indicators for the project
Common challenges
You may encounter these frictions as you do the work of discovery research. These are challenges the Recommended actions are designed to solve, or that may arise as you take those actions.
Focusing on existing products
It’s common to have existing products in mind as you start a software sourcing process. However, jumping to existing solutions without defining the actual needs can lead to buying something you don’t need, or limit the possibility of innovative, better-than-expected solutions in the long run.
Lack of creative confidence
There is a myth that civil servants aren’t, or can’t be, creative and can’t design software. This is false! You are the person who is best suited to understand the problem and imagine solutions. A good development partner will integrate your design input.
Insufficient or ineffective user research
Not addressing the end user can result in building something that is incompatible with the day to day nuances of their job.
Lack of resources for discovery research
Not having adequate time, resources or knowledge for a discovery research phase undermines the entire procurement and development process. Allocating sufficient time and budget for initial discovery work will save money and frustration in the long run.
Recommended actions
1. Doing discovery research
Discovery research is a way of getting close to the problem at hand. Many different methods can be used, but the overarching goal is to understand the technical, social, procedural, and subjective dimensions of the problem you are trying to solve or the process you are trying to improve—with an emphasis on the end user.
The following design research tools are useful ways of understanding users:
Cognitive walkthrough
Contextual inquiry
Workshops with key stakeholders
Stakeholder
and user interviews
Dot voting
Five whys
Heuristic evaluation
Mapping out opportunities, challenges,
ideas and fears
Use discovery research tools and methods
Engage with various different groups of stakeholders to ask questions, surface ideas, and prioritize them.
Software should always be in service of its actual users. For that reason, the procurement process begins with mapping out who those users are, understanding their roles, understanding their expertise, and documenting the risks and challenges they face. User profiles (also known as “personas”) describe operational procedures as well as subjective experiences. Think of these user profiles as a description of a real person and a day in their life at work. Of course, your write-ups should be anonymous, incorporating elements from several different end users.
Embed with the end users
Accompany a municipal service delivery department employee and document specific requirements of the tasks they perform.
Consider other users who are involved
This may include superiors, auditors, people who read regular reports, or people in other departments whose work interacts with the user you are focusing on. Begin to create additional user groups as needed.
Create personas for each user group
These are fictional but highly detailed descriptions of prototypical users who interact with the software. They should incorporate insights from several different real people.
Write user journeys
Describe the current job of the end user. Write down their workflow, pain points and goals. Repeat for individuals in each user group. Here is an example—use this as a template, or create your own.
Greta Hansen, 27
Transit Data Analyst
Motivations
Meet delay reduction KPIs
Learning to code with React
Risks
Gaps in service delivery
Public perception of transit efficiency
Changing political priorities
User story
Greta is an early-career transit data analyst who was recently hired by the Tulsa
metropolitan transit authority. Her job is to use existing data sources—and identify new
ones—that help to predict and reduce delays in public transit services. To do this, she is
building a workflow on top of the transit authority’s existing API.
3. Writing a problem statement
Successful software procurement requires a clear definition of the problem you aim to solve. This short written document details the problem and accurately reflects your discovery research. Put careful thought into the problem statement – it will be the thread that runs throughout the entire software sourcing process.
Consider your user research
Identify a number of problem(s) that need to be solved. Meet with associated stakeholders and collaboratively prioritize problems. Keep looking for multiple problems that are complementary—problems that have similar causes, even if they look different.
Write out a problem statement
Agree on a clear, meaningful problem that needs to be solved (and be open to the possibility of solving it without software!). The problem statement should be concise and written in clear language.
4. Defining Key Performance Indicators (KPIs) and broader goals
The problem statement should be accompanied by specific metrics, milestones or observable improvements that indicate the problem has been solved (often known as Key Performance Indicators, KPIs, or outcome-based targets).
Write down broad administration goals, commitments and objectives
As they relate to the problem, include things like climate change targets, social equity commitments, local economic development, returning citizens.
Write down the broader departmental goals
As they relate to the problem.
Write out your KPIs
Review the problem statement and consider how you might measure the success of a solution. Also think about how a solution could advance departmental or administration-wide objectives. KPIs can include both.
5. Underwriting the problem statement
Everyone involved will refer to this and the KPIs throughout the procurement process. These will guide your work, empowering you to design a successful solution. All associated stakeholders must have reviewed these before moving forward. Early buy-in and aligned expectations will reduce risk and save significant time over the course of the procurement or design process.
Get stakeholders to sign a unified document
Collect the research, user journeys, problem statement, and KPIs into a single document, then “underwrite” it—have stakeholders literally sign the document.
Software may not be the best or only solution
It’s easy to assume that new software will solve all of the complex problems you and your
colleagues are facing. But sometimes software is not the only or best solution. Once you’ve written
a problem statement, KPIs and goals, take some time to explore many and varied ways of approaching
the problem and achieving your goals without software. Consider:
Changes to bureaucratic processes, budgeting, or policy directives.
Communications and shifting departmental norms.
Partnerships with outside organizations.
Takeaways
Create or complete the following outputs before moving on to the next step.
Documentation of discovery research
User profiles and user journeys
Problem statement
Broad goals and detailed KPIs for the project
Further reading
1.
CityMart
Defining needs and setting intention
2.
3.
4.
The Atlas
Free Procurement Toolkit For Cities
A toolkit to help government officials to develop a clear problem statement and select the most appropriate procurement approach for the issue they want to solve.
5.
Interaction Design Foundation
Personas—A Simple Introduction
6.
UX Collective
Understand and define users with the User Profile Model
