Purchase Orders Service
HelloFresh | 2017
Procurement is one of the key operational processes in a meal-kit business. One of the products in the ecosystem is a tool to support buyers, analysts and operational folks to manage a big number of purchase orders across suppliers, distribution centeres, as well as to negotiate the best price of the goods. The tool is used across 12 markers, with vastly different operational processes; the goal was to ensure we address the pain points and carve a unified and standardised user experience.

User research | UX design | UI | Wireframes | Prototype | User testing

HelloFresh is a publicly traded meal-kit company, running it's business in the USA, Western Europe, Australia and New Zealand. Supply chain management (SCM) tech tribe, part of which I am, works with Operations team hand in hand, to ensure the technological solutions are in place and the users can do their work smoothly.

In the heart of any meal-kit business is a Procurement department; that essentially is supporting the process of finding, agreeing terms and acquiring goods from an external supplier. It often involves a lot of tendering and bidding, back and forth, and enormous amounts of communication between buyers and suppliers. Our team have been working on providing users across markets with tools for SKU and supplier management, ordering and purchase orders management.

setting the context
The Purchase Orders Service project is part of a bigger Ordering Tool product family. When I came onto the team, the initial product was already rolled out and was used across markets. But the product itself was referred to it as Frankenstein by it's stakeholders and users. The bug reporting board on Jira was overflowing with user's feedback; in fact that is where the idea to look into making the product more user-friendly emerged. The challenge was that it was not really clear what was the problem, there was a very vaguely defined problem statement I started to work off slowly beginning to understand the pain points more, and scoping the project down.
research phase
I took my time to talk to the tech team, because even within the team, people were rolling their eyes when the product was mentioned. A few knowledge sharing sessions later, a trend started to emerge – the team was very far away from the end users, have had zero empathy towards them, and were under the impression that the users are just a whiny bunch.

This issue was the first one to address on my agenda. As a team we went on a trip to a Verden facility, where HelloFresh has a warehouse and where the goods are stored, and packed for the deliveries. It helped the team to understand the bigger Operational flow and to meet some of the users onsite. In general it was a good opportunity for the team to get a peek into the daily bustle, and provided us with a shared experience to base the discussions off moving forward.
Since the product I was working on is rather industry-specific, I wanted to get an overview of other tools and processes out there. Together with the product owner we were able to research some of the tools. We downloaded a few to have a look, but even though we were able to assess the flows and the visual design, we were lacking the understanding of the processes these tools are supporting.

Talking to the stakeholders within the organisation, who are the industry experts, namely heads of Purchasing in different countries, helped us to understand the industry standards of the processes and how software supports it. With this input in hands, we were able to understand the business requirements more, that later informed the first draft of the design brief.
Once I have understood what work was already done by the product manager and the tech team and talked to stakeholders I moved to the actual user research. Going through the Jira tickets submitted by the users from different markets allowed me to spot certain patterns, that informed the discussion guide for further user interviews. The user interviews were meant to be conducted on the individual basis, lasting between 25-40 minutes per session. The 1:1 format allowed me to thoroughly explore each person's subject matter expertise, pain points and frustrations as well as brainstorm together on the ideal-world flow scenarios.
The user base is located in different markets, and given the ambiguity of the problem and project scope, I first met face to face with the German batch of users. Being in one physical space allowed for a more natural flow of conversation, with accidental doodles and flow sketches along the way. Later, with the help of the same users group, we have mapped the Purchase flow, that transcends beyond technical tools, and is allowing to see the process, rather than a digital product user flow. The artefact was a great way to connect with the tech team, we used it to pin-point the discussions going forward, and try to make sure we are not following off the user-focused track. Together with the product owner and the team we revised the discussion guides for the future user interviews in other countries.
Because of various market maturity across the countries, the operations processes are not standardised. Thus thee company's approach is to focus on the top performing markets: the USA, BENELUX and Australia, followed by the rest of the countries. The users from these countries were my next focus.

Product owner and I flew down to the NYC office to meet the users and the stakeholders in person and to build the rapport with them. Talking across ocean on Hangouts is a good option once the communication has been established; in our situation the Ops team and the tech team did not have a good communication record, and it was better to try and restore the trust.

We held numerous workshops with the users and stakeholders while in the NYC office. After the first workshop where we gathered both groups in one room, it became apparent it's better to separate them. While the stakeholders act more as visionaires of a product, the day to day users are able to give a more granular and detailed feedback on the actual flow and interactions. Both points of view are important, and we wanted to hear both sides, without given either one a preference.
The last few days in the NYC office I have spent conducting onsite field research, where I observed the buyers while they were working. The goal of this exercise was to validate some of the insights generated thus far in the research, and to clarify a few complex customer journey map interactions. It was important to understand the reasoning behind what the users are doing, and how it fits into a bigger agenda, rather than just the steps. It also helped a lot with building the rapport and relationship with the USA users; the users got comfortable with me looking over their shoulder and eventually would even talk me through what they are doing and how they feel at a given stage.

