One design system for the A Tu Tu brand across web, mobile app and back office, from Figma tokens to a published npm package and a live docs site.
A Tu Tu is a multi-brand online shopping platform in Myanmar. The name comes from the Burmese word "အတူတူ", which means "together": many brands and shoppers in one place. Shoppers can browse fashion, beauty, rain gear and more, catch flash deals and pay in MMK. The brand has three products: a mobile app and a website for shoppers, and a back office where admins manage products, orders, customers and promotions. I wanted all three to feel like one A Tu Tu: warm, friendly and easy to use, with orange as the brand color that ties them together.
| At a glance | |
|---|---|
| Components | 22 (10 atoms · 9 molecules · 2 organisms · 1 UI screen) |
| Design tokens | 244 (+ 55 dark-mode and 79 back-office overrides) |
| Tests passed | 961 / 961 (staging and production) |
| Products it serves | 3 |
| Which products | Web · Mobile app · Back office |
| Current version | @attutu/[email protected] |
A Tu Tu is one brand with three products: a multi-brand online shopping app, a website and a back office for admins. The idea is one shared set of colors, type and components that every product builds from.
Each product was designed and built on its own. The same button looked different in each place, colors were copied as raw hex values, and states like focus or disabled were often missing. Every change had to be made three times.
We built one source of truth: design tokens and components in Figma, the same components in React code, tracked in one registry and tested against Figma before they ship.
We started with tokens (color, type, spacing, radius) in Figma, then designed components level by level using atomic design. A team of AI agents built each component in React, tested it against Figma on staging and production, and documented it. I approved each step, merged to production and approved each release.
| Decision | Why |
|---|---|
| Components use only semantic tokens | One token change updates every product, and nothing is hard-coded |
| Figma names = code prop names | Designers and developers talk about the same thing |
| Every state is drawn and tested | Missing hover, focus or disabled states break real use |
| One registry (Airtable) drives the work | Everyone sees each component's status in one place |
| Batch release from staging to main | Shipping one component at a time was too slow |
| A human approves production and releases | Agents never approve their own work |
| Usage text lives in Figma | Docs copy it word for word, so design is the single source |
Tokens come in two layers. Foundation tokens hold the raw values. Semantic tokens point at them and say what a value is for. Components only use semantic tokens, and Figma exports them to code for CSS, iOS and Android.