The company had a product that was in need of a complete revamp. It was utilizing dated technology from the early 90’s, and the process involved a ridiculous amount of manual processes and use of hard copy materials for this day in age. Common sense dictated that a lot of the work could be automated and the artifacts digitized, however the product team did not know where to start. That is where we came in.
The Question: What do we do and how do we do it?
We began by having a meeting with the product stakeholder. We established what they believed to be the problem, what their expectations were out of hold a workshop, what their goals consisted of, reviewed potential obstacles, and matched that up with what we could provide them. We began by holding a workshop and developing service blueprints for a number of their current processes. After establishing what their current process was, we moved to developing service blueprints for what their ideal process would look like.
At this point we had to pivot, as their ideal process involved passing on some of the steps in their process off to the end-user. As our service blueprints could only account for a single user, we had to adapt and create process maps instead that could account for multiple users. This also allowed us to stream-line the exercise and remove confusion as identifying back-end processes was proving to be a bit of a hang-up for our group. These processes were later mapped out in Visio, mimicking how they were in sticky-note form.
After establishing their ideal processes, we were able to identify a list of very high-level features that would be required for the product replacement. With this, the group was able to determine whether an in-house replacement needed to be developed, or if a third-party product would suffice. In the end, they determined a third-party product would not be able to meet the unique needs of their situation and wanted to move forward with developing a replacement in-house. They wanted to proceed with a workshop to establish a more definitive set of features, determine MVP (Minimal Viable Product), and prioritize the features.
While that was certainly a great step to take, we pulled the reigns back just a bit. The processes had been defined without end-users in the room to verify that they actually wanted to be involved in those processes. Other features were also cooked up on the assumption users would want additional control over the process. In order to verify these assumptions, I set out to conduct contextual interviews with the end-users. We also established the requirement that end-users would have to be present in the workshop that the team wanted to hold. This would ensure that we could avoid making further assumptions moving forward about the end-user. It also left us with evidence/research and live to accompany the live feedback that could now be present in the workshop.
The administrative side of the product only involved two users. They had been paramount in the initial
process mapping. Despite that, given we only had two users handling an important product that affected thousands of users, I wanted more insight into their operations. Therefore I arranged with them to allow me observe them “in the field” (behind their desk) to obtain a better understanding as well as empathy for the administrative users in their current processes.
For the moment this project has not moved into wireframes or development at the process. I will update with additional details when we do move to those milestones.