Reducing Onboarding by 7 Days via Dashboard Clarity

About Image
About Image
About Image

Senior UX Designer

Fruugo: global marketplace connecting 7M shoppers to 4000+ retailers in 40 countries.

Problems


In 2024, Fruugo was focused on scaling the platform and attracting high-quality retailers, however the following problems threatened the 'onboarding at pace' initiative;

  • Internal Workflow Debt: Fragmented tools forced teams into repetitive, low-value manual tasks, making it impossible to prioritise high-value retailers.

  • Low Retailer Autonomy: Minimal signposting in retailer-facing tools led to confusion about the retailer onboarding process and increased dependency on manual support.

Problems


In 2024, Fruugo was focused on scaling the platform and attracting high-quality retailers, however the following problems threatened the 'onboarding at pace' initiative;

  • Internal Workflow Debt: Fragmented tools forced teams into repetitive, low-value manual tasks, making it impossible to prioritise high-value retailers.

  • Low Retailer Autonomy: Minimal signposting in retailer-facing tools led to confusion about the retailer onboarding process and increased dependency on manual support.

Cost of Inaction


  • Increased operational costs: Without change the overheads to support the existing onboarding process would outpace revenue generated by onboarding volume.

  • Delayed time to revenue: Every day lost to onboarding, was a day of lost commission to Fruugo and revenue to retailers, capping Fruugo’s growth rate.

  • Reputation risk and churn: A fragmented onboarding process demonstrated low technical maturity to high-value retailers, driving disengagement and increased drop off.

Cost of Inaction


  • Increased operational costs: Without change the overheads to support the existing onboarding process would outpace revenue generated by onboarding volume.

  • Delayed time to revenue: Every day lost to onboarding, was a day of lost commission to Fruugo and revenue to retailers, capping Fruugo’s growth rate.

  • Reputation risk and churn: A fragmented onboarding process demonstrated low technical maturity to high-value retailers, driving disengagement and increased drop off.

Solution


Prioritising internal workflows, I designed a unified global search and dashboard that consolidated siloed data into a single User Interface (UI), reducing unnecessary navigation friction and low-value data fetching tasks.

Solution


Prioritising internal workflows, I designed a unified global search and dashboard that consolidated siloed data into a single User Interface (UI), reducing unnecessary navigation friction and low-value data fetching tasks.

Impact

Impact

7 days reduction in avg. onboarding

From 44 days to 37 days for a single retailer

From 44 days to 37 days for a single retailer

12x decreased search volume per retailer

From 12 to 1

From 12 to 1

71% Increase in user satisfaction

From 'unengaged' to 'significantly satisfied'

From 'unengaged' to 'significantly satisfied'

Research

Back-stage Vs front-stage.

The Product Owner (PO) and I mapped the end-to-end onboarding journey, detailing the jobs to be done (JTBD) for both retailers and internal teams, and it quickly became apparent we could not improve the retailer experience without first fixing the internal operational engine. Lacking historical quantitative data, I led a "backstage-first" research phase, conducting workshops with the internal Tech Ops team in which the following themes kept emerging:

  • Fragmented Architecture : Excessive design debt in the Tech Ops tool (which handled the majority of retailer onboarding) forced a disjointed workflow. Onboarding a single retailer required a minimum of 12 separate searches across inconsistent interfaces, leading to wasted time and navigation fatigue.

  • Low-Value Manual Retrieval: 13 of the 31 onboarding tasks were identified as simple data validation or fetches. Users were forced to navigate multiple pages, then tab-juggle to manually copy data into third-party systems or UIs, creating a high risk for human error.

  • Information Silos & Visibility Gaps: Data was hidden within specific modules, making cross-team collaboration impossible. Sales and Account Management teams lacked visibility into retailer progress, forcing them to rely on manual status updates from Tech Ops. This problem was further confounded by the fact internal teams lacked a clear understanding of the retailer-facing interface, creating a disconnect between the support they provided and the actual user experience in the retailer tool.

Beyond the obvious time loss and performance inefficiencies of repeated queries, the above friction had also accidentally contributed to a culture of mistrust. Users felt that previous features and attempts to improve their workflows had been delivered with little context or collaboration, inadvertently increasing the complexity of the Tech Ops tools rather than reducing it.

