Webtalk Design System
Building a design system as the lead designer on a relationship management platform for desktop and mobile browser.
System at a glance
Deliverables
Design system
Component library
UI design
Years
2019–2022
Context
Webtalk is an all-in-one platform for personal, professional and business relationship management — part social feed, part contact manager, part professional network. Founded in 2011 and repositioned around professional services in 2015, it ran an unusual growth model: a referral programme that shared revenue with beta users for inviting their networks. That meant referral, rewards and invitation surfaces weren't a side feature — they were a core part of the product I designed for.
I joined in 2019 as Product Designer and stayed three years. The product was web-only, delivered responsively across desktop, tablet and mobile browser.
My role
There was no design system. The files I inherited were built by copying elements from screen to screen, which turned every new feature into a search problem: does this component already exist, which version is current, and should I rebuild it?
Sole designer. No design team — I was the design function, working as design lead.
Owned UI and visual design end to end, and contributed to UX alongside the founder and Head of Development.
Worked directly with ~7 developers, plus the founder and Head of Development as my main decision-making partners.
The design system was my initiative. Nobody asked for it. I identified the problem, made the case, and got sign-off.
The problem
I inherited the design files from the previous designer, and they had been built by copy-pasting elements from one screen to another. There was no library and no source of truth.
The practical effect showed up within my first weeks. Starting any new screen meant a search problem rather than a design problem: does this component already exist somewhere, hidden in a file I haven't opened? If it does, which version is current? If I can't find it in ten minutes, do I rebuild it and add a fifth variant of something that already had four?
The product itself showed the symptoms. Looking at the pre-system screens:
Two or three competing button styles could appear on a single page — a solid cyan primary CTA next to pale grey outlined pill buttons, with no rule governing which was used when.
The rewards and referral pages had drifted into their own palette of pastel greens, blues and pinks that had no relationship to the brand blue used everywhere else.
Headings were inconsistent — uppercase section labels in one column, title case in the next.
Card treatments varied across the same screen: different radii, different shadows, different internal spacing.
None of this was anyone's fault. It's what happens when a product grows quickly without a system, and it compounds.
Constraints
No dedicated time
I built the system while continuing to deliver feature work. There was no project slot for it — I made the time inside the normal delivery schedule.
One product, three breakpoints
Desktop, tablet and mobile browser had to feel like the same product while behaving differently. This turned out to be the hardest technical constraint in the whole build.
Adoption by persuasion, not mandate
I had no authority to require anyone to use it. If the developers didn't find it genuinely easier, it would have died.
A live product
Nothing could be rebuilt from scratch. The system had to absorb what already existed and improve it incrementally.
Key decisions
1) Refining what existed, rather than starting over
Some foundations were already in place — typography, a core colour set, and buttons in their primary variations. The instinct with an inherited mess is to replace it, but a full visual overhaul would have meant redesigning every live screen, which nobody had time for and nobody had asked for.
I took what was there and extended it instead: kept the existing type and colour direction, rationalised the palette into proper ramps, and built out every missing variant and state.
The colour system ended up as five ramps — blue, neutral, green, red, amber — with semantic roles annotated directly onto the tokens: 700 as Main, 900 as Text, 400 as Borders, 200 as Background. One deprecated value stayed in the sheet, labelled 500 (Old), so anyone who found it in an existing file knew it was on the way out rather than guessing.
Rejected: a clean-sheet rebrand. It would have been more satisfying and would have shipped nothing.
2) Atomic structure, so the system could grow without me curating it
I organised the library as atoms → molecules → organisms. With one designer and seven developers, the system needed to be navigable by people who hadn't built it. An explicit hierarchy meant a developer looking for an avatar knew where avatars lived.
3) Sizing components by context, not by number
The avatar component ended up with seven sizes, and I named them for where they were used rather than how big they were: Profile 142, Profile Mobile 102, Cards 80, Platform 80, Mobile Card 48, Menu 36, Mobile Nav 28.
This was a direct response to the responsive problem. Naming by context meant that when a developer moved from a desktop card to a mobile card, the correct size was the one that said Mobile Card — no judgement call, no measuring. Naming by pixel value would have pushed that decision back onto whoever was building the screen, which is exactly where inconsistency comes from.
4) Building the button as a property matrix, not a pile of variants
The button ended up as the largest component in the system — 408 variants in a single set. That number is only manageable because it isn't 408 hand-made buttons; it's five named properties multiplied together:
Type · Size · Status · Leading Icon · Trailing Icon
So a developer picking a button doesn't scroll a list. They set Type to White with Border, Size to Large, Status to Hover, and toggle the two icon booleans. The combination they need already exists.
Underneath the set sit three base components — .base button Large, .base button Small, .base button Default — prefixed with a dot so they stay hidden from the assets panel. Shared structure lives in the base; the variants inherit from it. Changing padding or corner radius across all 408 meant editing three components rather than 408.
Rejected: a flat list of individually-built button styles. It's faster to make and it's the reason most design systems become unmaintainable by their second year.
5) Cutting templates
The original plan included a templates layer above organisms — full page-level compositions. I scaffolded the section, built a few, and then removed them.
Every feature the team built varied enough that a template never fitted without modification. A template that always needs changing isn't a shortcut; it's a fourth layer to maintain that quietly goes out of date. The organisms layer was already doing the useful work.
The empty scaffolding is still in the file — twelve named template pages, Newsfeed through Lightbox, all deliberately cleared out.
This is the decision I'd defend hardest. Knowing what not to systematise matters as much as knowing what to.
The work
943 components across 27 variant sets, organised over 45 pages.
Atoms
the 408-variant button set; an icon library of 343 marks split into line icons, colour icons, brand logos, file-type icons, arrows, profile icons and emoji; and the colour and typography foundations.
Molecules
Inputs and text areas across states with inline validation; dropdowns; switches; radio buttons; checkboxes; tags; progress bars; sliders; tooltips in four positions and two themes; toasts; lists; and the avatar set sized and named by context.
Organisms
Navigation as the largest piece: 32 variants of the web navigation bar and 17 of the mobile bottom bar, plus the sticky Webtalk menu, accordions and counters.
Roughly 1,280 instances of these components were placed across the file — the system wasn't a reference sheet sitting to one side, it was what the working files were actually built from.
The most demanding single piece was the Create Post composer. It had to handle text, photo, video and file attachments, collage and slideshow layouts with drag-to-reorder, audience selection, cross-posting to four external networks, and the Spotlight Post allowance — then do all of it again in a mobile layout where the same controls stacked into a fraction of the width.
Adoption
Once the system covered what I judged to be the minimum useful set, I presented it to the team. The team was small enough that this wasn't a hard sell — nobody objected in principle.
The more useful thing I did was record Loom walkthroughs so the developers could open the library themselves and play with it: swap variants, change states, change colours and text, and see how components were meant to behave rather than being told. That turned the system from a document into something they used directly.
I kept extending it as I built features. New components went into the library as they were designed rather than being retrofitted later, which is the only version of design system maintenance that actually survives contact with a delivery schedule.
The one real piece of pushback came from the founder, who felt the system was slowing my output down. He wasn't wrong in the short term — it was slowing me down. I made the case that the cost was front-loaded and the return would come to both design and development for as long as the product existed. He backed it, and the argument held up.
What shipped
The system lived in Figma as the design source of truth. The developers built their own parallel implementation in React, mapped to my components.
It covered the full product surface across desktop, tablet and mobile browser, and I maintained it for the remainder of my three years.
Outcome
New screens went from being designed from scratch to being assembled in an afternoon.
Production got faster and more precise for both design and development.
Design largely dropped out of the QA cycle. As coverage grew, screens built entirely from the component set came back correct, so design QA stopped being a required step for them. That was the clearest signal the system was doing its job — the work it saved was work nobody had to think about any more.
What I'd do differently
The system lived in Figma and the developers built their own parallel implementation in React. That was the pragmatic choice at the time — it was the path of least resistance for them, and it got the system into the product.
But two sources of truth drift, and they drift silently. It didn't bite us, largely because the UI stayed fairly stable across my three years there. On a product changing faster, it would have.
If I did it again I'd push harder to get the design tokens shared directly with the codebase rather than reproduced from it, even in the simplest form — a JSON export of colour and spacing values would have been enough to start. It would have needed developer buy-in I wasn't certain I could get at the time. It's the one structural weakness I'd fix.
AppTier integrates cutting-edge software, robust cloud infrastructure, and extensive field expertise to deliver ECM solution.
case study