CardioSignal design system

Design system · Medtech · Accessibility · Mobile

tl;dr

I built CardioSignal’s design system from the ground up to give design and engineering one source of truth. It cut duplicate work, made every design decision traceable for medical device certification, and became the base for a second product, CardioSignal Inside, launched with Mehiläinen.

background

In a certified product, inconsistency is a compliance risk

CardioSignal detects signs of atrial fibrillation using the phone’s gyroscope sensors. It is Software as a Medical Device, built under IEC 62304, so every change has to be specified, reviewed and traceable.

problem

Screens, but no system

When I took over product design, there were screens but no system. In the code, the onboarding flow alone had 3 separate top bar components, 3 ways to close a screen and 4 tab components, each built from scratch. Colours were named after palettes, not roles, so nothing told developers which one to use where, and there were no accessibility requirements. What shipped often didn't match the designs.

DECISIONS

Three calls that shaped the system

In a regulated product, speed, flexibility and compliance rarely point the same way. These decisions set the balance.

01 Borrow the structure, own the look

We built on Material 3 rather than a custom system. Flutter supports it natively, so developers could adopt the tokens without rewriting the app. A custom system would have given more visual freedom, but Material 3 was faster and carried less regulatory risk.The structure is Material 3. The look is CardioSignal’s: its own colour scheme and type, applied to Material’s roles and scale.

Material design tokens

02 Put accessibility in the system, not the screens

Accessibility is built into the tokens and components, not checked screen by screen. Every text and background pair meets WCAG AA contrast, text sizes stay readable at every level of the type scale, and every tappable component has a 48dp minimum touch target. A new screen built from the system starts accessible.

Contrast of each colour role against its matching "on" colour. AA needs 4.5:1 for body text, AAA needs 7:1.

03 Bring regulatory in early to avoid rework later

Weekly syncs with developers and the regulatory team cost time every week while the system took shape. I chose that cost over late surprises. Regulatory could flag blockers before anything was designed, so no work went into solutions they wouldn't approve.

THE SYSTEM

Foundations first, then components

I defined colour, typography, spacing and elevation first. Eight tonal palettes feed a semantic colour scheme, so a role like Primary Container means the same thing in Figma and in code.On top sit 53 components in 17 categories, including medical ones like measurement results and cardiograms. Each one ships with usage guidelines developers build from directly.

A look into the component library

COMING TOGETHER

The activity calendar, redesigned for colour blindness

The activity calendar shows every measurement from the month at a glance. Most CardioSignal users are over 50, and many have some form of colour blindness. The old calendar told results apart by colour alone, so for many of them a normal day and a day with signs of atrial fibrillation looked the same.The new calendar pairs colour with shape. Signs of AF show as a ring, a measured day as a bold date with a dot, so the result reads the same with or without colour.

In the simulation, the old calendar’s green, amber and red turn into the same olive. The ring still shows signs of AF.

DESIGN TO CODE

Design and code speak the same language

Tokens follow Material 3 roles, so names match one to one. If the spec says Primary Container, the code says primaryContainer.

Every change follows the same path, from requirement to design, build, design review, QA and release. Each step links to the last in Jira, which feeds the IEC 62304 documentation directly.

IMPACT

How CardioSignal builds products now

REFLECTIONS

What I’d do differently

More of my work

Designing with AI: Skeins

Design system · Medtech · Accessibility · Mobile

tl;dr

I used a real problem to test where AI fits in a design process: knitters lose count when they put their work down. I wrote the requirements, and Claude built a prototype, a design and the app. I tested, reviewed and reworked at every stage. AI made building fast. The test findings, the visual quality and the accessibility fixes came from the design process around it.

background

A small problem to answer a bigger question

AI tools can now build prototypes, designs and code from a description. I wanted to find out what that changes for a designer, and what it doesn't. Reading about it wasn't enough, so I ran a full project with AI from start to finish.I picked a problem I knew well. When I started knitting, the stitches weren't the hard part. Counting was. Shaped pieces repeat a cycle: knit a set number of rows, then add or remove stitches. Put the work down for a few minutes and the count in your head is gone. Many knitters still track it with pen and paper, and existing apps count rows without knowing where you are in the cycle.Small enough to finish, real enough to test with users.

Process

I designed. Claude Built.