This was important context to shape our approach moving forward, and the PO and I were keen to continue in a collaborative method to ensure designs were firmly rooted in the users' day-to-day realities.

31 tasks in total onboard a new retailer

18/31 tasks completed within specific modules of the 'Tech Ops' tool.


31 tasks in total onboard a new retailer

31 tasks in total onboard a new retailer

18/31 tasks centred around data retrieval and transferring.


12 modules housing specific functionality


Each module accessible by module search > search results > module functionality.

12 modules housing specific functionality

12 modules housing specific functionality


Each module accessible by module search > search results > module functionality.

Minimum of 12 searches to complete 18 tasks

Minimum of 12 searches to complete 18 tasks


Each search and results page with inconsistent design.


Each search and results page with inconsistent design.

Our current process is hindered by the [Tech Ops] tool…we spend too much time on things the technology should be doing…or at least helping us with…and less time on actually doing the important, core tasks that humans should be doing

One Search to Replace Twelve.

With a clearer understanding of the operational barriers and commercial consequences of inaction (increased operational costs, delayed revenue, and reputational risk) the Product Owner (PO) and I explored multiple solutions with stakeholders, including AI-driven task automation and a centralised notification hub.

The strongest solution to emerge was a single global search replacing the existing 12 separate module searches, with a holistic results dashboard consolidating the most useful data from all 12 modules into a single, unified UI. While this didn't eliminate all manual data fetching tasks, it significantly reduced the navigation required to find data and laid the foundation for automating those tasks later.

Despite the heavy initial data restructuring, initial buy-in for this solution was high, for a few reasons;

  • Deliverability: Developers felt this solution was achievable within a single quarter, whereas complex features like the notification hub were not feasible under desired timelines.

  • Scalability: It consolidated 12 maintenance points into one, creating a 'source of truth' that could later serve as essential infrastructure for other opportunities, such as a retailer self-serve portal.

    To validate this direction, I developed wireframes and explored the concept further with the Tech Ops team.

Despite the heavy initial data restructuring, initial buy-in for this solution was high, for a few reasons;

  • Deliverability: Developers felt this solution was achievable within a single quarter, whereas complex features like the notification hub were not feasible under desired timelines.

  • Scalability: It consolidated 12 maintenance points into one, creating a 'source of truth' that could later serve as essential infrastructure for other opportunities, such as a retailer self-serve portal.

    To validate this direction, I developed wireframes and explored the concept further with the Tech Ops team.

Despite the heavy initial data restructuring, initial buy-in for this solution was high, for a few reasons;

  • Deliverability: Developers felt this solution was achievable within a single quarter, whereas complex features like the notification hub were not feasible under current timelines.

  • Scalability: It consolidated 12 maintenance points into one, creating a 'source of truth' that could later serve as essential infrastructure for other opportunities such as retailer facing self serve portal.

    To validate this direction, I developed wireframes and explored the concept further with the Tech Ops team.

Define

Define

Define

Measures of Success.


Whilst working on concept ideas and wireframes, we considered what success would look like.


Lacking baseline analytics or quantitative user data, we decided that our primary benchmarks would focus on ensuring the final solution was both functional, trusted, and directly mapped to the three core problems we'd uncovered in research: fragmented navigation, buried data, and a team that had lost confidence in the tools built for them.

Measures of Success.


Whilst working on concept ideas and wireframes, we considered what success would look like.


Lacking baseline analytics or quantitative user data, we decided that our primary benchmarks would focus on ensuring the final solution was both functional, trusted, and directly mapped to the three core problems we'd uncovered in research: fragmented navigation, buried data, and a team that had lost confidence in the tools built for them.

01.

Decrease search volume per retailer

Users should be able to access all required functionality to onboard a retailer in less than 1-2 search queries

02.

Increase critical data find-ability

Users should be able to find all core data points in 10 seconds or less

03.

Increase user satisfaction

At least 70% of users should report improved satisfaction with the tool

Prioritise

Prioritise

Defining Value and Trade-offs.

