Case Study · WS Audiology · 2023

RTApps Figma Library

Owned the Figma library · Sketch-to-Figma migration, atomic design, auto-layout, documentation

The RTApps Figma component library behind Signia’s hearing-aid apps, migrated from Sketch. I rebuilt every component and screen on real library instances, with an atomic structure and documentation. One change to a component then propagated to every screen that used it, and the app it powered won a UX Design Award in 2023.

Design Systems Component Library Atomic Design Multi-brand Sketch Migration
RTApps components · real instances from the library · one set, themed for every brand

RTApps is the WS Audiology platform that powers the companion mobile apps for the group’s hearing aids. One product, many brands. I owned the Figma component library that turns that platform into pixels: I led its migration off Sketch, rebuilt it under atomic design with auto-layout from the ground up, and shipped the documentation conventions every designer on the team now follows.

When I joined WS Audiology, the source of truth was a Sketch library that had grown past the point of being usable. Components had drifted, overrides were inconsistent, naming was tribal knowledge, and resizing anything by hand cost an hour. Engineering and the brand-app teams were starting to fork off their own variants because the central library could not keep up. The migration to Figma was the moment to fix the file, not translate it.

6+
Brand spinoffs themed from one library
UXDA
UX Design Awards 2023 winner

The brand spinoffs the library carried

Signia is the flagship. Five sister brands were themed from the same component set: Rexton, TruHearing, Audibene, HearCom, AudioService, with private-label apps on top of that. Each brand kept its own wordmark, palette and surface choices; the components underneath stayed shared.

A row of brand logos all themed from one RTApps component set: Signia, a navy sister brand, Vibe, myRemote, Sony, two Audibene Horizon variants, Integration, and Rexton.
Brand spinoffs · one component set, many wordmarks · Signia plus sister and private-label brands

This case is about the Figma file itself: how it was built, why atomic design held, and what auto-layout unlocked. RTApps is self-contained. It powers the companion apps for the hearing aids WS Audiology already has in the field, themed across Signia and its sister brands from one component set.

A Sketch library at the end of its rope

The pre-migration file wasn’t broken, just out of road. Sketch symbols had no real responsiveness; every screen size meant a duplicated symbol. Overrides did not nest deeply enough for a multi-brand library, so the same component existed three or four times with different colours baked in. The naming was carrying years of legacy, and the only person who could navigate the file confidently was the person who built it.

At the same time, the platform was scaling. Signia was the flagship, but the same RTApps engine had to skin into sister brands and private labels, each with its own visual identity. Without a library that could absorb that variance, every brand-app designer was about to fork the file. The work I needed to enable, multi-brand theming, was structurally impossible on the existing setup.

01
No real responsiveness

Sketch symbols could resize, but not relayout. Every breakpoint meant duplicated symbols. One source of truth, only on paper.

02
Multi-brand was glued on

Colour and type variants were duplicated per brand instead of derived. Adding a brand meant copying the file and editing every symbol by hand.

03
Naming was tribal

Legacy names from earlier app versions sat next to current ones. New designers could not tell which was the one to use without asking.

04
Forking was about to start

Brand-app designers were copying components into their own files to fix what the library could not. The central library was on its way to becoming a reference, not the source.

I owned the library, end to end

I was the designer who carried the file. From the migration plan and the atomic structure to every component’s auto-layout setup and the documentation pages everyone reads on day one. The library is consumed by the designers shipping each brand’s companion app.

What I owned

  • The full Sketch-to-Figma migration of the library file
  • The atomic structure: atoms, molecules, organisms, templates
  • Every component’s auto-layout and resizing behaviour
  • The variant matrix per component · state, size, brand
  • The documentation pages, naming, and contribution rules
  • Library publishing and the consumption pattern across the brand apps

Who I worked with

  • WSA brand-app designers consuming the library
  • Product stakeholders · release planning and scope
  • Engineering · matching component behaviour to the implementation

RTApps and the Signia App later won the UX Design Awards 2023, in the Medical Software category. The library was the source every screen in that award entry came from.

Sketch out, Figma in

