The daily operating system for Packhelp's Production & Supply-Chain team - managing order queues, production tracking, exceptions, and bulk operations at scale.
E-commerce · Supply Chain
Industry
Product, IA, UI, design system
Role
Web · CRM · 0→1
Platform
In-house
Type
2018-2020
Timeline
Company
The two surfaces users lived in
Production order detail (left) and the accounting order ledger (right) — driven by one shared order model.
01 / Overview
Problem
Packhelp was scaling fast across Europe while the internal tools running production, orders and payments were quietly breaking down. Teams worked in silos, finance tracked payment states in spreadsheets, and production coordinators had no reliable view across external print facilities.
The task
Build one platform that gives three teams a coherent, role-specific experience — without duplicating data, creating access confusion, or adding cognitive load to a high-pressure operation.
My role
Embedded senior product designer in the cross-functional team (CEO, PM, engineering). I owned end-to-end design across all three operational surfaces — research, prototyping, final UI, and the design system built to support them.
02 / Discovery
I started with the people, not the data model. I ran interviews across every department that touches an order — production, accounting and sales — to understand how each team actually works: the tools they used at the time, their workflow end to end, what they needed first, and where the process broke. The findings became the documentation the platform was specified from.
From that point the loop stayed tight: two-week sprints, and each department nominated one person who validated prototypes and functionality before anything went into implementation.
The core complexity, mapped early.
A single order crosses dozens of states across sales, production, external print facilities and finance — each visible to a different team.
Making that legible per role was the central design constraint.
03 / Web platform
The design bet was extensibility: a system of views instead of hardcoded screens, so new data and workflows slot into a pattern rather than triggering a rebuild.
01 · Flexible architecture: a system of views, not screens
Default templates and custom views
Each role builds custom columns, filters and saved views without engineering — adding a data type means slotting it into an existing pattern.
Custom views without engineering
Columns, filters and saved views are composed by the user. Adding a data type means slotting it into an existing pattern rather than commissioning a screen.
Problem
Operations changes faster than a design-and-build cycle. Every new data type, exception type or reporting need would otherwise mean a new screen and an engineering ticket.
Decision
I designed the platform as a view system: shared list and detail templates, with per-role columns, filters, saved views and action sets configured by the user rather than built by engineering.
Rationale
I referred to Airtable's approach, where users compose views instead of relying on engineering. This is more focused: it's a single order model with configurable views.
Outcome
Adding a data type became a configuration step inside an existing pattern instead of a new build.
Production space
The queue as a coordinator reads it: what is in production, at which facility, and what is late.
Single order details
Each space shows the states it can act on and collapses the rest into a summary, so an order crossing dozens of states never presents dozens of states to one person.
Problem
Production, accounting and sales each treat the same order as a different object. Giving each team its own tool duplicates the data; giving them one shared screen forces every role to read past information it never acts on.
Decision
One order model, three spaces, each with its own default views, vocabulary and action set.
Rationale
The interviews showed the disagreement was about attention, not access: the teams needed the same record, ordered differently. Separate tools would have re-created the spreadsheet problem the project existed to remove.
Outcome
Three role-specific experiences with no duplicated records.
Accounting space
The same orders, ordered by payment state — the view that replaced the spreadsheet finance was tracking payments in.
Sales space
The order as a customer offer: what was promised, and whether the operation is on track to meet it.
Problem
A single order crosses dozens of states across sales, production, external print facilities and finance. Exposing all of them to every role makes the queue unreadable; hiding them makes exceptions invisible until they are expensive.
Decision
I tiered status visibility by role: each space surfaces the states it can act on, collapses the rest into a summary, and escalates exceptions into the queue.
Rationale
Each role acts on only a slice of the lifecycle, but an order stalling in someone else's slice is exactly what they need to notice. Tiering keeps the daily view scannable without hiding the failure cases.
Outcome
A documented status model engineering could build against, with defined patterns for exceptions and hand-offs between teams.
The platform went into use: the teams it was designed for worked in an alpha version and later moved to the production release. My engagement ended at handoff, so this case study covers the system I designed and specified for build — the architecture, the role model and the design system — not post-release performance data.
Deliverables
Three role-based spaces — production, accounting, sales — on a single shared data model
An extensible view system: default and customisable list/detail templates
with per-role columns, filters and action setsThe full order-lifecycle state machine, made legible through role-tiered status visibility
A design system built from scratch to support all of it
3
role-based spaces on one data model
60+
operational users the platform served
0→1
The most expensive mistake was conflating role-based access with role-based UX — related problems that need separate design treatment.
Access defines what a role may see; UX defines what it should see first. Getting the permission model right did nothing to make the queue readable, and we paid for the difference twice.
