As Playo expanded across platforms, inconsistencies started appearing in the way interfaces were designed and built. Similar components had different styles, behaviours, and implementations, making it harder to maintain a cohesive experience.

With multiple teams contributing to the product, we needed more than a collection of reusable components. We needed a shared foundation that could bring everyone together.

I started by auditing Playo's iOS, Android and web experiences, identifying inconsistencies in typography, colours, components and interaction patterns.

I also ran sessions with marketing, engineering, product, operations, customer support and data to understand their challenges and how design decisions were being made. Alongside this, I analysed competitor products to find established patterns and opportunities to improve Playo's experience.

Playo's identity lived across marketing campaigns, social media and the product itself. Translating that identity into a consistent interface needed a shared direction.

I worked with the marketing team to align brand tone, colour palette and visual language, so the product felt recognisably Playo on every platform. Those decisions became the starting point for Bibs, connecting the brand's personality with what the product needed to do.

The audit made one thing clear: Playo's inconsistencies didn't start at the screen. They started with the smallest pieces. Three tag styles did one job, two chevrons meant the same thing, and two action styles sat in the same card. Every new screen re-solved those small decisions, so every screen drifted a little further.

That's why I chose atomic design. It builds interfaces up from the smallest parts, so a decision made once at the bottom carries all the way to the top. Fix a chip and every card that uses it is fixed too. Consistency comes from the structure, not from reviewing every screen.

It also gave every team one shared vocabulary. Engineers on iOS, Android and web already compose UI from small parts, so “is this an atom or a molecule?” became a quick, common way to decide where a piece belongs, who owns it, and whether it already exists. And because Playo-specific patterns like activity cards are assembled from shared atoms rather than drawn as one-offs, new features stay on-system by default.

Before any component, I built a token architecture with Figma variables. Foundational values sit in reusable primitives, and semantic roles give each one a job.

Every semantic colour carries a light and a dark value. The data team's numbers made that non-negotiable: Playo is busiest at night, with 7 to 8 PM the most-booked hour. Everything built on top shares one visual foundation, in both themes.

Atoms are the parts that can't be broken down further without losing their meaning: type styles, icons, buttons, checkboxes, radios, toggles and badges. Each is built only from tokens, with every size and state defined.

Molecules pair atoms into small, reusable units: an icon and a label become a chip, an icon and a message become a toast, a level colour and a label become a skill tag.

This is where the audit's duplicates disappeared. Instead of three tag styles doing one job, there is one chip with clear variants for default, selected and highlighted states.

Organisms are the distinct sections of a screen: activity cards, the filter sheet, calendar cards, list cards and the header. These are where Playo's product lives, and they're assembled entirely from molecules and atoms.

Because they share the same tokens underneath, an organism switches theme as one piece. Drag them across below.

Templates set the structure of a screen without its content: title bars for home, collapsed, image and action headers, with regions for the organisms below.

Pages are those templates filled with real content. The redesigned Home, Pay & Join, Playo PRO and the dark-mode screens were all built this way, which is where the system proved itself on real work.

A component library alone wasn't enough. Designers and developers needed a common reference for how components should look, behave and be built.

I documented Bibs in Storybook and GitHub, organised the same way as the system: foundations first, then components from atoms up. Every page explains when to use a component, then shows how, with copyable snippets and a live playground.

As AI-assisted development became part of how we prototype, I explored how Bibs could be used by AI tools, not just by people.

In a Claude project, Joinee Profile, I connected Claude to the Bibs Figma file. It rebuilt the system in code: the tokens as one file, and 31 React components, 25 of them traced back to their exact Figma nodes, with a written guide to every one.

From those parts, Claude assembled a staging app with 14 screens and flows, including Home, Play, Pay & Join, Booking and Split Payments, so ideas could be tried end to end on a real build. A design-audit skill closes the loop: after each screen, Claude compares the build with its Figma frame and checks every value against the tokens.

Bibs gave Playo's products a shared foundation, so design and engineering worked from consistent patterns and common references.

Teams stopped recreating familiar components, alignment between them improved, and the experience became more consistent across platforms.

Building Bibs taught me that a design system is more than a library of components. It's a way to connect people, decisions and processes.

Atomic design gave that a shape everyone could follow, from aligning the brand with marketing to working through implementation with engineering. The biggest lesson was to think beyond individual screens and build foundations that help a whole team move forward.