The cheap option was to import the Sketch file into Figma and call it done. I argued for the expensive one: rebuild every component natively, on Figma’s terms, so we could finally use what Sketch had been missing. Auto-layout, variants, nested components, and proper publishing. The migration was the rare chance to fix the structure under cover of a tooling change.

Before · Sketch

Symbol-based, fragile

  • Symbols with overrides, no relayout
  • Per-breakpoint duplicate symbols
  • Colour baked into the component
  • Branch-and-merge via Abstract, slow
  • One owner who held the map
After · Figma

Component-based, responsive

  • Components with variants for state, size, brand
  • Auto-layout doing the relayout work
  • Theme tokens consumed via styles and variables
  • Branching native to the file, fast
  • Documentation pages so the file teaches itself

How I sequenced it

I didn’t rebuild everything before opening it to the team. The migration ran as overlapping phases, so the brand-app designers were never without a working library.

Atoms, molecules, organisms

I used atomic design because it gave the library a shared vocabulary across designers and a clean rule for where any new piece belongs. Templates and pages live outside the library, in the brand-app files.

Atoms
Indivisible primitives

Single-purpose, single-state, no internal structure. The pieces every higher tier composes from. Change an atom and the whole library updates.

Icons Type styles Color styles Spacing tokens Elevation Radius Dividers
Molecules
Composed, single-purpose

An icon plus a label plus a state ring is a button. A label plus an input plus a help line is a field. Built from atoms, exposing variants for state, size, and brand.

Buttons Inputs Toggle Slider Chips List rows Tab item Avatar
Organisms
Composed, multi-purpose

Discrete chunks of an app: a hearing-aid status card, a program list, a tab bar, a bottom sheet, a full dialog. The pieces that change the way a screen reads as a whole.

Hearing-aid card Program list Tab bar Bottom sheet Dialog Equalizer Volume control Onboarding card

A new component goes in the lowest tier that lets it stay single-purpose. Buttons stay molecules even when they get complex. Anything bigger gets pushed up. If two designers disagree on where something belongs, the answer is almost always: smaller than you think.

Atoms in the file

The foundation pages publish the atoms every component composes from: the type scale and the colour system. Text styles ship per platform, iOS and Android in parallel, each a real copyable style rather than a value to eyeball.

iOS Android
Header Adjust your hearingiOS/Head/Header Adjust your hearingAndroid/Head/Header
Subtitle Program & volumeiOS/Sub/Subtitle Program & volumeAndroid/Sub/Subtitle
Body Tap a program to switch your hearing profile.iOS/Bod/Body 1 Tap a program to switch your hearing profile.Android/Bod/Body 1
Button CONNECTiOS/Btn/Button CONNECTAndroid/Btn/Button
Caption Last synced 2 minutes agoiOS/Misc/Caption Last synced 2 minutes agoAndroid/Misc/Caption

Palette · what the screen carries

Right-ear red#D83831 · the right hearing aid
Left-ear blue#0072E3 · the left hearing aid
Success#008B58 · connected, goal met
Warning#CA8300 · attention states
Ink#1A1A1A · text and chrome
Surface#FFFFFF · the app background

Auto-layout on every component

Sketch’s missing piece was relayout. Figma’s auto-layout is the lever that turned the library responsive: a single component can stretch, hug, fill, and re-wrap based on its content and the frame it lives in. I built it in from the start · no component shipped without auto-layout · so the brand apps could drop the same instance into an iPhone SE and a 6.7″ canvas and have it behave.

Hug · Fill · Fixed

Every frame in the library uses one of three sizing rules. Hug to content, fill the container, or hold a fixed dimension when a control needs to.

Direction by purpose

Horizontal for inline composition, vertical for stacked. Direction is set by what the component is, not by what fits today’s screen.

Small screens first

Components were drawn against the 360 px Android grid first, then stretched up to 414 px iOS. The grid page in the library documents both, so the same component fits the smallest target without breaking the larger one.

Resize, don’t duplicate

A button at width 320 and a button at width 390 is one component, not two. That single rule killed half the file.

