Service Design Case Study
The Challenge
GPC is an old company, doing business for over 100 years. The software is difficult to use and hard to manage. Our customers demand correct data from NAPA. How might we provide up to date and correct data using a legacy software?
The Approach
Conduct user interviews and research studies, field visits, internal and external workshops, and ideation sessions with product and business.
The Outcome
A blueprint for how to run an internal team and use it's legacy software to the best of it's ability to serve the customers, partners, and internal stakeholders.
“I have a powerpoint that has all the steps....It’s just such acumbersome complicated system.”
Supplier for NAPA Auto Parts
Research Participant
In the auto part industry, there is what comes with the car (OE - Original Equipment) and something a manufacturer has made to rebrand what came in the car AE( After Market Equipment). This goes for farming equipment, fleet vehicles, industry specific vehicles (ambulances, firetrucks, etc) but our main focus for this project was to focus on the average consumer / driver. NAPA stores support this industry by selling car parts from multiple suppliers, to multiple car repair shops and the hobbyist customer coming into a retail store. NAPA does not manufacture parts itself, so it partners with these manufacturers we call suppliers. These suppliers not only sell us the part for resale but have to tell NAPA's back end system all of the information about the part, what cars the part fits (or doesn't fit), and equivalent parts out there (interchange number). This is just a little context needed to understand the challenge.
The technology used to hand over information from supplier to NAPA is legacy and difficult to use for both the suppliers and internal employees trying to read the information and manage it. The clunky back end software also had very little reports or quality control. This industry relies heavily on the correct information being published to the retailer websites. If even a few words or numbers are wrong, the part could be mislabeled on the shelf, not only leading to things like loss of sale but also the breakdown of the customer's car. This problem for the industry has compounded over the years leading to perception around brands for having "good" data online, or "bad" data. Fixing a car is no easy task, and the parts are supplied from all over. The organization sought to reduce the cognitive load on both parties in order to load and manage the data faster, with more efficiency and especially to present correctness.
Phase 1 was to talk to these suppliers and learn everything we could know from their hardships with our internal software, but also to learn more about the industry as a whole. What are the expectations of the customers reading this data? We talked to both suppliers and customers during this interview phase. The methodology we used overall was to talk to suppliers and rank the different qualities they expected in both our software, and competitors.
Our first intake session for research started with gathering assumptions from our internal business and validate them with the suppliers.
Only two of the assumptions made by the company were true. Leading to the team realizing we had a lot to learn about what we didn't know. After this session we let the suppliers lead the way in a workshop format ranking their capabilities of the ideal experience. In the end the top 6 in order are; Efficiency, Help, Feedback, Quality, Control, Notifications.
We followed this up with a read out that showed how our current experience stacked up the the supplier's ideal what opportunities we could take and use to gain competitive advantage. This read out included a ranking system that we could measure ourselves against over the next year to ensure we were listening to the feedback from suppliers while creating this ideal experience. The next step was to start brainstorming HOW to meet these goals.
Phase 2 included two different steps. One was to identify the internal employees who manage the software, and what their experience was like, and the second was to work with them to improve it. By improving the internal employee's experience, you directly effect the supplier experience positively. This is an important part of service design. During the interviews, we found that the internal employees echoed a lot of the same grievances that the suppliers had while using and managing the software. Their jobs were to make sure the data was managed and correct with little to no collaboration with the supplier or the industry itself. They expressed being on a island. So enter the workshop, bringing them all together to interact with their jobs in a different way using a method called Business Origami, to think outside the box.
I turned each person, process and prop (software, hardware) into a physical object we could move and discuss on a large brown paper desktop. I used a toll road metaphor which was on brand for NAPA but also helped illustrate the different "gates" a supplier or internal employee had to pass to finally get this complex, difficult process done correctly. We also included billboards along the way with supplier quotes from our initial research, and roadblocks of pain points they experienced along the way to show both sides.
To pass each gate, you needed the correct set of data, in the correct format, from the right person in order to pass. We turned this process into coins and cash that you could write on the back of, but had to go to the right person to get the correct coin/cash. They noticed pretty soon how difficult it was. This wasn't the point we were trying to make. The employees already know how hard this process is for them and their partners. So after setting this foundation, we pivoted.
I asked the room what would make passing this gate more efficient? Soon the people in the workshop from all different departments were working together to accomplish passing each gate, even rendering some gates obsolete. I facilitated this whole process until we were satisfied with the process, and checked our work for quality control (remember that data has to be correct not just fast to collect).
After the workshop, I consolidated the solutions and risks we learned from each department/person at the table into a presentation for our leadership. It included a new way of working with the legacy system as replacing it was out of budget for the year. It pitched that if collaboration and space was created for the different departments in the company, they could better support the supplier's data on intake.
This would help the team responsible be able to focus on the management and correctness of the data as it's published to retailer sites.
Each department taking on a slice of the project and setting up processes to make sure they were all aligned monthly. It also included a plan to open communication with suppliers on a more frequent basis to improve the relationship so when problems did arise, they were handled more efficiently and without damaging the companies reputation. I provided them with multiple kinds of information architecture based on both the research and the workshops we ran so they could efficiently train their teams.
Finally I was able to create a service blueprint for each department and their ongoing roadmap working towards this new future state journey. We used it to define our roadmap and which department was responsible for what implementation. It also included a detailed ecosystem map showing the different software interacting at every stage. This project is still in the process of implementation today! The blueprint has been blurred as it contains sensitive information about the teams at GPC and their process.
Service Design Case Study
The Challenge
GPC is an old company, doing business for over 100 years. The software is difficult to use and hard to manage. Our customers demand correct data from NAPA. How might we provide up to date and correct data using a legacy software?
The Approach
Conduct user interviews and research studies, field visits, internal and external workshops, and ideation sessions with product and business.
The Outcome
A blueprint for how to run an internal team and use it's legacy software to the best of it's ability to serve the customers, partners, and internal stakeholders.
“I have a powerpoint that has all the steps....It’s just such acumbersome complicated system.”
Supplier for NAPA Auto Parts
Research Participant
In the auto part industry, there is what comes with the car (OE - Original Equipment) and something a manufacturer has made to rebrand what came in the car AE( After Market Equipment). This goes for farming equipment, fleet vehicles, industry specific vehicles (ambulances, firetrucks, etc) but our main focus for this project was to focus on the average consumer / driver. NAPA stores support this industry by selling car parts from multiple suppliers, to multiple car repair shops and the hobbyist customer coming into a retail store. NAPA does not manufacture parts itself, so it partners with these manufacturers we call suppliers. These suppliers not only sell us the part for resale but have to tell NAPA's back end system all of the information about the part, what cars the part fits (or doesn't fit), and equivalent parts out there (interchange number). This is just a little context needed to understand the challenge.
The technology used to hand over information from supplier to NAPA is legacy and difficult to use for both the suppliers and internal employees trying to read the information and manage it. The clunky back end software also had very little reports or quality control. This industry relies heavily on the correct information being published to the retailer websites. If even a few words or numbers are wrong, the part could be mislabeled on the shelf, not only leading to things like loss of sale but also the breakdown of the customer's car. This problem for the industry has compounded over the years leading to perception around brands for having "good" data online, or "bad" data. Fixing a car is no easy task, and the parts are supplied from all over. The organization sought to reduce the cognitive load on both parties in order to load and manage the data faster, with more efficiency and especially to present correctness.
Phase 1 was to talk to these suppliers and learn everything we could know from their hardships with our internal software, but also to learn more about the industry as a whole. What are the expectations of the customers reading this data? We talked to both suppliers and customers during this interview phase. The methodology we used overall was to talk to suppliers and rank the different qualities they expected in both our software, and competitors.
Our first intake session for research started with gathering assumptions from our internal business and validate them with the suppliers.
Only two of the assumptions made by the company were true. Leading to the team realizing we had a lot to learn about what we didn't know. After this session we let the suppliers lead the way in a workshop format ranking their capabilities of the ideal experience. In the end the top 6 in order are; Efficiency, Help, Feedback, Quality, Control, Notifications.
We followed this up with a read out that showed how our current experience stacked up the the supplier's ideal what opportunities we could take and use to gain competitive advantage. This read out included a ranking system that we could measure ourselves against over the next year to ensure we were listening to the feedback from suppliers while creating this ideal experience. The next step was to start brainstorming HOW to meet these goals.
Phase 2 included two different steps. One was to identify the internal employees who manage the software, and what their experience was like, and the second was to work with them to improve it. By improving the internal employee's experience, you directly effect the supplier experience positively. This is an important part of service design. During the interviews, we found that the internal employees echoed a lot of the same grievances that the suppliers had while using and managing the software. Their jobs were to make sure the data was managed and correct with little to no collaboration with the supplier or the industry itself. They expressed being on a island. So enter the workshop, bringing them all together to interact with their jobs in a different way using a method called Business Origami, to think outside the box.
I turned each person, process and prop (software, hardware) into a physical object we could move and discuss on a large brown paper desktop. I used a toll road metaphor which was on brand for NAPA but also helped illustrate the different "gates" a supplier or internal employee had to pass to finally get this complex, difficult process done correctly. We also included billboards along the way with supplier quotes from our initial research, and roadblocks of pain points they experienced along the way to show both sides.
To pass each gate, you needed the correct set of data, in the correct format, from the right person in order to pass. We turned this process into coins and cash that you could write on the back of, but had to go to the right person to get the correct coin/cash. They noticed pretty soon how difficult it was. This wasn't the point we were trying to make. The employees already know how hard this process is for them and their partners. So after setting this foundation, we pivoted.
I asked the room what would make passing this gate more efficient? Soon the people in the workshop from all different departments were working together to accomplish passing each gate, even rendering some gates obsolete. I facilitated this whole process until we were satisfied with the process, and checked our work for quality control (remember that data has to be correct not just fast to collect).
After the workshop, I consolidated the solutions and risks we learned from each department/person at the table into a presentation for our leadership. It included a new way of working with the legacy system as replacing it was out of budget for the year. It pitched that if collaboration and space was created for the different departments in the company, they could better support the supplier's data on intake.
This would help the team responsible be able to focus on the management and correctness of the data as it's published to retailer sites.
Each department taking on a slice of the project and setting up processes to make sure they were all aligned monthly. It also included a plan to open communication with suppliers on a more frequent basis to improve the relationship so when problems did arise, they were handled more efficiently and without damaging the companies reputation. I provided them with multiple kinds of information architecture based on both the research and the workshops we ran so they could efficiently train their teams.
Finally I was able to create a service blueprint for each department and their ongoing roadmap working towards this new future state journey. We used it to define our roadmap and which department was responsible for what implementation. It also included a detailed ecosystem map showing the different software interacting at every stage. This project is still in the process of implementation today! The blueprint has been blurred as it contains sensitive information about the teams at GPC and their process.
Service Design Case Study
The Challenge
GPC is an old company, doing business for over 100 years. The software is difficult to use and hard to manage. Our customers demand correct data from NAPA. How might we provide up to date and correct data using a legacy software?
The Approach
Conduct user interviews and research studies, field visits, internal and external workshops, and ideation sessions with product and business.
The Outcome
A blueprint for how to run an internal team and use it's legacy software to the best of it's ability to serve the customers, partners, and internal stakeholders.
“I have a PowerPoint that has all the steps....It’s just such a cumbersome complicated system.”
Supplier for NAPA Auto Parts
Research Participant
In the auto part industry, there is what comes with the car (OE - Original Equipment) and something a manufacturer has made to rebrand what came in the car AE( After Market Equipment). This goes for farming equipment, fleet vehicles, industry specific vehicles (ambulances, firetrucks, etc) but our main focus for this project was to focus on the average consumer / driver. NAPA stores support this industry by selling car parts from multiple suppliers, to multiple car repair shops and the hobbyist customer coming into a retail store. NAPA does not manufacture parts itself, so it partners with these manufacturers we call suppliers. These suppliers not only sell us the part for resale but have to tell NAPA's back end system all of the information about the part, what cars the part fits (or doesn't fit), and equivalent parts out there (interchange number). This is just a little context needed to understand the challenge.
The technology used to hand over information from supplier to NAPA is legacy and difficult to use for both the suppliers and internal employees trying to read the information and manage it. The clunky back end software also had very little reports or quality control. This industry relies heavily on the correct information being published to the retailer websites. If even a few words or numbers are wrong, the part could be mislabeled on the shelf, not only leading to things like loss of sale but also the breakdown of the customer's car. This problem for the industry has compounded over the years leading to perception around brands for having "good" data online, or "bad" data. Fixing a car is no easy task, and the parts are supplied from all over. The organization sought to reduce the cognitive load on both parties in order to load and manage the data faster, with more efficiency and especially to present correctness.
Phase 1 was to talk to these suppliers and learn everything we could know from their hardships with our internal software, but also to learn more about the industry as a whole. What are the expectations of the customers reading this data? We talked to both suppliers and customers during this interview phase. The methodology we used overall was to talk to suppliers and rank the different qualities they expected in both our software, and competitors.
Our first intake session for research started with gathering assumptions from our internal business and validate them with the suppliers.
Only two of the assumptions made by the company were true. Leading to the team realizing we had a lot to learn about what we didn't know. After this session we let the suppliers lead the way in a workshop format ranking their capabilities of the ideal experience. In the end the top 6 in order are; Efficiency, Help, Feedback, Quality, Control, Notifications.
We followed this up with a read out that showed how our current experience stacked up the the supplier's ideal what opportunities we could take and use to gain competitive advantage. This read out included a ranking system that we could measure ourselves against over the next year to ensure we were listening to the feedback from suppliers while creating this ideal experience. The next step was to start brainstorming HOW to meet these goals.
Phase 2 included two different steps. One was to identify the internal employees who manage the software, and what their experience was like, and the second was to work with them to improve it. By improving the internal employee's experience, you directly effect the supplier experience positively. This is an important part of service design. During the interviews, we found that the internal employees echoed a lot of the same grievances that the suppliers had while using and managing the software. Their jobs were to make sure the data was managed and correct with little to no collaboration with the supplier or the industry itself. They expressed being on a island. So enter the workshop, bringing them all together to interact with their jobs in a different way using a method called Business Origami, to think outside the box.
I turned each person, process and prop (software, hardware) into a physical object we could move and discuss on a large brown paper desktop. I used a toll road metaphor which was on brand for NAPA but also helped illustrate the different "gates" a supplier or internal employee had to pass to finally get this complex, difficult process done correctly. We also included billboards along the way with supplier quotes from our initial research, and roadblocks of pain points they experienced along the way to show both sides.
To pass each gate, you needed the correct set of data, in the correct format, from the right person in order to pass. We turned this process into coins and cash that you could write on the back of, but had to go to the right person to get the correct coin/cash. They noticed pretty soon how difficult it was. This wasn't the point we were trying to make. The employees already know how hard this process is for them and their partners. So after setting this foundation, we pivoted.
I asked the room what would make passing this gate more efficient? Soon the people in the workshop from all different departments were working together to accomplish passing each gate, even rendering some gates obsolete. I facilitated this whole process until we were satisfied with the process, and checked our work for quality control (remember that data has to be correct not just fast to collect).
After the workshop, I consolidated the solutions and risks we learned from each department/person at the table into a presentation for our leadership. It included a new way of working with the legacy system as replacing it was out of budget for the year. It pitched that if collaboration and space was created for the different departments in the company, they could better support the supplier's data on intake.
This would help the team responsible be able to focus on the management and correctness of the data as it's published to retailer sites.
Each department taking on a slice of the project and setting up processes to make sure they were all aligned monthly. It also included a plan to open communication with suppliers on a more frequent basis to improve the relationship so when problems did arise, they were handled more efficiently and without damaging the companies reputation. I provided them with multiple kinds of information architecture based on both the research and the workshops we ran so they could efficiently train their teams.
Finally I was able to create a service blueprint for each department and their ongoing roadmap working towards this new future state journey. We used it to define our roadmap and which department was responsible for what implementation. It also included a detailed ecosystem map showing the different software interacting at every stage. This project is still in the process of implementation today! The blueprint has been blurred as it contains sensitive information about the teams at GPC and their process.