With high enthusiasm from Tech Ops, we ran a collaborative prioritisation exercise to identify the most critical data points for meaningful search results. From potentially hundreds of data points across 12 modules, users distilled these to 23 essential attributes, ranking them by usefulness and discussing presentation to ensure clarity without overwhelming the interface.


More ambitious features, such as filters and tooltip visualisations, were deliberately deferred in favour of a focused MVP: a fully functional dashboard surfacing this critical data. Catalogue and Compliance cards formed the foundation, with remaining cards delivered sprint by sprint until the complete vision was realised

Design

Design

Card by Card, Sprint by Sprint.

Due to the complexity of the data required for meaningful search results, I quickly established a card-based layout to ensure a clear visual hierarchy as I developed designs. This approach enabled a "card-by-card" design process where I designed, tested, and validated a card in one sprint, before it was developed and released in the next. This approach facilitated continuous user and engineering collaboration, and ensured the consistent delivery of value throughout the quarter, avoiding the risks of a 'big-bang' release at the end.

The first sprint delivered a core global search feature and the basis for the new holistic search results. In this initial release, we were able to include the first fully developed results card - the catalogue card, as well as 11 quick access buttons to the remaining Tech Ops modules.

In the subsequent sprint, we delivered the first major data visualisation for the search results: the 'Catalogue Card'. This card surfaced critical SKU data, including 'live' and 'error' counts in a pie chart format, replacing a tedious process where users had to navigate to the catalogue module, download a report and then manually calculate error percentages. By automating and visualising this data, the second sprint delivered users an immediate understanding of retailers ‘go-live viability' and demonstrated committed progress towards our end vision.

In the subsequent sprint, we delivered the first major data visualisation for the search results: the 'Catalogue Card'. This card surfaced critical SKU data, including 'live' and 'error' counts in a pie chart format, replacing a tedious process where users had to navigate to the catalogue module, download a report and then manually calculate error percentages. By automating and visualising this data, the second sprint delivered users an immediate understanding of retailers ‘go-live viability' and demonstrated committed progress towards our end vision.

Building on this momentum, we co-designed, developed and released the remaining cards, including compliance, shipping etc sprint by sprint, delivering the full search solution by the end of the quarter. The continuous feedback loop ensured that both individual cards and the broader information architecture remained readable and accessible as the UI evolved.

Building on this momentum, we co-designed, developed and released the remaining cards, including compliance, shipping etc sprint by sprint, delivering the full search solution by the end of the quarter. The continuous feedback loop ensured that both individual cards and the broader information architecture remained readable and accessible as the UI evolved.

Measure

'It definitely makes monitoring progress much easier…'

After deploying the global search in Q1, we evaluated the results in Q2 once the new workflow had embedded. Since user analytics were still unavailable, a questionnaire felt like the most proactive, accessible way to capture insight.


Search volume was the most immediate win. The single global search reduced queries per retailer from 12 to 1, saving users a minimum of 48 clicks per onboarding. 79% of users confirmed they saved moderate to significant time each week — time they could now direct toward higher-value onboarding tasks rather than manual data retrieval. 93% agreed it was easier to access core functions than before.

79% reported 'moderate -significant' time saved (per week)

79% reported 'moderate -significant' time saved (per week)

in searching for and retrieving siloed data

in searching for and retrieving siloed data

71% were 'significantly' more satisfied with the Tech Ops tool

71% were 'significantly' more satisfied with the Tech Ops tool

compared to before the introduction of this work

compared to before the introduction of this work

100% reported increased 'holistic view of progress' for a retailer

100% say the dashboard gives them a more holistic view of a Retailer's onboarding progress

100% reported increased 'holistic view of progress' for a retailer

making it easier to understand go live viability and pace of onboarding

making it easier to understand go live viability and pace of onboarding

Data find-ability exceeded our expectations entirely. The dashboard now surfaced all 23 required data points in under 2 seconds — well inside our 10-second target. Every single user confirmed that the holistic view improved task prioritisation and made it easier to spot data gaps that had previously stalled onboarding. The benefits also extended cross-functionally: Account Managers reported a significant reduction in their dependency on Tech Ops for status updates, a ripple effect we hadn't explicitly designed for but were glad to see.