I split the work along one line: AI makes things, I decide what they should be. Every stage ran the same loop. I wrote the requirements, Claude built them, I tested or reviewed the result, then I decided what to change.

Stage 1  ·  Prototype

Something to test before anything to design

I described how the counter should work: count rows, track a repeat cycle, flag when to increase. Claude built a working prototype in an afternoon. That changed the order of my process. I could test real behaviour before I drew a single screen.

The test

I gave the prototype to an experienced knitter and told him only that it was for knitters. Two problems came up within minutes.

Both came from the same place. The app assumed people already understood how patterns are structured. AI had built exactly what I asked for, and what I asked for was unclear. The brief changed: Skeins didn't need to count better, it needed to be clearer.

Four principles

The test gave me four principles. They became the brief for every stage after.

Stage 2  ·  Design

AI gave me a draft. Taste made it a product.

I gave Claude the four principles, the screens I needed and what each one had to say. It produced a complete design fast. It was also generic: default blue and white, and information in the order it happened to be listed. Everything that makes Skeins feel like Skeins came from my review.

What I changed

Visual: before and after. The AI-built counter next to my final card.(Screenshot to add.)
Visual: palette and logo.

Stage 3  ·  App

A system that checks the work, mine included

For the build, I gave Claude the final design and a structure to follow: foundations, primitives, compounds, screens, the same order as in Figma. AI writes code fast, so the risk isn't speed. It's drift between design and code. A design system with built-in checks is how I kept control.

Tokens

Tokens come in two layers. Primitive tokens hold raw values, like a specific sand or terracotta. Semantic tokens say what a value is for, like the main action or an increase. Components only use semantic tokens, so dark mode is a remap of one layer instead of a rewrite.

Components in Storybook

7 primitives, 4 compounds and 5 screens, documented in 60 Storybook stories. Each story is a real state: the counter at row 1, on the action row, in decrease mode, in dark mode. Storybook is where I reviewed what AI built, state by state, instead of clicking through the app hoping to find problems.

Accessibility, caught by the system

Storybook runs an automated accessibility check on every story. It flagged four colours. They came from my own palette, and AI had carried them into code without question. The worst was the orange decrease button: white text on it scored 2.9:1, below the WCAG AA minimum. I fixed each colour once, at token level, and every component that used it was fixed with it. All 60 stories now pass WCAG AA in light and dark mode.

Saving progress

Supabase handles sign-in and stores each project, and each person can only see their own. When you come back, the app opens on the row you left. Without an account it saves on the device, so nobody has to sign up to try it.
Visual: Storybook token page and component overview.
Links: View Storybook · Try the app (add once published)

Impact

A working app and a process I can repeat

Reflections

AI builds what you specify, not what you mean

Information Design

Illustration work

Illustration · Various projects

tl;dr

Illustration is where I get to play. When a brief leaves room for it, I give a brand its own characters, scenes and details, and several of the companies I’ve worked with did exactly that. I draw in vector (Illustrator) and bitmap (Procreate), and by hand in watercolour.

illustration

CardioSignal

Blog  ·  2021 to 2024

I illustrated CardioSignal’s blog, which explains why tracking your health, and your heart health in particular, matters. Each illustration had to carry the idea of its article at a glance.

vector illustration

F-Secure

Events  ·  2018 to 2021

Tech people love their stickers. Events and internal campaigns at F-Secure kept calling for new ones, from Christmas gifts and a welcome back to the office after Covid to event promotion.

vector illustration

ParkMan

Email campaigns · 2016 to 2017

ParkMan’s onboarding emails introduced the app and shared tips for parking smarter. I illustrated them in a classic stroke style, so each email was easier and more fun to read.

More of my work

About me

Hi, I’m Erik. A product and visual designer based in Turku, Finland.For the past 10 years I’ve designed products, brands and visual systems for startups and large companies, including work in regulated healthcare.I start with research and validate through testing, so decisions are grounded in evidence rather than opinion. I work closely with engineering, marketing, sales and regulatory teams, and I’m comfortable owning a product from first concept to release.My focus is clarity: experiences that are easy to understand, easy to use and accessible to people of all ages. Function comes first. Craft and visual quality are how I make it feel right.

Experience

Education

Bachelor of Engineering, Information Technology, Turku University of Applied Sciences

Languages

Spanish (native), English (fluent), Finnish (beginner)