Variants for state, size, brand

State (default/hover/pressed/disabled), size (sm/md/lg where it matters), and brand (Signia and sister labels) live as variants on the component, not as separate components.

Frame as a container

Components never assume the canvas. They assume the parent frame. That is what lets the same component live in an iPhone, a tablet sketch, or a marketing mock.

Why this matters

The library’s job is to make the next screen cheap. Auto-layout is what makes that true: a brand-app designer drops in a list row and it works at any width, on any platform, in any brand, because the layout rules belong to the component, not to the designer who placed it. If you have to nudge it, the library failed.

One component, every brand

Same components, themed across the brands the platform supports. The variant matrix carries state and size; the brand swap is a Color Style change at the root. The library does not duplicate per brand · it themes.

Signia A Primary button themed in Signia red The Volume card themed in Signia red on a light surface
Rexton The same button themed in Rexton yellow The same Volume card themed in Rexton yellow on a dark surface
One component, two brands · the same button and volume, Signia red and Rexton yellow · a Color Style swap at the root

Where the library themed, and where it forked

Most components themed cleanly: same anatomy, brand-specific Color Styles, no structural change. A small set of organisms could not. Rexton ships its own Assist module: tutorial cards, illustration components, retry flow, onboarding list. These were brand-specific by design, so they lived as their own page in the library, alongside Signia’s. One library, two assistants · documented as such.

A Rexton Assist card on a dark surface: a yellow illustrated avatar with main text and auxiliary text
Rexton Assist · its own organism, documented alongside Signia’s

What the library ships

The library covers the surface area the brand apps use. Every component listed below is auto-layout enabled, has the full state matrix, and themes across the brands the platform supports.

Native, not redrawn

A handful of components were native to the platform · the iOS and Android search bar, the navigation bar, the system keyboard. The library wrapped the platform behaviour and documented the touch points, instead of redrawing them. Native components stayed native; the library’s job was to handle everything else.

In the wild · the Signia App consuming the library

Every element on every screen below is a library instance. The volume slider, the list rows, the status pills, the buttons, the navigation: nothing is local to the app file. Change the library, change every screen.

The Signia App Controls screen on iOS: a Controls header, a MyWellBeing card and Speech boost action, a Program selector reading Universal, a tall vertical Volume slider with the value 15, and a bottom tab bar with Volume, Balance, and Direction
Controls · volume slider, program selector, action button, tab bar
The Signia App Settings screen: a list of five rows — Hearing aid settings, App settings, Versions, Imprint, Heading — each with an icon on the left, a blue status dot and a chevron on the right
Settings · list rows with leading icons, status dots, trailing chevrons
The Hearing aids status sheet over a dimmed background: two device cards side by side — Left, in a red bordered state, reading Not connected and Tap to check battery level; Right, reading Connected, 30 percent. Below, an information note about Bluetooth and battery beeps, with Dismiss and Turn on Bluetooth actions
Hearing aids status · modal sheet with device cards, info note, action row
The Connect to TeleCare onboarding screen: an illustrated avatar with sound waves, a description of TeleCare remote services, a bulleted feature list, a paragraph about manual connection, and two stacked buttons — primary Set up TeleCare in red, secondary Set up later
TeleCare onboarding · illustration, body text, primary and secondary buttons

A library that teaches itself

A library nobody can navigate is a library nobody uses. I built the documentation in the file, not next to it, so the answer to “how do I use this component?” is one page-jump away from the component itself. Each page is in the same Figma file, kept current as the library evolves.

The Button documentation page from the RTApps library: a matrix with rows for Primary, Secondary, Assistant, Text Button, Icon + Text Button and Action button, and columns for Enabled, Pressed, Disabled and Active. Each cell shows the live component in that state, in Signia red.
Button documentation, live page from the library · button matrix · every cell is the real component
How to use this library
Read first. Atomic vocabulary, naming convention, where to find what, who to ask.
Contribution rules
How to propose a new component, where it goes, what state matrix it needs to ship with.
Foundations
Type, color, spacing, elevation, motion. The atoms documented one page at a time.
Component pages
One page per molecule and organism, with anatomy, variants, do’s and don’ts.
Brand themes
How the same component switches identity. Signia and the sister brands, side by side.
Release notes
What changed each publish, what broke, what to update in consuming files.

