DES.Inna product designer

Swivl: rebuilding a field service platform

Swivl is software for field service businesses: the companies that send a technician to a house, quote the job and invoice it afterwards. In sales calls and user surveys the same feedback kept coming back. The product didn’t look like a tool made for them. It was fuchsia.

We moved it to a deep teal. That turned out to be the easy part.

Problem

User Feedback: Visual Mismatch with the Audience

Feedback from sales conversations and user surveys showed that the platform’s visual language felt out of place for a tool used primarily in trades and field operations.

Accessibility Issues

Beyond perception, the existing colour system had real accessibility shortfalls. Several colour combinations did not meet contrast requirements, creating legibility problems for users working in bright outdoor conditions — a common scenario in field service contexts.

Design System Fragmentation

Separately, the Figma environment had deteriorated significantly. The team was working on top of shadcn, but the files had drifted far from the library. Many components across the product had been detached and customised in place. There were no design tokens or Figma variables — colours, spacing, and type sizes were hardcoded per component. No rules existed for which component to use in which context, meaning different designers made inconsistent choices across the same product.

The result was a fragile, slow design environment where making a global change required hunting through dozens of individual instances.

System

The system under the colour

Several colour pairs also failed contrast, which matters when your users read job details on a phone, outside, in full sun.

The Figma files were built on shadcn, but they had drifted a long way from it. Components were detached and edited in place. Colours, spacing and type were typed in by hand. The same button existed under different names, sometimes in colours that weren’t in the system at all. Changing anything globally meant hunting through screens one instance at a time.

How we rebuilt it

We started by conducting a full audit across all product pages — cataloguing detached components, identifying inconsistencies, and documenting which elements were connected to the library versus which were floating. This gave us a clear picture of scope and helped us prioritise what to address first.

At the same time, we reviewed the colour system against WCAG contrast requirements, identifying every failing combination and mapping them against the most common use cases.

From fuchsia to teal

The new palette moved from fuchsia to a deep teal. Every new colour pair was checked against WCAG AA, starting with the densest screens.

One result looks odd on paper: the library got bigger, not smaller. Patterns that people had rebuilt by hand on every screen became real components. More components, far fewer versions of the same thing.

Flows

Flows built inside the new system

While the system was still being built, I designed the product’s core workflows directly in it. No retrofitting later: every flow tested the new components on dense, real screens before they were final. It also meant constant coordination. A decision in one stream changed the other two, so we kept checking each other’s work as we went.

Estimates and invoices. We started here: the screens where a business quotes a job and then bills for it. I redesigned both flows and settled on one layout pattern for them.

Jobs and tasks. Jobs came next, and that’s where the order caught up with us. The pattern we’d chosen for estimates and invoices was hard to stretch over jobs and tasks. Estimates and invoices hang off a job, not the other way round, so in hindsight we should have started from jobs.

Task scheduler. Built for the manager rather than the technician: one place to see who on the team is busy, how each task is going and how much time has been tracked against it.

Website builder. This one started as research. Swivl wanted its customers to get a website of their own quickly, so I mapped the builder options we could use and designed a much bigger concept, closer to a separate product than a feature. The budget didn’t stretch that far. We went with the simplest version: ready-made templates where a business changes the font, colours and content. Victoria took it further after my contract ended.

A designer reporting to me picked up smaller iterations on these flows, which let me stay on the system and the harder flow decisions.

Launch

The redesigned product soft-launched in September 2025.

1️⃣

Engineers almost stopped asking how to use components. The names and usage rules answer it.

2️⃣

New screens are assembled from the system instead of drawn from scratch.

3️⃣

In sales calls and surveys, users described the new look as more modern and nicer to work in.

Reflection

If I did it again, I’d start from jobs. We redesigned estimates and invoices first, picked a layout pattern for them, and then had to bend it to fit jobs and tasks. Everything else in Swivl hangs off a job, and the flows should have been shaped around it first.