At Sedex, a leading SaaS platform for enterprises like Walmart, Tesco, and Nestlé, I lead the end-to-end design of user experiences that enable clients to manage their supply chains and gather ESG data. Close collaboration with engineers ensures technical feasibility and accurate data representation, while working with the Product Manager aligns our efforts with business strategy. We also engage enterprise partners to ensure our solutions address their key challenges.
Research with current users shows big problems in finding and fixing supply chain risks. Sedex helps large retail companies avoid bad publicity by using our tools to check suppliers. This helps companies find and fix problems.
Our project aims to make organising and sharing risk data easier from Sedex's tools. Our database needs to clearly show how goods move from the source to the consumer. Big companies need help managing risks in their supply chains. By improving the data structure, we want to give a clearer view of supply chain risks, helping companies understand and reduce these risks.
Customers have expressed a need for deeper visibility into their multi-tier supply chains. They have requested that Sedex expand its tier capabilities to enhance their understanding and management of supply chain risks.
As seen on the example above, big enterprises have to deal with overwhelming numbers of suppliers in their network. If a user decides to look into the tiers of their supply chains, we can see how quickly the network explodes into more companies with each tier we look through.
This makes a challenging case for complex interface, needing to show all the data needed, while keeping a tamed version. If we show the users the unfiltered, untamed version, our platform will be of no use, because it will make it impossible to precess the data that one might be looking for.
During my first ever touchpoint with the new project, the whole company was on an ongoing, already two-year-long, re-platforming project. During that time, our current key members repeatedly requested a solution to help them understand their risks in their supply chains.
Due to this ongoing demand, I picked up the solution from the previous designer, to visually transform our current links management concept into a concept that would support more tiers.
To help myself understand where we are, I mapped out our current end-to-end journeys to increase my platform knowledge and plan a strategy concerning where we currently stand.
Then I emphasised in our team’s journeys to note all the details around our users’ journeys that might represent anything close to a supply chain on the current platform.
Even though it was only my second month in the company, there was pressure by the stakeholders show our solution to the business. I went on Figma, and according to what we discussed as a team and I prototyped a happy journey to show the entire company with a refreshed UI and a re-invented atomic component structure.
Generally, the concept made very positive impressions across the company and there seemed to be some investment ahead to kick off the final stage of this concept and start building it.
After this, there were some broad company changes urging all the product teams to shift their focus back to re-platforming and put all the new features on pause until later notice.
The main reason was that mid-year the KPI changed, and we needed to drive 60% of all journeys on the New platform by the end of 2022, to speed up the decommissioning of the old platform.
This led to the successful completion of the Links project.
After we hit our targets for 2022 and the on-going problems of our existing enterprise members, we picked up the supply chain feature again.
As we were picking up this work again, we first wanted to do a quick round of research with current members to cross-reference and update our insights from the exploratory work that had been done before.
Coming back, we went intro a room together with the Product Manager and the Tech Lead, back on the drawing board while referencing knowledge that we had from the first round of the supply chain exploration work.
It quickly became clear that whole project can be identified by two major journeys that all together make up the full supply chain experience that we needed on the platform.
First, we wanted to do a talk to our members again, to understand their problems after the refreshed experiences we already released.
We then went intro a room together with the Product Manager and the Tech Lead, discussing our how would the system work to respond to our users' needs.
It quickly became clear that whole project can be identified by two major journeys that all together make up the full supply chain experience that we needed on the platform.
Due the dependancies on the old platform and team changes, I decided to lead a user stories workshop with the team. This helped us understand which journey each user type follows, what functionality each feature would be transferred from and it also helped communicate a complex project to the new team members.
Post brainstorming, we understood that the current data structure and our dependancies on the still existing "Old platform", might be difficult to achieve.
Once we had some ideas for small “quick wins” Sedex was heading to the first Sedex conference post-COVID-19, and we all agreed it would be a good opportunity to talk to members face to face, and do some live testing.
Post brainstorming, we understood that the current data structure and our dependancies on the still existing Old platform, might be difficult to achieve.
This led us back to the brainstorming board to note how we can start switching small pieces of functionality to fit the new feature and evolve step by step.
Once we had some ideas for small “quick wins” Sedex was heading to the first Sedex conference post-COVID-19, and the Head of Product at the time wanted us to take this opportunity to conduct experiments with members face to face.
We got together as a team and wrote down what we want to achieve out of the live experimentation.
With the above notes, we all decided to take our concepts and put them in front of the members that will be attending the conference. For my team, I tested three different distinct concepts as clickable prototypes.
With these results, I went back to pen and paper and sketched some possible solutions that might combine the two concepts into one.
The idea of making the supply chain look like a “Tube map” (London Underground rail) with stops, was a prominent insight. This led to the Link Summary project and contributed towards the 2023 KPI.
We then got all the developers together on regular sessions to come with a strategy to building new services and restructure out data to support bigger supplier networks.
I also worked together with the storybook and design system teams to introduce the new components that would support our tree-list and tube map concepts.
It became clear to me that we have the opportunity to combine something that uses a tree list for an overall supplier network overview but can be connected to a “focused” supply pathway and help a member of the supply chain look at the risk date of sites in that pathway.
The chart showcases some examples that explain what we aim to achieve when we go from an entire Supply chain network, down to a specific supply chain pathway.
This chart was followed by:
After testing some of the journeys we were more confident that this was now the way forward.
In order to deliver this fully built we need to restructure our entire data structure and build the appropriate APIs that would call the right services to bring all the data to the Front End.
So as a first round, we wanted to test the performance of such a project with our current Data structure. In order to do that we needed to build a Proof Of Concept and test out the current loading speed before we expand our data structure to support an X amount of nested companies under each tier.
The idea of making the supply chain look like a “Tube map” (London Underground rail) with the stops, played as a serious insight. This was implemented in the completion of the Link Summary project that would be our team’s major contribution towards the company KPI to keep 80% of all journeys in the new platform.
Our delivery process looks like the following:
After designing the management and visualisation part of the experience we still had the big questions that needed answering:
With this project, we are sure that we will have the “winner-winner” scenario where:
After looking at our data again, it seemed that many companies had very unique ways to mapping their supply chains. For example, M&S buys T-shirts from Ace T-Shirts and sells groceries to Ocado. Relationships in supply chains include:
Example: Blakely buys from many organisations and sells to many customers.
After consulting with the Product Manager and Tech Lead, and much consideration to the user needs, reducing the amount of friction, our cascading concept would be the most feasible and usable at the same time. This would also rebuild our current data structure and the enterprise users would passively contribute towards cleaner data.
So step-by-step the supply chain would be built collaboratively by each supply chain member splitting the task and reducing the amount of admin effort while safely rebuilding a good quality data structure.
I then started sketching some wireframes and I started transforming into mid-fidelity where I took them through the first round of testing to gain some insights before moving to the higher fidelity.
I then started sketching some wireframes and I started transforming into mid-fidelity where I took them through the first round of testing to gain some insights before moving to the higher fidelity.
I then started sketching some wireframes and I started transforming into mid-fidelity where I took them through the first round of testing to gain some insights before moving to the higher fidelity.
After a newly introduced rebranding from the marketing team, as a design team, we all went into workshops and together we defined the typography and colour schemes that work for us, and each of our products through experimentation, making sure that we are still communicating the brand in our products.
This took us forward to reworking our design system components and with this opportunity, I also introduced the right components that fit the new feature. As a result, we ended up with the last round of testing to understand a user’s tolerance when completing a supply chain mapping journey.
At this point, the business was going through a crisis, of still having to spend a huge amount of money to maintain the old platform while we were also working on the new projects. This quickly became non-viable which led to the decision to freeze the supply chain project and project that is about new features, until further notice and shift the full resource to focus on transferring all functionalities over to the new platform to shut down the old platform as soon as possible.
This also led to a lot of team changes and some last “quick deliveries” for those of us who had something that could be built in a single sprint (two weeks) and still add business and user value.
Whilst we were mapping out the supply chain mapping project, we came across some unhappy paths.
💡
"If we design a bulk search feature, it will help users quickly identify who is a member of Sedex or not"
First, we discussed and agreed with the team, that with a bit of adjustment, we could isolate our bulk search functionality that we were going to build anyway as part of the supply chain mapping experience and deliver it within a single sprint as a stand-alone feature.
We presented this idea in front of the executives and we were able to get a buy-in.
The main challenges that we wanted to solve before going to were:
So I went back to the bulk search tool and wireframed some mid-fidelity while still chatting together with the team and collecting peer feedback.
Before the building phase which strictly needed to be only a sprint long (two weeks), I needed to validate the idea so I decided to run some user testing to make sure that we were confident with what we had and that there wouldn’t be any other iterations along the way.
After prototyping some ideas and making sure that they test well in front of users, we also built another Proof Of Concept to test out our loading times and what makes sense to do.
After prototyping some ideas and making sure that they test well in front of users, we also built another Proof Of Concept to test out our loading times and what makes sense to do. With testing and a POC to play with, we were able to get the following answers:
After implementing the above and getting some final high-fidelity cross-referencing with our storybook library, we successfully released the feature!
The feature is a tool that helps users search for multiple companies throughout our system. They feature returns them relevant matches for each company term they searched for with some elastic search to cater for misspelling.
What disciplines did I collaborate with? Notable mentions:
Adding to the previously introduced members, we also have those working in multiple teams who've made noteworthy contributions to Synergy.
Our team has experienced changes in personnel over the course of the project. Some members have left, while others have joined during this time.
©Evangelos Angelis ️