Every component anatomy uses the same diagram language: numbered call-outs over the actual component, with the corresponding atom listed below. The diagram is built from the live component, so it cannot drift when the component changes. The file teaches the convention by showing it.

The naming convention, written down

Eight rules for how every component gets named: component ID, type, operating system, appearance, name, version, status, state. A sample matrix at the right shows the rules applied to one component. Newcomers stop asking what to call things; the file already answered.

The Naming Conventions for mobile component library page: a numbered eight-row list on the left explaining each segment of a component name — Component ID, Component Type, Operating System, Appearance, Name, Version, Status, State. To the right, a matrix showing Button, Selection Controls and Dividers, with rows for type, OS, appearance, neutral/version, default/big, and enabled/focused/pressed/active states. Bottom-left lists three style rules. Far right shows the naming convention for component layers.
Naming convention page · naming segments applied to a sample matrix · sentence case, version sections with ‘/’

What shipped

The migration finished and the Sketch file was retired. The Figma library became the only place a brand-app designer goes to find a component. The product it underpins went on to win at the UX Design Awards 2023.

  • Every screen rebuilt on the real components: each component and screen flow moved from Sketch to Figma on the actual library instances. One change to a component propagated to every screen that used it.
  • One library, all brands: a single Figma file consumed by the Signia App and the sister-brand apps. No more forks, no more drift.
  • Atomic structure with auto-layout on every component: resize without duplication, retheme without copying, ship to iOS and Android from the same source.
  • Documentation in the file: contribution rules, anatomy diagrams, release notes. Onboarding for a new designer became a single afternoon, not a week of file safaris.
  • UX Design Awards 2023, Medical Software: RTApp for hearing aids of WS Audiology won. Every screen in the entry came from this library.

What the migration taught me

Migrating tools is the cheap part

The Sketch-to-Figma jump itself was a week of mechanical work. The hard part was getting the budget to rebuild rather than translate. I had to convince stakeholders that an import would carry the same structural debt across, and that the migration was the cheapest window we had to fix it.

Auto-layout is the system, not the polish

Treated as a finishing touch, auto-layout stays half-applied: some components are responsive, some are not, and the file looks consistent until you try it on a different device. Building it in from the first atom is what made the library hold together. Everything composed from atoms inherits the same layout discipline.

Variants made states cheap, Styles carried colour

Two Figma-specific calls shaped the rebuild. Variants turned the state matrix into a property panel: state and size flipped from instance properties on the canvas, so designers stopped duplicating an instance to change a state. For colour, I used Color Styles, because Figma Variables did not exist yet in 2023. Styles let me publish a swappable palette per brand, which was the closest thing to themable colour the tool offered then.

If I took this on today, tokens would be the base

In 2023, Color Styles were the furthest Figma let you go. The skinning engine for brand swap ran in code, written before I joined, with no design counterpart in the file. Today I would push for proper design tokens at the base · type, colour, spacing, elevation · with the library consuming them as Variables and engineering reading the same exported token set.

Accessibility was half done

Contrast, text scale and touch targets were enforced at the foundation level · type styles met WCAG AA, hit areas met the 44 pt minimum, focus and pressed states were part of every Variant matrix. Screen-reader support is where it fell down. Read-order, labels and VoiceOver/TalkBack semantics were not part of the file’s contract, and the previous app shipped with poor screen-reader behaviour as a result · documented in the accessibility evaluation of the previous app in the Bluetooth pairing case. The annotation system I built later, on a separate project, was the answer; if I rebuilt RTApps today, that layer would be in from day one.

Documentation in the file is the only documentation that lives

A library wiki sits next to the work. A library page in the file is the work. The documentation could not lag the components, because they were one page-jump apart. When a designer fixed a typo in a doc page mid-task instead of flagging it for later, the model had proved itself.