I was able to successfully build a rapport with the users, and we have also discussed how the communication will happen across the ocean in the future. I recruited one of the people in the NYC office to be a UX ally. Together we schedule user research and/or testing sessions, where he would be the facilitator of the actual session, and I would be the source of content input: ideas, sketches, prototypes and the questions to go along with it.
Having direct inputs from USA & Germany users, and indirect inputs from other markets – filled out Google Forms, the product owner and I were able to define the way to move forward. We scoped the problem down, and wrote a few iterations of the design statement to inform the later work.

We digested the research into a list of insights and pain points users are experiencing. This exercise allowed us to look into actual user scenarios with solid actions; this spreadsheet acted as an early product roadmap because it was breaking down the features by category that addressed a certain pain point. There were tabs for technical, UX, and business notes as well.
Together with the tech team, who in the meantime did technical research into the codebase, we prioritised the features using the Impact Vs Feasibility metrics. It is important to note that at this point in the process, sketching remained minimal, and all the focus was on idea generation through sticky notes. With a help from an agile coach, the team left the stage of discovery with epics, user stories, and a backlog that we later revisited for more ideas.
design work
To kick-start the ideation, I worked on the HMW statement:
HMW Provide buyers with a flexible system that would allow them to easily configure the groups of order by categories and bulk action these groups.
I started by doing quick and rough sketches to get a grasp of the overall flow of interactions. It is always easier for me to start sketching as fast as possible, rather than ponder more over the spreadsheets. However, the spreadsheets do help to guide me in the exploration phase, they let me stay on track with the user scenarios and action points that have to be in the product.
Once I got comfortable with the results, I run them through a product owner. I did not show it to the users and stakeholders deliberately – the level of design maturity was not high, and I would have to make the sketches much more detailed and annotated to get the point across, which at that point of time would have been too expensive of a task to do.

Once the product owner signed off the flows, I transformed the sketches into digital more or less hi-fi wireframes. Putting the user flows together, and adding annotations to the steps, helped me to refine a few smaller interactions that I have overlooked while working on sketches. I presented the results to the users across countries via Hangouts so I could also answer questions along the way rather than leave the users in ambiguity; because of the distributed team with low design DNA, that was the only way to overcome communication issues and problems. Going more high fidelity allowed me to also get users involved; my aim was to maintain a close communication with the user base and fast feedback loop with both the team, and the users.

Last but not least part of the design work was creating a clickable prototype of the entire flow. I wanted to make sure the users get a more fulfilling and full experience of the product for some last feedback; it is important before the tech team gets into the development phase. I ran a few usability testing sessions myself, and also got a tremendous help from the UX allies in different countries to help me. I created an elaborate user testing guideline with questions and user prompts to help the allies out.
user feedback & design iteration
The remote user testing and feedback gathering with a remote user base is tricky to say the least. I had to make sure I am reaching out to every country, as well as allowing the users to give their feedback in a meaningful way. The UX allies were of a great help; I also enjoyed the process of explaining the intricacies of facilitation and user testing to them, teaching them as we go.

These sessions helped refine the product more. For example, we have introduced an extra touch point in the flow. I observed a pattern in user's feedback about pagination component; the users were asking to make it a perpetual scroll instead. A few sessions later, looking through more and more feedback, I understood the real pain point and the rationale behind it:
Users were afraid to click CTA, they did not know if they would be able to go back one step in case they did a mistake. As a precocious measure, they wanted to double check what exactly have they selected before processing with the bulk action that would affect quite a signifucant number of purchase orders.
To address the pain point I have sketched some ideas, and sent it over together with some discussion prompts before/after the UX ally shows the sketches to the users. Thus I was able to validate a user pain point, and propose a solution right away. A few iterations later, the extra touch point designs were refined, and made it to the bigger flow.
To keep on with the continuous feedback loop, product owner and I created an easy to submit feedback form that is accessible from the product itself. The feedback goes immediately to the dedicated Jira board. I look through the tickets on a weekly basis to observe patterns, and extract ideas that we can work on as a team.
visual design
As I started prepping the designs for the development to take over, I updated the wireframes with new components from the Pattern Library the team and I have been working in the meantime. It is still WIP with the Pattern Library, so while collaborating with the front-end engineers on the implementation, I made sure that the engineers are aware and organise the infrastructure in a way that would allow for easier implementation of certain components later on.
take aways
The biggest pain point while working on this project was the distributed user base and stakeholders. In the beginning of the project the priorities were given to those with the loudest voices. Setting the infrastructure in place that would allow to reach to everyone took some time and iterations, but in the end it allowed the tech team and I to really get into the nitty gritty of the user's pain points and feedback. Throughout the length of the project, I documented the work on the project sporadically, but have I had more neatly organised documentation, stakeholder management and pushing for some ideas would be much easier.

Personal take away was that I really really love holding workshops, it simply makes me feel more fulfilled and happy. Connecting with the team, facilitating the discussion and making sure even the silent voices have an opportunity to part take in the conversation is a bliss.
Made on