Designing a configurable platform to control the complete waste journey.
Bezeroo is a configurable platform for organisations responsible for managing regulated waste. It connects declarations, documentation, billing, operations, logistics and compliance within one shared system.
Each SCRAP or regulated organisation can adapt the platform to its own actors, rules and operational workflows. The same product model extends into a transport app that connects route planning, waste collection, DIs, evidence and delivery with the central platform.
I led product design across this ecosystem, helping transform complex regulatory and operational requirements into one coherent model of roles, states, workflows and connected product experiences.
The product challenge
Different organisations needed different workflows, but the product needed one coherent foundation.
Bezeroo serves organisations responsible for controlling regulated waste, working with multiple professional profiles. Among the primary actors are waste managers, transporters and treatment plants, alongside SCRAP teams and public administrations.
Each organisation may work with different actors, declaration periods, validation processes, documentation requirements, billing rules and transport workflows.
Building each implementation independently would have created a fragmented product that became harder to maintain with every new organisation.
The challenge was to create enough flexibility to represent real operational differences while preserving one shared product model across the platform.
Adapt the platform to different SCRAP and regulated operating models.
Turning every implementation into an isolated client solution.
Create a common foundation of roles, states, permissions, workflows and configurable rules.
Product direction
Three decisions created the foundation for an adaptable product.
Build one model that could adapt to different organisations.
Every SCRAP or regulated organisation could introduce different actors, responsibilities, rules and validation processes. Building each workflow independently would have created a collection of client specific solutions rather than a scalable product.
I helped define a shared model of roles, system objects, states, permissions, transitions and configurable rules. This allowed the platform to represent organisational differences without losing its underlying product logic.
The model became the foundation used across declarations, billing, operations, logistics, reporting and configuration.
Trade offConfigurability required more product definition at the beginning, but reduced fragmentation and repeated decisions across implementations.
Turn regulation into visible product behaviour.
Regulatory requirements affected what users could do, which documents were required, who needed to validate them and when a process could move forward. The regulation could not be transferred directly into the interface as legal or technical complexity.
I translated regulatory and operational rules into visible states, contextual actions, permissions, validations, document requirements, alerts and exceptions.
The product did not hide regulation. It made its consequences understandable and actionable.
Trade offThe experience needed to remain clear without removing the traceability and control required by the process.
Connect management and transport through one operational journey.
Waste control could not end inside the manager platform. The physical movement of waste needed to remain connected to the same states, responsibilities, documents and operational data.
The transport app extended the product into the field. It supported routes, stops, collections, DIs, evidence, incidents and completion at destination.
I treated the manager platform and transport app as two surfaces of one service, ensuring that office planning and field activity remained connected through shared data and operational states.
Trade offSupporting different devices and working conditions increased coordination needs, but prevented transport from becoming an isolated operational tool.
My product direction
My role was to create the product logic that connected regulation, operations and execution.
My responsibility went beyond producing interface designs. I worked across Product, Engineering, business, operations and regulatory specialists to understand how the service worked, expose contradictions and transform fragmented requirements into product decisions.
I defined workflows, state models, information architecture and interaction patterns that teams could use to discuss responsibilities, permissions, exceptions and dependencies before development.
This made the relationship between modules visible. A declaration could affect document validation, billing, compliance and reporting. A waste operation could affect planning, logistics, DIs, evidence, reception and closure.
Design became a way to establish product clarity across the organisation, not only a way to represent decisions after they had already been made.
- Product modelling
- Experience direction
- Workflow definition
- State models
- Information architecture
- Interaction design
- Transport app experience
- Design documentation
- Product priorities
- Regulatory requirements
- Operational needs
- Technical feasibility
- Cross module dependencies
- Platform and mobile behaviour
- Product leadership
- Engineering
- Business stakeholders
- Operational specialists
- Regulatory specialists
- Client facing teams
The platform
One product foundation supports different regulatory and operational models.
Bezeroo was not designed as a fixed sequence of screens.
Its product model needed to support different organisations, workflows and responsibilities while keeping data, documents and traceability connected across the system.
Organisations can define the actors, permissions, centres, waste codes, containers, periods and rules required by their operating model.
Declarations, billing, operations, logistics, reporting and configuration share product states, documents and data.
Actions, documents, responsibilities and changes remain connected throughout the regulated process.
The product
The shared product model became a platform for control and execution.
Rather than presenting every module, the case shows four pieces of product evidence that demonstrate the product logic and the range of experiences it supports.
Managing declarations through explicit states.
Declarations required users to complete information, provide documents, respond to validation and manage authorised modifications. The experience used visible states and contextual actions to show what had happened, who was responsible and what could happen next.
Connecting waste operations from request to closure.
A waste operation could involve the requesting organisation, a manager, a transporter, several documents and a sequence of operational decisions. The platform connected request, assignment, acceptance, collection, reception, review and closure through one shared operational model.
Extending product control into the field.
The transport app gives drivers a focused view of the work planned and assigned through the central platform. Routes are organised by status, with access to stops, collection details, contact information, DIs, evidence capture, incidents and completion at destination. The experience needed to remain clear in real working conditions while preserving the documentation and traceability required by the organisation.
Keeping office and field activity connected.
Assignments and operational information move from the manager platform to the transport app. Status changes, documents, incidents and evidence return to the central system so teams can follow the operation without relying on separate tools or manual updates. The value comes from the connection between both surfaces, not from either product operating independently.
Product value
Configurability allows Bezeroo to support different organisations without losing product coherence.
Different SCRAP and regulated organisations can represent their own actors, rules and workflows through one configurable foundation.
Declarations, documents, operations, logistics and responsibilities remain visible across the product.
Waste movement, DIs, evidence, incidents and operational changes remain connected to the central system.
Administrative planning and field execution follow the same product states and shared information.
The product continues to evolve. The strongest evidence from this stage is the shared model, the connected workflows and the ability to translate regulatory and operational complexity into adaptable product behaviour.
What changed
Fragmented requirements became one connected and configurable product system.
Roles, states, permissions, rules and dependencies created a shared foundation across modules and organisations.
Product, Design, Engineering and specialists could discuss decisions through the same workflows and models.
The manager platform and transport app followed one operational logic across planning, execution, documentation and control.
New requirements could be evaluated against a coherent product model rather than treated as isolated features.
What Bezeroo changed in how I lead.
Bezeroo reinforced that complexity is not solved by simplifying one screen at a time. The most important work was defining a model that allowed different specialists to understand the same product and make connected decisions.
I would preserve the emphasis on roles, states and dependencies, but introduce shared product modelling even earlier so regulatory, operational and technical questions could be resolved before individual modules began to diverge.
The project made me more deliberate about using design not only to shape interfaces, but to improve how an organisation understands and builds its product.
Next case
Redefining the kitchen journey across digital tools, specialist advice and stores.
At Leroy Merlin, the challenge moved from regulated operations to a high consideration retail journey connecting customer needs, specialist advice, digital tools and physical stores.
Explore Leroy Merlin