Loop design system · PackBack Network
One system for a dashboard, a phone app and a bin.
One design system for three very different surfaces: the PackPulse web app, the crew's iOS app and the touchscreens on our machines. Built with Arabic and right-to-left layouts from the start, for the Gulf launch.
- Role
- Product Lead, system owner
- Company
- PackBack Network
- Timeline
- Nov 2025 to now
- Team
- 1 product designer, 3 front-end engineers, 1 iOS engineer, 1 firmware engineer
- Platforms
- Web (React), iOS (SwiftUI), Machine screens, Figma
1One scale, three reading distances
2Machine targets never smaller than 64 px
3Arabic layouts built into every component
84%
Production UI built from Loop components
3
Platforms from one set of tokens
5 weeks
To ship Arabic machine screens and PackPulse
AA
Contrast on every token pair, checked at build
The problem
PackBack's three products had grown separately. Two purples, three button styles, machine screens hard-coded by the firmware team, and no plan for Arabic, even though the Gulf launch was months away.
What I did
I audited all three surfaces, designed a token architecture that covers web, iOS and machine screens, built the core components with the team, and made right-to-left layouts part of every component from day one.
What changed
84% of production UI now comes from Loop. When the first Gulf customer signed, we shipped Arabic machine screens and an Arabic PackPulse in five weeks instead of the three months engineering had estimated.
01 · Context
Three products, three ways of doing the same thing.
When I joined, PackBack had three customer-facing surfaces built by three groups of people. PackPulse was a React app built by a contractor. The machine screens were made by the firmware team inside the machine software. The crew app was about to be started. Each had its own colours, type and components.
| PackPulse (web) | Ops app (iOS) | Machine screens | |
|---|---|---|---|
| Who reads it | Operators at a desk | Crew in a van or basement | Strangers in a hurry |
| Reading distance | 50 cm | 30 cm | 1 to 1.5 m |
| Smallest target | 32 px | 44 pt | 64 px |
| Body text | 15 px | 17 pt | 28 px |
| Built in | React | SwiftUI | Web view on the machine |
| Languages | English, Dutch | English, Dutch | English, Dutch, Arabic |
On top of that, PackBack had hired a managing director for the Gulf region and was in talks with its first customers there. Arabic was coming, and none of the three surfaces could handle right-to-left text.
02 · Problem
Inconsistency was costing us speed, and Arabic would make it worse.
I started with an audit of every screen in production. It took a week and produced a wall of screenshots that made the case on its own.
Engineering estimated three months to make all three surfaces work in Arabic, mostly because layouts were built with hard-coded left and right values. That estimate was the moment the system stopped being a design nice-to-have.
The question we worked on
How might we give three very different surfaces one shared language, without forcing a phone app and a bin to look the same, and make Arabic a setting instead of a project?
03 · Research
Talking to the people who'd actually use it.
A design system has two audiences: the people who build with it and the people who see the result. I interviewed every engineer, sat with the firmware team while they changed a machine screen, and ran a small study with eight Arabic-speaking participants in Rotterdam and, remotely, in Dubai.
Engineers read the repository, so the docs live there
Nobody opened the old style guide. Examples sitting next to the component in the repository were used every day.
“If it's not in the repo, it doesn't exist for me.”
Machines need their own scale
Web sizes made bigger looked clumsy at 1.5 metres. Machine screens needed their own type scale and spacing, still from the same family.
“We just doubled everything and it looked like a toy.”
Arabic is more than mirroring
Participants expected layouts to flip, but not numbers, charts or the clock icon. Most preferred Western digits on receipts and machines.
“Flip the screen, but don't flip the time.”
04 · Process
Build what's used most, first.
We never stopped product work to build the system. Every component was built when a real feature needed it, starting with the 25 that covered 80% of what we saw in the audit. That kept the system honest: nothing went into Loop that wasn't being used.
One component library for all three
Tried for buttons. A web button scaled up for a machine looked wrong, and a machine button scaled down wasted space on the web.
Three separate systems
What we already had. Every change happened three times and drifted within weeks.
Shared tokens, platform components
One set of tokens and rules. Each surface gets its own components and scale, built from the same decisions.
05 · Design decisions
Shared decisions, platform components.
Three tiers of tokens, three outputs
Primitive tokens hold raw values. Semantic tokens hold meaning, like 'action primary' or 'surface warning'. Component tokens hold decisions for a specific component. Themes, density and the machine scale only change the semantic layer, so components never need to know which platform they're on.
Tokens live in Figma variables and are exported as JSON, then compiled into CSS variables for PackPulse, Swift for the iOS app and a theme file for the machine screens.
Accessibility lives in the tokens
Every foreground and background pair in the semantic layer is contrast-checked when tokens are built. If a change would break AA contrast, the build fails before anyone ships it. Machine screens use a stricter rule, 7:1, because they're read from further away and often in bright light.
- 01Figma variablesDesigners change a value
- 02Export JSONW3C token format
- 03Contrast checkAA for screens, 7:1 for machines
- 04CompileCSS, Swift, machine theme
- 05Visual testsScreenshots in three languages
Fails the build if contrast breaks
Right-to-left is part of every component from day one
Every component uses logical properties: start and end instead of left and right. Icons are tagged as mirroring or not. Arrows and progress flip; clocks, charts, play icons and our logo don't. Numbers stay in Western digits, which our Arabic participants preferred and which match card receipts in the Gulf.
We tested every component in Arabic from the first week, using real copy written by a native speaker. I speak Arabic, which helped with reviews, but it didn't replace testing with people who'd actually use the screens.
Documentation next to the code, readable by people and by tools
Each component has usage rules, do and don't examples and a structured spec in the repository. Our engineers increasingly build screens with AI coding assistants, and with the spec in reach those tools reuse Loop components instead of inventing look-alikes.
06 · Governance
Small team, light rules.
A startup can't afford a design system team. Loop is owned by me and one designer, with engineers contributing directly. Anyone can propose a component with a short template, and we review proposals every Thursday.
Template filled in
Problem, where it's used, why existing parts don't work.
Thursday review
Design and engineering together, 30 minutes, decision on the spot.
Used in one feature
Lives in Loop with a beta tag until a second feature needs it.
Documented and tested
Docs, RTL check, contrast check, visual tests in three languages.
07 · Outcome
The Arabic launch was the real test.
When the first Gulf customer signed in July 2026, we had five weeks before installation. Because RTL had been part of every component since the start, the work was mostly translation, review and testing. Arabic machine screens and an Arabic PackPulse went live on schedule.
“We quoted three months for Arabic. It took five weeks, and most of that was waiting for copy.”
“I changed the machine colours for a customer in an afternoon. That used to be a firmware release.”
08 · Reflection
What I'd do differently.
I would have brought the firmware team in a month earlier. The machine scale was the most original part of Loop, and their constraints shaped it more than anything I designed in Figma.
I'd also measure adoption from day one. We only started scanning the codebase in January, so the first two months of progress are estimates.
Tools on this project
Figma variables, Tokens Studio, Style Dictionary, Storybook, SwiftUI, Chromatic, GitHub
Names of the people quoted have been changed to protect their privacy.
PackPerks →