User satisfaction told the most meaningful story. 71% of Tech Ops users reported being significantly more satisfied with the tool — clearing our 70% target and, more importantly, signalling that we'd begun to rebuild the culture of trust that had eroded over years of top-down delivery.

It definitely makes monitoring progress much easier, and saves a lot of time….Overall, it's a lot quicker if I need to check a retailer's live data. I can see what's missing right away on the [search results] dashboard.

Success sustained

Define

Success sustained

Business Impact.


The results above validated the immediate design goals, but the downstream business impact in Q3 and Q4 reinforced the value of what we delivered:

  • Accelerated Time-to-Revenue (Q3): Following our success review, Tech Ops reported a 7-day reduction in average onboarding time. This directly increased Fruugo’s quarterly commission opportunities and had potential to also improve Time to First Sale for retailers.

  • Infrastructure & Development Efficiency (Q4): By lowering performance overheads through improved data architecture, we were able to re-evaluate previous "high-cost" features. Most notably, the highly desired notification hub became significantly more feasible, with development estimates reduced due to the streamlined foundation. The trust established during this project also meant feasibility conversations were met with greater confidence from the business.

Business Impact.


The results above validated the immediate design goals, but the downstream business impact in Q3 and Q4 reinforced the value of what we delivered:

  • Accelerated Time-to-Revenue (Q3): Following our success review, Tech Ops reported a 7-day reduction in average onboarding time. This directly increased Fruugo’s quarterly commission opportunities and had potential to also improve Time to First Sale for retailers.

  • Infrastructure & Development Efficiency (Q4): By lowering performance overheads through improved data architecture, we were able to re-evaluate previous "high-cost" features. Most notably, the highly desired notification hub became significantly more feasible, with development estimates reduced due to the streamlined foundation. The trust established during this project also meant feasibility conversations were met with greater confidence from the business.


Learnings.


Beyond the product outcomes, this project left a lasting mark on how I approach design leadership;


  • Strategic Visualisation for Decision-Making: To facilitate more grounded conversations with stakeholders, I introduced Opportunity Solution Trees (OSTs) to the team at Fruugo, a framework that hadn't been used there before. Mapping proposed features directly to user pain points and business goals allowed us to surface and test underlying assumptions early, rather than discovering misalignment deep into delivery. OSTs have since become a regular part of how the team approaches problem framing.


  • Trust as a Product Deliverable: I also learned that trust can be a deliberate objective, rather than a byproduct of delivery. By involving Tech Ops in difficult trade-off discussions and maintaining transparency regarding technical limitations, we fostered genuine shared ownership and understanding.




Learnings.


Beyond the product outcomes, this project left a lasting mark on how I approach design leadership;


  • Strategic Visualisation for Decision-Making: To facilitate more grounded conversations with stakeholders, I introduced Opportunity Solution Trees (OSTs) to the team at Fruugo, a framework that hadn't been used there before. Mapping proposed features directly to user pain points and business goals allowed us to surface and test underlying assumptions early, rather than discovering misalignment deep into delivery. OSTs have since become a regular part of how the team approaches problem framing.


  • Trust as a Product Deliverable: I also learned that trust can be a deliberate objective, rather than a byproduct of delivery. By involving Tech Ops in difficult trade-off discussions and maintaining transparency regarding technical limitations, we fostered genuine shared ownership and understanding.



Learnings.


Beyond the product outcomes, this project left a lasting mark on how I approach design leadership;


  • Strategic Visualisation for Decision-Making: To facilitate more grounded conversations with stakeholders, I introduced Opportunity Solution Trees (OSTs) to the team at Fruugo, a framework that hadn't been used there before. Mapping proposed features directly to user pain points and business goals allowed us to surface and test underlying assumptions early, rather than discovering misalignment deep into delivery. OSTs have since become a regular part of how the team approaches problem framing.


  • Trust as a Product Deliverable: I also learned that trust can be a deliberate objective, rather than a byproduct of delivery. By involving Tech Ops in difficult trade-off discussions and maintaining transparency regarding technical limitations, we fostered genuine shared ownership and understanding.


Jo Laycy 2026 ©

Jo Laycy 2026 ©

Jo Laycy 2026 ©

Back to top