WFP PSB
Role
UX/UI Designer
Team
Product Owner
SAP Architect
Front-End developer
Back-End developer
SAP Architect
Front-End developer
Back-End developer
In June 2021, I had the chance to work on my first project for The World Food Program. I always wanted to be a designer to have an impact on the world, and this was my chance! I joined a multi-disciplinary team from WFP HQ in Rome to design a tracking platform that would help reduce the lack of visibility and tracking of assets disposed of via the 97 WFP offices worldwide.
Goal & challenges
- Organized co-design workshops with the HQ team to define the workflow and the features needed in the tool.
- Definition of personas and jobs to be done.
- User interviews & user tests to understand the expectations and pain points from the five different personas of end-users using the platform.
- Wireframing and prototyping of the solutionUser tests and iteration.
- Get familiar with the SAP Fiori design Library at the speed of light.
- Application of the UI and daily stand-up with the PO and development team to coordinate the impact-effort decision for implementation.
In this project, I took the UX/UI Designer role and led the design part of the project. It was my responsibility to bring to life the vision of the five stakeholders that requested the platform but, most importantly, ensure that hundreds of WFP office workers worldwide could use it as intuitively and effectively as possible. Moreover, I was in charge of coordinating with the SAP Architect to make sure the design and functionalities we imagined could be implemented. Finally, I also had the chance to run some usability tests and interviews during the process.
When we joined the project, the WFP team already had a workflow established by a service designer that would help us understand the tracking and approval steps (as well as who was involved). Nevertheless, we were still looking at a blank page regarding the users' exact needs and features to implement. In 12 weeks, we went from a Workflow in Miro to a Pixel-perfect MVP prototype.
When we joined the project, the stakeholders had already imagined the solution for a few months, and it was not easy to convince them that we should start the process with discovery interviews. However, they got completely engaged when they saw what they imagined was coming to life. They provided more than 30 users to run interviews and usability tests across their geographical locations. This project became collaborative as they would join us in these sessions and participate actively during design iteration presentations weekly.
During the kick-off, we jumped into a complex existing workflow that took us some time to get through and adequately understand. Also, the team made it clear that they did not want us to show any designs to potential users for interview and testing until they would represent what they had in mind. However, it did not discourage us, and we decided to tackle the project from a specific angle. We proposed to run three co-design sessions during the first week to make sure we (1) visualize the vision and (2) could reach users as soon as possible. Engaging them in the design process and visualizing their ideas relaxed the team and gave them confidence for the next steps.
Despite the co-designed sessions, our UX instincts pushed us to go with a mix of generative and evaluative research during our meetings with users. Moreover, we needed to juggle several expectations and levels of complexity as the tool was supposed to be used by different teams across different geographic locations. Therefore, we would start with a quick interview to ensure we got the process straight and tackle the current pain points. Afterward, we would ask them to go through the process following small scenarios we imagined. The prototype was then tested and iterated weekly over the remaining duration of the project. As is always the case, the initial tests revealed multiple problems, from the original ones that hadn’t been solved to new ones that arose from the new design, and paved the way for weekly conversations with the stakeholders from the client’s side.
As the weeks passed, these problems were tackled one by one until, in the final weeks, test participants could perfectly understand the product’s value and use it without any instructions.
This whole project needed to be built in SAP Fiori; therefore, I used the design system available and applied it accordingly. Working directly in this DS was a great experience. It taught me a lot about creating an entirely new product while ensuring it is compliant with the Design System and, therefore, can be built effectively by the development team.
When you work on an internal platform that many different stakeholders will use, you need to juggle expectations and remind yourself and each stakeholder that their needs might not be the needs of the user next to them. On this project, we had a thought start convincing the team about the design process that we would follow, and I understand they might have thought: ok, these are fancy techniques, but hey, we are dealing with this tracking and approval process for 20 years, we know what we need! Nevertheless, once we got them on board and started designing the first screen and running the first test, we began to hear: "it was so great to see them understanding this part " or " this is not working; let's re-think it and test again"!
When things started moving, the HQ team realized quickly that this tool could eventually solve many problems, and ideas began to flow during the weekly meetings. While some feature views were great, and it is always easier to say yes than no, it was essential to remind the team that we were building an MVP and needed to create a perfect one. Users will use an MVP that will work properly, and most importantly, that developers will be able to ship in a not-so-long time. Here we had a super collaboration with the PO and the SAP Architect to keep things on track and convince HQ that we needed to move step by step... It is not a no, it is a yes but later :)
As this project started, my discovery of SAP Fiori began with it. It did not take me long to go from fear to excitement as they built a great library of templates and patterns. It forced me to adapt my design process: I would start sketching concepts and then go to the sample library to find which elements would fit my original idea, how I could integrate it, and make sure it would work with the rest of the logic.
Also, working directly with an SAP Fiori Architect was a massive help as we could evaluate and ensure that everything we designed would be technically feasible early on.