Maintenance Platform
A global maintenance platform was digitising work orders across breweries, but teams still relied on conversations, spreadsheets and parallel systems to keep work moving. The challenge was not simply to redesign screens. It was to understand where the service broke between noticing a problem, preparing the work and executing it in the field
Location: Brazil and South Africa
01 | CHALLENGE
The Challenge
The Challenge was bigger than a software interface
Maintenance does not happen in a clean, linear flow. A technician may discover missing materials, lose connectivity, receive a new priority or need help from another team—while production keeps running.
The product captured what had happened, but often did not help people decide what to do next. That gap created hidden work, weak visibility and unreliable data.
How might we turn a system of record into a service that supports decisions, handovers and recovery while the work is happening?
As Lead Service Designer, I framed the research, connected field evidence to the end-to-end service, facilitated cross-functional alignment and translated the findings into product opportunities.
Tools used:
Field Research (Etnographic and Attitudinal Qualitative Research), Insights Mapping, Service Blueprint, Event Storming, Capabilities Mapping
02 | METHOD
Research
Etnographic and Attitudinal Qualitative Research
I conducted contextual research in Alrode, South Africa, and Maranhão, Brazil, with operators, technicians and planners. We observed tasks in context, walked through real maintenance scenarios and compared what the process expected with what people actually did.
The environments were different. The workarounds were remarkably similar: critical information lived outside the platform, handovers depended on personal follow-up, and teams lost confidence when the system could not explain or recover from failure.
When the same friction appears in multiple contexts, it is no longer a local workaround. It is a service problem.
What the research revelead
Outside of
the system
Issues were first noticed and negotiated through conversations, then entered into software later.
Hidden
Double-Work
Missing context moved effort downstream, forcing people to chase details or repeat decisions.
Error as
Blockers
Weak feedback, sync uncertainty and limited recovery paths pushed users back to other tools.
Passive Platform with
no Guidance
People needed support to prioritise, prepare and act—not another place to document completed tasks.
03 | OUTCOME
Results
Service Model
Making the whole service visible
We organised the evidence into one maintenance funnel:
-
Awareness — detect, assess and communicate the need.
-
Prioritisation — decide what matters, prepare the work and secure materials.
-
Execution — dispatch, perform, update and close the work.
This reframing exposed the product experience as a chain of decisions and dependencies, not a collection of isolated screens.
Building a Platform with Engineers, Designers and Product Managers
-
Observe — contextual inquiry and task walkthroughs
-
Model — cross-role funnel, journeys and breakdowns
-
Align — EventStorming across people, systems and business rules
-
Prioritise — turn recurring friction into testable product directions
The EventStorming workshop mapped **460+ artefacts**, including **150+ domain events, 130+ commands, 50+ policies, 50+ integrations and 50+ read models**. The value was not the count itself. The model made assumptions visible and showed where ownership, information and system behaviour diverged.
Event Storming
Impact
From Evidence to Product 5-Year Plan
The workshop transformed fragmented knowledge into a shared view. It exposed where decisions relied on tacit expertise, where handovers lost context, where SAP integrations shaped the experience, and where important business rules had never been made explicit.
Furthermore, designing for industrial maintenance means respecting a world where software is never the whole service. The experience spans people, production pressure, materials, safety, connectivity and enterprise systems.
The strongest Service Design move was connecting what happened in the brewery, what the platform recorded and what each person needed to decide next.
Build systems that work where the work happens.
Shared
Product Vision
Aligned product, design, engineering and business teams around the same operational reality, priorities and desired outcomes.
Evidence-based
Priorization
Assessed process, data, product and user percpetion to distinguish immediate opportunities from long-term capabilities.
5-Year Plan
Transformation
Translated research and Event Storming findings into phased horizons, connecting short-term improvements with the platform’s long-term evolution.
Clear Business
Value Proposition
Helped the business evaluate where product value is and where investment could reduce operational friction and improve maintenance reliability.