Orderific
One design system across six platforms, with RTL, dark mode, and governance
Orderific is a restaurant management platform, spread across six platforms. It covers orders, payments, inventory, and the other tools that keep a restaurant running. I worked on the design system there in separate stretches, and each one was a different job.
- —Scaling the components, so they kept working as the product range grew
- —Adding right to left (RTL) support, and improving a dark mode a teammate had started
- —Hiring junior designers, then mentoring them and the quality analysts, and writing the onboarding doc
- —Writing the governance doc: what every interface has to pass before it goes to development
These sat on different timelines, so no single process ran through all of them. Each had its own. The design work always started with an audit. The governance doc came out of feedback meetings with engineers. What they kept getting stuck on became the rules.
Full scope breakdownRoughly 370 hours across separate stretchesShowHide
| Work | Time | Covered in |
|---|---|---|
| Audit | ~50 hours | Component architecture |
| RTL | ~80 hours | Theming and RTL |
| Mentorship | ~80 hours | Hiring and mentorship |
| Governance | ~120 hours | Governance doc |
| Hiring | ~40 hours | Hiring and mentorship |
Roughly 370 hours in total, spread across separate stretches
6
Platforms sharing one set of components
4
Separate jobs: components, theming and RTL, mentorship, governance
2
New designers I onboarded, plus a QA training session
3 token layers
Global, alias, and component
- Role
- Product designer, working to the product direction the team had set
- Team
- 4 designers, plus product managers and engineers
Three decisions that shaped the system
- 01
The product range was growing faster than the system could stay consistent. Fixing the components fixed every screen built on them.
- 02
I decided what mirrors and what holds still, component by component, then built that into each one.
- 03
The rules every interface passes before development were written down, so the system kept working when I was not there.
A dashboard assembled from the shared component set
Job one · Component architecture
Scalable components
The product range was growing faster than the system could stay consistent. I started with a design system audit of what was already there. Corner radius, spacing, and shadows drifted between products, and a lot of component states were missing. Designers were detaching components to get the state they needed, and engineers were guessing at the rest.
- —I added component properties where they were missing. A designer could then set a state from the panel without detaching the component
- —I simplified the ones that had grown complicated. An engineer could then read the structure and see which states and content were required
- —I set stricter global rules before building anything new, and moved gradients into design tokens. New components matched the system from the start
A component playground put every property in one place. Designers could reach any state from the panel. The panel also showed developers which states and content the component required.
The playground for an input: type, state, helper, and content all set from the panel
The same treatment on a large component, down to each item in the sidebar
The shared inputs in a customer welcome message workflow
The same system applied to filters, tabs, tables, and statuses
The full dashboard shows the system working across onboarding, metrics, charts, and data tables
Job two · Theming and RTL
Working out what flips and what stays
Dark mode was already partly set up. A teammate had added it as a new variable mode with its own values, and I carried it on from there. I extended it across the rest of the components and gave each one a switch, so a designer could see either mode without leaving the playground.
RTL was mostly mine, and it was the one job on this project that needed a real judgment.
Problem
Mirroring the layout was the easy part. The hard part was deciding, element by element, which components and which parts inside them should mirror. Get one wrong and the screen reads as broken to someone who uses Arabic every day.
Decision
Make direction a property of the component. Navigation, text, and reading order flip. Maps, the logo, the phone country field, and charts hold their position.
Why
Once the rule lives inside the component, the component applies it. A designer starting a new screen gets the right behavior without knowing the rule.
Tradeoff
All of the work comes first. Every component had to be audited and rebuilt before a single RTL screen existed. Mirroring a few screens for a demo would have been much faster.
- —I went through the components one at a time and marked what mirrors and what holds still
- —I built that decision into the component. The layout flips on its own, with no designer redrawing the screen
- —Every new component had to pass an RTL check and a dark mode check before I accepted it
The same screen both ways. The nav, cards, and controls mirror; the map, the logo, and the pin do not
Dark mode read straight from the tokens
No component needed a separate dark version
Job three · Hiring and mentorship
Onboarding new designers and QA
I hired the junior designers who joined the team. So I was also the one who had to get them working inside the system. The system only holds if the people using it know how it is meant to be used. I was explaining the same thing in person each time: what the different types of properties do, and when to use which one. So I wrote it down.
- —I hired the junior designers who joined the team
- —I wrote the design onboarding doc. It covers how the file is laid out, what each property type does, and when to use which one
- —I took two new designers through it as they joined
- —I ran a training session with the quality analysts on the basics. They could then check work against the system themselves
The file a new designer starts in: components grouped by type, each page documented
Job four · Design governance
A check before development
This one came out of feedback meetings with engineers. I listened to what they kept getting stuck on during handoff, and turned it into a document. It covers how an interface should be checked before anyone starts building it.
Problem
Engineers kept getting stuck on the same questions at handoff: what a state should be, which token applied, whether a screen had been checked in RTL or dark mode. Every answer came through me, which meant the system only worked when I was available.
Decision
Write the rules down as a check an interface has to pass before development. Make that check part of handoff.
Why
A rule in a document is a rule anyone can apply. It moved the system from something I maintained to something the team ran. It covered the designers I had just hired and the QA team.
Tradeoff
Governance only works if someone enforces it, and nobody enjoys that job. It also goes out of date, so the doc needs an owner after the person who wrote it leaves.
- —Naming rules and file versions, so any component can be found and its history traced
- —A three tier token architecture with global, alias, and component levels. One color change reaches every product at once
- —Node IDs as the single source of truth for each component. That also let developers point AI tools at the actual component
- —A design QA checklist run on every interface before handoff: states, content, RTL, dark mode
Part of the governance doc: how tokens are named, layered, and kept in one place
Outcomes
What the four jobs produced
6 platforms, 1 component set
The full product range stayed visually in line off one shared library
3 token layers
One color change reaches every product at once
2 directions, 2 themes
RTL and dark mode became properties of the components
2 designers and the QA team onboarded
The doc walked them through the basics, so handoff questions went to the document