One design language for a storefront, a mobile app and an operations console — built while the platform underneath it was being replaced.






Black Knight sells single-origin crops from Ethiopia, Yemen, Colombia, Brazil, Costa Rica and El Salvador in 250g and 1000g, alongside curated boxes, drip sachets, capsules, Saudi coffee, brewing gear and accessories. The catalogue is not a flat grid of products — it is origins, harvests, roast profiles and collections that customers browse the way they'd read a wine list.
The business had outgrown the hosted platform it launched on. Everything — storefront, admin, order data, the link to the ERP — lived inside someone else's template. The rebuild puts a custom stack underneath: a Django and PostgreSQL backend, a Next.js storefront, a Flutter app, and an internal admin console, with historical orders and customers migrated across while the old store kept trading.
My side of it: define one visual system that holds across three very different surfaces in two reading directions, then turn a 162-line requirements backlog into screens the engineers could build from without guessing.
Three surfaces, one brand, no system A storefront, a native app and an internal console have almost nothing in common in layout, density or interaction — and all three had to look like the same company. Without shared tokens, each would have drifted into its own dialect within weeks.
Arabic and English as equals Not a translation layer bolted on at the end. Every component had to mirror cleanly, every numeral and price had to sit correctly in an RTL line, and Arabic and Latin type had to hold the same hierarchy at the same optical weight.
An admin console is a product too Half the design work is a surface no customer ever sees: product and box authoring, variant pools, origin and category management, stock, staff permissions, review moderation, and a home page that merchandisers compose themselves out of blocks.
Saudi commerce has its own shape Phone-and-OTP identity with an SMS route and a WhatsApp fallback rather than email-and-password. BNPL beside card payment. ZATCA-compliant invoices. Local carriers. Each one changes a screen, not just an integration.
Designing onto moving ground The data model was being rewritten and back-filled from the old platform at the same time as the screens were drawn. The design had to stay explicit about what each screen needs, and hold its shape when a field arrived late.
1. Take the requirements from the client Sessions with Black Knight to get the actual business on paper: how a crop becomes a product, what a box is, who touches an order, what the ERP already owns. Everything landed in one requirements board with a platform tag and a priority.
2. Build the fundamentals of the design system Colour, type, spacing and elevation as tokens first, then the core components — fields, buttons, selects, tables, sheets, empty and error states — each drawn to mirror for RTL and to survive Arabic and Latin text in the same slot.
3. Build the basic screens in Figma Onboarding, account access, home, then the catalogue and the console — assembled from the token set rather than drawn freehand, so a change to a field or a radius propagated instead of being repainted 40 times.
4. Use Claude Code to make the work faster and more accurate Checking a screen's fields against the backend contract, generating token scaffolding, and catching mismatches between a design and its requirements before they reached a build.
Onboarding and the app home were the first two flows delivered. Both are recorded from the Figma prototype — the home page's block composition and the onboarding sequence with its phone-and-OTP handover.


















11 June to 9 September 2026, ongoing. Requirements intake opened the work, the system fundamentals ran alongside it, and the screens started before either was finished — the only way to prove a token set is to build a real screen out of it.
An honest read of the design board on 9 September 2026: 7 delivered, 1 in progress, 16 in review, 30 queued. The shape is what you'd expect from a system-first approach — a slow, foundation-heavy start, then a queue that fills faster than it drains once the components exist and screens can be assembled rather than invented.
The foundation ticket stayed open for 85 days while six screens shipped on top of it. That is the point, not a delay — every screen that used the system also corrected it, and closing it early would have meant freezing the wrong answer in June.