Supplier Portal


Daymon already have a big data base filled with all sorts of supplier information. Traditionally this information is updated by hand, discussing on the phone or by email with supplier contacts what needs to be changed. There was a need for an easier way to manage, request and validate supplier information.

The goal of this particular project was to design, test and develop a supplier portal, were users can easily manage their data, and managers can easily validate it.


Daymon is a giant in the retail world, that provides a full service on creating and managing products for retailers since1970. I have been working for the IT Team, based in Lisbon, since August 2018 as a Product Designer.

Currently, I am half the design team at Daymon.
The team has over 20 engineers and 10 QA's. I support design across every aspect of our business and am responsible for leading UX and UI across key parts of the application side of the platform.
I've grown tremendously in the last year, some key achievements of which I have listed below:
  • Implemented a design process. We work with Lean UX, and we came up with a process that has helped the team establish more structure to how we communicate between teams, and our work has allowed business to gain visibility across our upcoming sprints. We try to develop small portions of work, only focusing on what is essential (MVP).
  • Improved usability across projects. No usability tests were conducted before dev handoff before. Since we established a design team, we have been actively working towards conducting UX best practices, usability testing on all projects that we could, and managing to show the value of it to the business.
  • On every project, we establishing a design kit. We work with atomic design, making sure we do not produce extra work for the engineers unnecessarily. This has helped to maintain consistency in the look and feel across multiple projects.

The process

Our process at Daymon is based on the Double Diamond Theory and Lean UX process. We aim to incorporate the key phases of Discovery, Definition, Ideation and Implementation in all of our projects.

Understanding the problem

Before Daymon decided to make a stand alone of the software, the feature was discussed to be a part of Blueprint. Blueprint is a project management software that also works with supplier information.
After gathering some requirements, I conducted research interviews with our primary users (account managers from the sourcing team).
‍At first I focused on understanding the user goals and needs.
After our first meeting I understood the problem was yet to much complex, and actually was not fully understand by the users the potential features this software should have. So I proceeded to have a quick meeting after, with some wireframes from the gathered info, so we could visually discuss what was the intent of the software, and how could we improve.

Intentionally hidden sensitive information below.

The first meeting resulted in a quick design using Blueprint's UI that could help bring some direction the business, and how we should proceed next.


Gathering insights

We conducted a second interview section, on which we gathered the following information:

Some Suppliers are not using Blueprint This lead to the conclusion that this should be a stand alone software

Established who our proto personas are We managed to understand the need for 3 different scenarios, for 3 different type of users.

From this information, we were able to work on the Information Architecture of the software.


Early Information Architecture Diagram, we can still see some doubts that were later discussed with the main users and team.

Prioritisation of issues

When I start working on assumptions, I like to organize issues by steps so I can help me and my team focus.

Since I like to use Azure Dev Ops Project Management system, I also tend to help product managers be able to organize the project a little better. I like to organize problems in epics, PBI's and tasks for our team, but the same tickets can continue to help engineers and even QA's along the road.

This not only helped to prioritise usability issues in order of need but also helped to shape the product roadmap for the quarter.

Business, Design and Engineering teams came to the conclusion that the first Epic we would prioritise would be the edition and viewing of information, so the POC could be produced and tested by the users.

Wireframing the solution

Based on the inputs we were given, I tried to come up with a fully interactive wireframe to be able to test some initial assumptions.

We created various flows, based on discussed IA, and based on the different proto personas we identified.

Some examples below.

Login screen, already contemplating the idea of being able to login with OKTA, and making sure we followed GDPR protocols.

The Supplier screen selection - This was a first sketch of how the selection of a supplier would be done by a Manager.

The Supplier Details page - already contemplating the idea of also showing information of SKUs.

The user details page could also include an Activity screen so we can monitor who made which change.

Also designed the backoffice, where fields and users can be managed by Admins.

Validating the designs

After showing the wireframes to users, we were able to receive feedback from them, as well as observe as they tested the prototype itself. (Low Fidelity).

We gather some information:

  • Users wouldn't like to see such an immense overflow of information in one one page This made us think in tabs, and worked with them to better categorize the information.
  • Discovered that Supplier Managers actually have all the users associated with them. We assumed that not many users would be associated with an account manager. This meant we needed to redesign the supplier selection page to be much more friendly to having a lot of information showing quickly.

Developing the designs

From the information I gathered, we could advance to Medium - High Fidelity Mock ups - This way I can still easily fix any problem with the flows, but also can show the first ideas of an UI. I find that people, when being interviewed, often show concerns with the way Lo Fi Wireframes look, so I like using this strategy.

This time though, we also had a meeting with engineering team first. Validating the design ideas with them first is really important to manage everyone's expectation, as something can turn out to be too expensive to build, and we might need to go around that.

The design was validated, and I conducted usability testing sessions with our primary users to validate whether the new designs would solve their problems.

During the session, I observed how they interacted with the prototype and edited users information, and sent it to verification. They also understood that there were missing fields that they would like having, and some that should be grouped in a different way. Some of the designs below.

Design Assets and Documentation/ Follow ups

After we are aligned with the business to start working on the development of the feature, we get a new alignment with the engineers. We provide Specs of the designs, explanations of flows, and a full prototype.

As we work on the designs, we have the need to explain to a lot of different people the flow that we are taking for different features.

As such, we develop along side the designs, UX documentation that normally is stored with the rest of product assets on Azure Dev ops.

We call it a wiki, and its totally built by the design team, and we fill it with screenshots, explanations of flows, gifs to clearly explain some features, etc.

The design team stays connected with developers since problems tend to arrive during sprints, and we work alongside each other to solve, manage expectations, and get to solutions quickly.

An example of the wiki below.


Results and takeaways

Since the implementation of Supplier Portal, both Sourcing Team and Suppliers seem to be happier than using the old phone/e-mail system. We were able to implement bulk editing solutions as well, as well as bulk inviting new users. Additionally, I have received positive feedback from users about the simple UI.


  • Daymon

  • 2021

The goal of this particular project was to design, test and develop a supplier portal, were users can easily manage their data, and managers can easily validate it.