Work Nine squads, one way to build a screen.
ButtonInputModalBottom sheetCardNavigationTabDropdown+ more
ttbTouch & ONE AppJun 2022 – late 2023

Nine squads, one way to build a screen.

ttb's retail app was built by 9+ squads, each with its own components. The app looked inconsistent, and QA had nothing to test it against. I helped build v2, then worked inside the squads until they used it.

My role
Core contributor, onsite with the design system team
When
v2: Jun 2022 – late 2023. I then led v3 until Dec 2024
Version
v2 (v1 was the legacy library)
Products
ttb Touch and ONE App
Tools
Zeplin → Figma

Impact

9+squads supported
2apps: ttb Touch and ONE App
1shared reference for design, dev and QA

The problem

Every squad built its own screens from its own specs, so the same choice looked different from flow to flow. Three groups paid for it:

  • Customers saw an app that felt like several apps.
  • Developers rebuilt components another squad already had.
  • QA had no reference, so a UI bug in one squad was "fine" in another. UI bugs crowded out feature bugs.

The inconsistency ran at two levels:

  • Style: the same radio card in different heights and spacing, and the same product named "me save" on one screen and บัญชี มีเซฟ (me save account) on another.
  • Pattern: no rule for when to use a radio card or a plain radio row, or when a bottom button should stay pinned or scroll with the form.

A component library fixes the first level. Only a written guideline fixes the second.

Open account screen (เปิดบัญชี): three tall radio cards for All Free, No Fixed and a product written in English as me save, with the Next button far below.
One open-account screen: tall cards, the product written as "me save".
Another open account screen: three shorter radio cards with tighter spacing, the same product written in Thai as บัญชี มีเซฟ, and a note under the cards.
Another: shorter cards, the same product as บัญชี มีเซฟ.
The same choice, built two ways. Public ttb app screens.
Identity verification screen (การยืนยันตัวตน): ATM verification as a highlighted radio card, then NDID, 7-Eleven and a service point as plain radio rows under a collapsible heading, and an orange Select button with a save-for-later link below.
A radio card and plain radio rows on one screen. Which to use, and whether the button stays pinned, needs a written rule.

What I did

  1. Audited real use cases across products, starting with the selection controls.
  2. Designed component structures that covered every case I found.
  3. Agreed design guidelines with the team, including usage rules for patterns.
  4. Wrote the handover so the design system developers could build each component.
  5. Joined the squads: their events, their UX/UI design phase, and BA flow reviews. I covered everything design-system related: tokens, components, patterns and error states.
  6. Bridged two dev teams: the design system developers and each squad's developers.
  7. Helped QA verify UI against the guidelines and Storybook.

In 2022 design systems were still new in Thailand. We started with designers only and grew into a full team with iOS, Android and web developers, and specs moved from Zeplin to Figma. I also designed UI flows for the CS and COB teams.

Example: the radio card

I designed the radio card as a base structure with fixed slots: the selection control, a title and value row, a content area, and an action row. In the car-loan flow, the lending squad filled the slots with its rates and coverage package. It didn't touch styling or radio behaviour. Its estimate dropped from building a new component to using an existing one.

When a squad needed something the library didn't have, I routed it to the design system team as a new base component. Squads stayed on product features.

The base card: fixed slots, styling and radio behaviour built in.
ttb car-loan advertisement. A phone shows the loan amount and term, then a selected radio card: buy the coverage package and get a special rate of 5.91 percent instead of 6.06, the monthly payment, a list of three insurance items, the interest total, and links for details and changing the package.
The car-loan card, as ttb advertises it: the lending squad's content in those slots.

What changed

  • QA had evidence to test against: the library and Storybook.
  • Developers could rely on design system components instead of building their own.
  • UI bugs went down, so squads spent their time on feature bugs.
  • Squad estimates went down, because base components came from the design system team.

Legacy products move over slowly; there's no business case yet for a full migration.

What v2 taught us

v2's tokens and components were too specific, so every new need became a new variant. That's why we started v3 in late 2023, which I led. Read the v3 story.

What I learned

A design system is a product. It needs to be adopted, not just built.From my notes on the project

And a library is only half of it. It fixes the spacing; only a guideline answers "card or row?"

Next caseI stopped re-reading my notes. Now I ask them questions.