Designing SafeChat: borrowing the right things, ignoring the rest

Every messaging app your users have ever touched has already done design work on them. WhatsApp has taught a billion people what a chat list looks like. Slack has trained a generation of knowledge workers to understand channels, threads, and workspace structure. When you build a new messaging product, you are not working from a blank canvas — you are working against a set of expectations that your users bring in before they have even read a single label.

That could be a constraint. We decided to treat it as a resource.

Starting with a hybrid mental model

SafeChat needed to do two things at once that most apps choose between. It needed to feel personal and immediate — the way WhatsApp does, where you open it, see your conversations, and get straight to the point. And it needed to carry structured, persistent team spaces — the way Slack does, where a channel for the swimming group exists independently of any single conversation and accumulates context over time.

Most products that try to do both end up feeling like neither. They bolt a channel list onto a chat interface and call it done. The confusion that results — what is the difference between a group and a channel, why are there two lists, which one do I use for what — is one of the most common complaints in enterprise messaging, and we saw it in early testing too.

The answer we arrived at was not a structural one but a visual and linguistic one. The two concepts needed to feel different before a user even read a label. Channels are square. Chats are round. That one rule — enforced without exception across every surface in the app — does more work than any amount of explanatory copy. A circular avatar means you are looking at a person or a group of people. A square icon with a hash means you are looking at a persistent team space. You learn it once and it works everywhere.

Taking what works, leaving what doesn't

The biggest mistake in designing for a new context is reinventing things that already work. Quoted replies, read receipts, unread badges, message grouping by sender, sender-prefixed previews in the chat list — these patterns exist in every major messaging app because they are genuinely good solutions to real problems. We took all of them and spent no time questioning them. The goal was never to be original for its own sake.

What we did question was what WhatsApp and Slack each get wrong for a context like an Olympic Training Centre. WhatsApp has no structure — it is a flat list of conversations with no way to distinguish a casual chat from an important team announcement. That works fine for personal use. It does not work when a physiotherapist needs to find the medical team channel and cannot remember whether it was a group or a conversation they started six months ago. Slack solves that problem but creates another one: it is built for the keyboard, for desktop, for people whose primary work mode is typing at a computer. Athletes and coaches live on their phones. Slack on mobile feels like a concession, not a design.

So we took WhatsApp's immediacy and mobile-first sensibility. We took Slack's structural model — persistent channels, group membership, admin control. We dropped Slack's density and desktop bias. We dropped WhatsApp's structural flatness. What was left was the shape of SafeChat.

A colour system that carries meaning

Most enterprise apps choose a colour scheme and apply it uniformly. We took a different position: colour in SafeChat carries semantic meaning, and that meaning is consistent throughout.

The primary colour is Pine, a deep, warm green — #2F6F5E. It is the colour of active states, connection confirmations, primary actions, and the sent message bubble. It reads as calm and trustworthy without being cold. For an app that handles athlete welfare reporting and SafeSport compliance, that tone matters. It should not feel like a consumer app trying to be fun, and it should not feel like a government system trying to be serious.

The accent colour is Terracotta — #C2703D. It appears in exactly two places: the end-call button and the decline button on incoming calls. Nowhere else. That restraint is deliberate. Terracotta means "stop" in SafeChat. If users see it, they know what it does before they read it.

The most considered colour decision was the channel accent. Channels needed to be visually distinct from chats not just in shape but in tone. We gave channels a separate colour identity — still within the warm palette, but distinct enough that switching from the Chats tab to the Channels tab feels like a change of context, not just a change of list. This is a small thing in isolation. Across hundreds of daily interactions it becomes the thing that makes the app feel organised rather than arbitrary.

The background is Sand — #FAF7F2 — a warm off-white rather than a clinical white. It gives the app warmth without adding noise, and it differentiates the light theme from the kind of stark white that most productivity tools default to.

Dark theme is not an afterthought

Dark theme in SafeChat was designed in parallel with light theme, not derived from it. The in-call surfaces are always dark — #13150F, the Ink token — regardless of which theme the user has selected. This is a deliberate choice: calls are a different mode, and the visual shift reinforces that. When you are on a call in SafeChat it looks and feels different from when you are in a chat, and that is by design.

Every colour in the system is defined as a token with both a light and a dark value, so theme switching is never a visual surprise. The app looks intentional in both modes.

Accessibility was in the brief, not the backlog

OSP staff includes people across a wide age range and a variety of visual needs. We built font scaling as a first-class feature — not a browser zoom hack, but a dedicated setting that scales text from 15px to 18px across the entire app through a single CSS variable. Every component was built to handle this range without breaking. Bubble heights, row heights, and control bar layouts were all tested at the minimum and maximum font size before anything was signed off.

Beyond size, the font family is selectable. Plus Jakarta Sans is the default — warm, legible, designed for screen use — but users can switch it. The theme selector offers light, dark, and system-preference modes.

None of this is heroic engineering. It is the result of treating accessibility as a requirement during design rather than a fix during QA. The difference is that when it's in the brief from the start, every component decision has it in view. When it arrives at the end, you are retrofitting.

What the design system actually delivered

The decisions made at the design system level — the circle-vs-square shape rule, the semantic colour tokens, the font scale variable, the dual-theme token structure — meant that when we designed the call screens six months into the project, they looked like they belonged to the same product without anyone having to make that happen deliberately. The system did the work.

That is the actual value of a design system: not a library of components, but a set of decisions made once that resolve a hundred later questions automatically. The call screen needed a background colour — it used the Ink token. The decline button needed a colour — it used Terracotta. The active speaker indicator in a group call needed to be identifiable — it used the Pine border token. No new decisions, no new negotiations, no inconsistency.

The product looks considered because the system was considered. That is the work.