Our goal was to define the features that would be part of a screen which is used by the Order Classification team. However, in meetings prior to the dynamic, we realized that we could not get to any conclusion without first understanding the entire flow.
To understand how things work, we talked to several people, including coordinators who managed the process, which was quite complex and completely manual, but necessary so that the Classification team had inputs to work with.
We also talked to the analysts who actually do the operational part and use the screen on a daily basis. In addition to the conversations, we held some observation sessions, where I as a Designer, a PO, a QA and some developers followed the daily basis of these people, making use of the screen as a whole.
At the same time that we were doing this monitoring, we also built some flows in Miro regarding the Analysis Board process, resulting in two situations: As Is (as it is today) and To Be (as it will be).
When we arrived, we already knew that the stakeholders had a different perception of their product. We had to align expectations and put everyone on the same page. For this, we dedicated the first few days of Lean Inception to doing some exercises, resulting in the following schedule:
Once we understood the entire flow that precedes the use of the Work Screen, we actually start the Co-creation stage, in which we design the entire User Story Mapping map.
We divided the map into Personas (dark green post-it), Activities (blue post-it) — or missions, they are the things that need to be done by the person — and Tasks (orange post-it) — the actions that need to be done to completion of an Activity).
After some design principles methods we delivered 3 design artifacts which were important to set the pace of product development
We mapped the user journey, outlining the entire flow of activities and tasks for the users who will be using our product.
We identified the most critical features after assessing technical feasibility and the Effort vs. Value delivery.
The primary pain point for users was an inconsistent information architecture that didn't align with reality.
Back to remote work, I started using the inputs collected in the dynamics to make a wireframe of what the new screen should be, but still taking advantage of the current screen’s identity, to avoid greater cognitive effort from the users.
After building the wireframe, I pitched the proposal to each person on the analyst’s team individually. I gathered productive feedback and only needed a few naming and content tweaks.
Since the first drafts, we worked with two versions to close an analysis. One of them was suggested due to a benchmark by the customer, the other was our solution that would be faster, cheaper and that would add more value to generate a pleasant user experience.
Because of internal and bureaucratic reasons, I’m not able to tell you if we got to achieve our business goals or not. However, with those insights in mind we were to target specific convertion metrics listed below:
Or send an e-mail to sayhi@uaimequi.des.br
Copyright © 203 Gabriel Macedo | All rights reserved.
