Katie Palermo

Get to know Katie

Get to know Katie's Work

Service design

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 cases 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: Measurment
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 or scale the


Workshop Planning

I began a listening tour where I interviewed members of product, design, and development to understand their perception of the requirement gathering process.


That lead to uncovering additional SMEs that are typically consulted by product in the requirements gathering process but where unknown to the design team.


We found there were natural silos in the process that happened because the product team are responsible to so many teams and they have limited time.

I began a listening tour where I interviewed members of product, design, and development to understand their perception of the requirement gathering process.


That lead to uncovering additional SMEs that are typically consulted by product in the requirements gathering process but where unknown to the design team.


We found there were natural silos in the process that happened because the product team are responsible to so many teams and they have limited time.

I began a listening tour where I interviewed members of product, design, and development to understand their perception of the requirement gathering process.


That lead to uncovering additional SMEs that are typically consulted by product in the requirements gathering process but where unknown to the design team.


We found there were natural silos in the process that happened because the product team are responsible to so many teams and they have limited time.

PHASE 1 - What do we know

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

When demonstrating the process to various stakeholders it became clear that they had trouble understanding the insights and process. I created a rough draft of the process which resonated and allowed us to discuss the issues specifically.


It also allowed me to talk through the steps, identifying what is currently working well and where there are opportunities.

When demonstrating the process to various stakeholders it became clear that they had trouble understanding the insights and process. I created a rough draft of the process which resonated and allowed us to discuss the issues specifically.


It also allowed me to talk through the steps, identifying what is currently working well and where there are opportunities.

When demonstrating the process to various stakeholders it became clear that they had trouble understanding the insights and process. I created a rough draft of the process which resonated and allowed us to discuss the issues specifically.


It also allowed me to talk through the steps, identifying what is currently working well and where there are opportunities.

Desirability, Feasibility, and Viability scoring

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

In order to demonstrate the current process, I created a visual map to lay out what happens when things go well.

In order to demonstrate the current process, I created a visual map to lay out what happens when things go well.

In order to demonstrate the current process, I created a visual map to lay out what happens when things go well.

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

Get to know Katie's Work