Craft

The brief

Airthings' radon-monitoring app looks and feels "scientific." The task: evolve it into something more personal and relevant — an experience that fits a health and wellness brand.

At a glance

• My angle: reframe the product around how people feel about the air they breathe, not just the data behind it.
• What I designed: personas, a friendly onboarding, everyday screens, low-fi explorations, and a repeatable design process.

My starting point

You can't humanise a product without the people using it. Airthings already has an engaged user base that gives feedback — so my approach was to listen first, then design. Not redecorating a scientific app, but reframing what it's for: helping people feel good about their home's air.

Who we're designing for

Figure 1. The six personas driving the redesign

I mapped six user types — from a tech-savvy homeowner to a senior with health concerns. Each cares about air quality for a different reason: control, family health, sustainability, convenience, budget, safety. This kept the redesign grounded in real motivations instead of assumptions, and made feature priorities easy to defend.

The design direction

Four principles guided the work:

1. Lead with the brand, not the science. Airthings is already calm, modern and stylish — I leaned into that with a consistent design system, soft imagery and inclusive visuals.
2. Make the science digestible. Turn raw readings into plain-language insight, so users grasp what radon or CO₂ means for them without a chemistry lesson.
3. Talk like a human. Empathetic, actionable notifications ("here's what this means for you") instead of clinical alerts.
4. Support the whole wellness journey. Personal dashboards, goals, progress over time, and gentle wellness touches like guided breathing.

Onboarding — discover before you commit

Figure 2. Onboarding — explore before connecting a device

The onboarding welcomes users, explains key terms in friendly language, and lets them explore the app before connecting a device. Positive tone, simple illustrations, no information overload.

The everyday experience

Figure 3. Everyday screens — room air quality, trends, and a personal summary

Room-level air quality at a glance, a knowledge centre for the curious, clear trends over time, and a personal summary that treats air quality as part of overall wellbeing.

From idea to screen

Figure 4. Free-hand sketches — exploring ideas and the current app before committing to high-fidelity design

Quick hand sketches to explore layouts and ideas cheaply before committing to high-fidelity design.

How I'd run this as a project

Figure 5. The design process as a repeatable loop

I framed the work as a repeatable loop — from business requirement and user research, through iteration, low- and high-fidelity design, collaboration, testing and post-release follow-up. The redesign is a continuous process, not a one-off.

What I'd validate before going further: some ideas — gamification, badges, community testimonials — could deepen engagement, but they may not suit every Airthings user. I flagged these as hypotheses to test with real users, not assumptions to build on. Knowing what not to ship yet is part of the job.

The challenge

Futurehome's mobile app manages a household's energy: live consumption, connected devices, multiple energy sources, automations, a cost calculator, gamified savings challenges, and account settings. Every one of those had shipped as its own feature, dropped into the navigation wherever it fit at the time. There was no shared logic holding it together — so the app grew genuinely complicated: people (and new teammates) couldn't predict where anything lived, and every new feature made the structure a little worse. It needed a real information architecture, built from research rather than bolted on after the fact.

My approach

1. Started from research, not the existing menu. Built personas, mapped the relevant consumption and energy behaviors, and inventoried every feature and screen already shipped — so the new structure was grounded in how people actually think about their energy, not in how the backlog had accumulated.

Figure 1. Research and analysis — personas, findings, and a full feature inventory

2. Grouped features by what they were for. Instead of one long, flat list of everything the app could do, I clustered features into a small number of logical jobs: keeping track of consumption, controlling and automating devices, understanding cost, and managing the account.
3. Rebuilt the screen hierarchy from the ground up. Turned that grouping into a real sitemap — five clear top-level sections instead of a sprawling, inconsistent menu — with every sub-screen given one obvious place to live.

Figure 2. The rebuilt screen hierarchy — five logical sections, replacing an unpredictable structure

4. Prototyped every screen against the new structure. Wireframed the full flow — login through dashboard, consumption, events, automations, calculator, and settings — to pressure-test whether the new hierarchy actually held up screen by screen, not just as a diagram.
5. Documented the structure for engineering. Annotated flows and screen specs so the team could build against the new architecture confidently, and so it stayed consistent as new features were added after handoff.

Figure 3. Mockups and prototype — every screen built against the new structure

The challenge

Call center agents worked from one screen while live on a call: the script they had to follow, the customer's history and details, and the call controls itself. That screen had grown into a patchwork — script, customer data, and controls competed for space and attention, forcing agents to hunt across tabs mid-call. Under call pressure, that cost time and caused mistakes. There was also no shared design system yet, so every new feature added its own visual logic.

My approach

1. Mapped the whole product before touching one screen. Every feature idea went onto a board with no filter, then got grouped into themes, then sorted into what belonged in the MVP versus the backlog. The call-handling view — the cockpit — earned its place in the MVP on its own merits, which is what justified rebuilding it properly instead of patching the existing layout.

Figure 1. User problems mapped out

2. Watched real calls. I shadowed operators to see, in the moment, what information they reached for and when — not what the org chart assumed they needed.
3. Separated always-visible from on-demand. Mapped which information had to be permanently in view during a call and what could be pulled up only when needed.
4. Mapped assumptions and ideated. Wrote down what we were assuming about agents' needs, then ran fast ideation rounds to turn those assumptions into concrete directions worth testing.

Figure 2. How I worked with data

5. Rebuilt the layout into fixed zones. Script, live customer context, and call controls each got a predictable, dedicated zone instead of competing for the same space.
6. Built the design system this view needed. Established the components and patterns as reusable foundations, not one-off fixes — the first real design system for the product.
7. Rolled it out with a design team I was building from scratch, using the new structure as the reference point for every feature that followed.

A note on the visuals: the screens shown below reflect the user flow and interaction design from my work on this project. The visual UI and design system in the live software have moved on since and no longer match these screens as of now.