Why Are We Engaged with a Supply Chain Project?
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.
What is a Supply Chain Project?
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.
Customer Needs and Tiers Expansion
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.
.jpg)
The big challenge
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.
Picking up from previous designer
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.
Understanding the project
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.
Atomic design approach, prototyping and presentation
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.
%201-min.png)
Company re-scoping
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.
Re-discovery phase
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.
%201-min.jpg)
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.
Listening to users
First, we wanted to do a talk to our members again, to understand their problems after the refreshed experiences we already released.
Technical discussions
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.
The two major journeys:
- Supply chain mapping
- Requesting members to join the supply chain
- Members processing the requests
- Accepting
- Rejecting
- Putting request on hold
- Supply chain management
- Visualising the supply chain in a consumable way
- Managing a supply chain that is being updated live by each member
- Each member owning their own data that is being shared in the supply chain
Technical dependancies & Team changes
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.
.jpg)
Conceptualising
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.
%201%20(1).jpg)
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.
.jpg)
Prototyping and Live testing
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.
.png)
Experimentation findings:
- Half of the people preferred the linear version because it would look really clean.
- However, it might not represent the full supply chain accurately.
- The other half preferred the tree view version because it would more accurately represent the supply chain.
- They thought that this would get very hard to consume once it takes a real scale of large supply chains.
With these results, I went back to pen and paper and sketched some possible solutions that might combine the two concepts into one.
%20(1)%20(1).jpg)
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.
Technical consultation and Design system updates
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.
.png)
Sytem architecture, Testing and Iterating
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:
- Drafts tested by real-time users
- Unmoderated tests
- Checking our checklists for accessibility
- Consulting with design system keepers and front end developers about the speed in which we could introduce any possible new components, as speed would be key at that point.
Gaining confidence in our concept
After testing some of the journeys we were more confident that this was now the way forward.
- Drafts tested by real-time users
- Unmoderated tests
- Checking our checklists for accessibility
- Consulting with design system keepers and front end developers about the speed in which we could introduce any possible new components, as speed would be key at that point.
- Users should have a quick overview of their entire supplier network, and the tree list helps them understand the tier depth of their suppliers.
- Zooming in to a specific path way, helps users understand a small section of a supply chain better, and it's easier to understand the data that they are looking at.
- The zoomed in version follows the concept of a pathway, visually represented as a tube map. The exploration for this can be seen at my Link summary case study.
.png)
Handover - Proof of Concept
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.
.png)
Our delivery process looks like the following:
- First we would have a “three amigos” meeting with the Product manager, myself and the Tech Lead to consult ideas by usability, business output and feasibility.
- Sometimes we also involve the Agile Delivery Manager here to get a better understanding of timelines as well.
- Then we get the entire team in a meeting to chat over the concept with user stories, and low fidelity ideas.
- Post usability testing, I when turning to high-fidelity, I will consult with the relevant developers and Product Manager about implementation and effort each concept would take to fit with our timelines.
- If there are any new components for the design system, I will consult the Design System designers and we would also do a “High-fidelity” check to make sure that the experience is consistent throughout the platform.
- Once the design is at a final stage, we get the UX Content writer to get the final copy in the designs.
- Once we are all at a happy place, I will mark the designs as ready to develop on Figma and add notes if needed.
- Together with the Product Manager, the Tech Lead, Agile Delivery Manager and Front End Developer, we will write the tickets on Jira before the next sprint planning.
- During the sprint of the tickets being picked up, I will stay in close communication with the developer working on that ticket for any support needed.
- Once the feature is developed in the test environment, we have a “Review” stage in our sprints where we review the feature before it’s pushed on the live platform.
Next phase
After designing the management and visualisation part of the experience we still had the big questions that needed answering:
- How do we build the tier depth from the current state?
- How do we collect the tier depth data from both members and non-members?
With this project, we are sure that we will have the “winner-winner” scenario where:
- Customers get the tier depth as they have long requested
- We help our customers reveal their entire supply chain that is only partly known.
- This will uncover potential suppliers that are not Sedex member so we have the opportunity to increase our total number of members. (Meaning more revenue)
Unexpected challenge
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:
- A customer can have many suppliers or none.
- A supplier can get supplies from other suppliers and sell them to many customers.
Example: Blakely buys from many organisations and sells to many customers.
The concept: Cascading requests
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.
%20(1).png)
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.
.jpg)
User journey - Happy path
.jpg)
Low 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.
High 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.
.png)
Business restructuring
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.
Corse correction
Whilst we were mapping out the supply chain mapping project, we came across some unhappy paths.
- What happens if the companies that the user wants to invite in their supply chain are not already linked to them?
- What if companies that the user wants to invite to their supply chain are not even in Sedex?
- If they start searching for one company at a time it will add up a lot of admin effort.
.jpg)
💡
"If we design a bulk search feature, it will help users quickly identify who is a member of Sedex or not"
“Bulk search” tool - Low fidelity
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:
- Can users consume a lot of search results at once?
- Can users process a lot of search results and get some useful actions out of it at the same time?
- Do we need to put a cap on the search terms to reduce the results and make them easier to consume?
- Should we use pagination for every X amount of search results?
- Should we use pagination to break the results into more pages?
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.
.png)
Double validation - Users and Developers
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.
.png)
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 looking at the average searches done by a company every month, we decided that 100 search terms maximum is a good and safe cap.
- With 100 terms searched each time, we are confident that the system gives back results fast enough that the pagination is not needed for performance.
- We can’t paginate because our current page layout would need restructuring so it would delay development.
- Our current page layout allows for a skeleton load so it feels nicer as an experience as a best practice.
- The front end would send a query for 15 search terms at a time for a “lazy load” so that the whole page wouldn’t get laggy.
- We can collect each search term with results on each table to define the difference.
- We should hide all the matches for each search term and keep the “Best match” always visible to allow a “quick scan” by the user.
- We would style the terms that had “No matches” differently so they would stand out.
High fidelity and release!
After implementing the above and getting some final high-fidelity cross-referencing with our storybook library, we successfully released the feature!
.png)
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.
- If a company is found in our system, the users can send bulk requests to link with the other company.
- If the company that was searched, wasn’t found in our system, the user is later is prompt with a second screen that allows the user to invite multiple companies to both join Sedex and link to them, just by giving us an email for the invitation to be sent to.
Benefits of the feature
- Users are now able to search for more than one companies at a time in our Database.
- Users are now able to uncover gaps in their supplier network a lot more efficiently.
- Users are now able to send multiple link requests simultaneously.
- Users are now able to send multiple invitation to other companies to join Sedex.
- Sedex is now able to gain more supplier membership faster.
- More suppliers can be identified without a membership, so Sedex has a bigger opportunity in the market for more suppliers to join.
%20(1).png)
