Product Discontinue
Goal: The current Product Discontinue process runs on spreadsheets and inconsistent communications. Additionally, the current process is fragmented, so there is no clear idea on who should be responsible for the Product Discontinue process. I need to figure out what the future experience should be and who should be responsible for that future experience.
Hopeful Outcome: as legacy systems get deprecated, and we face an antiquated backend system, we hope to produce a much more efficient discontinue process for the end users who should be triggering, performing, and authorizing discontinues
Tools Used
Current Process to-date
~ Onboarding & Problem Framing
~ Hypothesis Stakeholder Mapping
~ User Research & Discovery
~ (NOW) Sketching & Wireframing
The Gallery
Definitions
Product Discontinue
process to keep products from being sold for whatever business reason or timing. In other words, these products are archived until brought back live to be sold
Item Status
flag saying if an item is available to be sold or not
Reason Codes
every item if discontinued for a period of time must have a reason attached to its discontinued status
Legacy System
systems at least ten years old and no longer have capacity to update to the newer and better software. Additionally, will hold old processes until new replacement processes are in place
User Experience
the expected experiences to cover the root user needs to successfully perform a business function
Current Thoughts
Because multiple people have tried to tackle this problem, I am looking at many pieces of research that seem disconnected. Bringing the engineers into the user sessions greatly help with improving the users’ perspective and also bridging the gap between all of the previous research.