Angelswing
~70%
fewer 1:1 design handoff meetings
3 systemic changes
Design system, handover, sprint rhythms
Unified
shared language across design, dev and QA
The product moved fast. Its shared design language didn’t.
Angelswing builds digital representations of construction sites. New features shipped continuously, and the product had outgrown its original design foundations. My task wasn’t a redesign, but improving an evolving product without slowing it down.
Inconsistent patterns • Knowledge held by individuals • Handoffs that needed walkthroughs
Components and states had grown feature by feature. Design decisions and edge cases were mostly understood through conversations with the people who had built them. Handoffs often needed detailed walkthroughs and developer 1:1s, and small changes could have unintended effects because the Figma files lacked a robust component structure.
Four sources told me what to fix first.
A large share of usage happened on tablets, but previous designs assumed a desktop.
The sales team’s insight changed how I approached touch targets, interaction density and several existing workflows. But of course, there were desktop users as well. It was important not to alienate either group.
I built the foundation alongside feature work, with developers in the room.
When I first joined the team, I was working off product screenshots to mock up new designs. But rather than pausing delivery, I gradually developed a Figma library of components and patterns while consulting developers on feasibility, behavior, reuse and constraints. The PO contributed their knowledge of existing best practices to the handover documentation, so the system became a shared working model.
Conversations slowly shifted from “How should this button look?” to “What should this component do in this state?”
Questions got answered before development started.
A design sprint ahead of development gave the team time to explore requirements, prototype, document decisions and align with stakeholders who had relevant information about the changes. Involving QA in backlog planning and design QA created a clearer path.
Requirement → design → verification → development → QA.
Shared knowledge replaced repeated walkthroughs.
One-to-one design handoffs dropped by roughly 70% in later sprints. Developers reused components, QA had a reference to check production against, and decisions no longer depended on one person. By the end, the process was mature enough to support additional designers. These are operational and qualitative outcomes. I haven’t claimed effects on revenue, conversion or velocity, because, frankly, they weren’t measured.
A simple tagging request exposed a whole workflow.
Engineering users at headquarters wanted to tag areas of the digital twin for the field team. Mapping it showed that a tag needs priority, assignment, the right recipient and a status, and that not every tag can simply be “completed.” Over several months, I made that hidden complexity visible to leadership, so we could decide what to build now and what to defer. Users responded well to the end result because it matched their real workflow.
Research changed my first idea.
I started with folders, the familiar solution. Conversations showed that what mattered was when something was captured and how it related to construction progress. I designed a supplementary lightbox interface that brings chronology into the media workflow, because construction media is a record of change over time.
We improved what was possible now and parked what needed research.
Leadership envisioned parametrically changing models, while engineering needed something reliable on an existing 3D library. I customized the interface to match the product’s language and postponed complex parametric interactions as a future research topic, so effort wasn’t committed to an interaction model whose technical feasibility still needed exploring.
The process and the product evolved together.
Alongside the systems work, a lot shipped in a year: tablet-friendly interactions, reporting workflows for different print requirements, integration of a third-party 360° application, better 3D usability, and workflow redesigns based on usability findings.
A feature request is rarely the whole problem.
Tagging involved assignment and status, media needed chronology, and 3D needed staged ambition. Good product design means understanding the system around the interface, solving what’s needed now, and giving the team enough structure to keep moving.