Systems
Systems
I don't design screens. I design the rules that produce them. That sentence is easy to say and hard to prove, so this page points at the evidence rather than repeating the claim.
What I've actually built
A design system from scratch. At IoTBlue I built the Cervello design system — components, tokens, interaction patterns, and the governance around them — for a platform sold to developers building their own products on top of it. Not a UI kit. A system with rules about when things are used, not only how they look. → Cervello — Method, System & Documentation A documentation format that outlived the product. The Feature Catalogue: one document per feature, thirteen sections, tracking it from problem statement through acceptance criteria to every iteration after release — each iteration added as a thread inside the same document rather than a new file. The common failure isn't that teams don't document; it's that documentation fragments until nobody can answer why is this like this. This format keeps the reasoning in one place. A four-layer permission architecture. Instance → Organisation → Team → Project, each with its own scope of visibility, in a B2B product where the buyer is frequently not the user. → Cervello — Permission Architecture
EvidenceMethod & Design SystemEvidencePermission ArchitectureWorking inside a system I didn't own
At Mashreq, the component library is shared across Egypt, the UAE and Pakistan. It's an honest thing to describe precisely: it supplies components and their visual states, but not the usage rules — when a button locks, how an error is phrased, where a summary bar sits. That governance layer is what's missing, and I say so plainly rather than calling it a design system. The practical consequence is that consistency across six systems and two languages was achieved by hand, screen by screen, without a written rule to point to. Consistency was manufactured, not inherited. I contributed components back into that library — a meeting-preference card, an accordion, RTL variants — reviewed by the system team and absorbed into the shared set. And in my first year I requested RTL support be added to the library at all. → Egypt — Accessibility & the component library
EvidenceAccessibility — Bilingual, RTL & Regulatory ComprehensionThe patterns that repeat across the work
Reading the case files together, the same structural decisions keep surfacing. These are what I actually mean by systems thinking: An exception is an object, not a message. A query raised inside a bank's review system carries a classified reason, a stage, a status, an author, and the specific artefact it points at — which is what makes the replacement automatic rather than manual. The same record, rendered twice. A customer sees a conversation; an officer sees a table. Same data, opposite densities, because one has a single application and needs a story, and the other scans dozens and needs to sort. Errors are attributed, not prevented. Past a point, layered review stops being safety and becomes paralysis. The protection is that every action is timestamped and owned, and the person who decides isn't the person who assessed. Structure serves whoever is doing the work. A linear sequence fits the person entering data and obstructs the person checking it — a lesson I learned from both directions in the same programme.
Coming
An open-source design system, built in public. Not yet published. This page will link to it when it exists — not before.