Requirement’s Gathering
Background
Sometimes the best way to help customers is by improving internal experiences.
Problem:
Design requirements received are often incomplete or are provided late in the workflow. As a result, the design team either delays the work or begins with limited context, which can ultimately result in delays or rework. Our goal is to collaborate with the Product team to figure out how we can reduce the overall delivery timelines by exploring ways to:
Improve the requirements gathering + delivery process (including the initial information submitted & the interactions with design to refine those requirements)
Optimize how the design team moves forward with partial information
Clarify roles & responsibilities across product & design related to requirement definition
Primary goals:
Define the current requirements gathering process.
Understand the current design approach when moving forward with partial information.
Identify areas where the requirements gathering process may break down or there are gaps that impact other teams (ex. In team-wide visibility).
Co-create a system that will allow for effective requirement gathering and cross-functional communication.
Define the DoR and what meets the threshold for the design team to start their work.
Identify what is 'need to know' versus what is 'nice to know'
Set a standard to identify when requirements do not meet DoR, how that is communicated, and next steps.
Determine pilot project to pressure test the new process.
Identify KPIs to measure progress of the pilot
Shadow goals:
Improve partner perception of these types of collaborative sessions.
Strengthen cross-functional relationships.
Increase effective cross-functional communication on difficult topics in a productive manner.
Ensure it feels like one
Methodology & Research Questions
A mixed-methods approach was used to collect qualitative and quantitative data. In-depth user interviews were paired with usability tests on wireframes and prototypes, while surveys and analytics reviewed conversion rates and task completion times.
Phase 1: Listening tour
We will first examine what is known through a listening tour. The listening tour will create a baseline of what we know about requirements gathering today, who is involved, what causes delays, what does the handoff process look like and how the design team approaches the work based on what is available.
Phase 2: Pilot Planning Session
A small group of 6-10 relevant stakeholders will be taken through our current state (determined by the listening tour) and asked to collaborate to better understand how might we improve this process when gathering/communicating-requirements & when moving forward with partial information. We will define and agree upon a standard for what meets DoR and what is 'nice to have'.
Phase 3: Socialization
A pilot project will be chosen (either as a team or at the leadership level) where we will pressure test the new system. The project team will be brought together and walked through the pilot process by cross-functional partners to increase buy-in.
Phase 4: Measurement
Areas of difficulty and gaps will be communicated on a regular basis during the pilot. After the design phase has concluded, designated participants will come back together to score the effectiveness of the pilot and determine ways to iterate and/or scale.
Listening tour
Empathy Mapping
The UX team had no ability to get the product team on board with this project. Therefore, taking information learned in the listening tour, an empathy map was created.
This was then presented to the product leads as a way to demonstrate we understood their limitations and were committed to helping them sort through their priorities.
By building empathy with them, we were able to shift the frustration felt by the design team to better understanding their obstacles and deepening the relationship.
Roughly building out the process
Refineing the process map
To continue reinforcing the issues at hand, a process map was created. The stages correlate with the flow chart and this breaks down each groups' responsibilities, the tools they used, pain points, and assumptions.
Define the happy path
The overall flows
Then I created a process map that demonstrated what is typically happening when design projects are taken on.
Doing this visually showed all of the various moments throughout the journey were there are break downs and there are opportunities.
Get to know Katie's Work