Designing a scalable system for a growing dev platform.

Context

I started collaborating with Shuttle in 2022 to define the web presence and visual direction ahead of a funding round. Over the next three years, I owned product design across web, console, and growth. As the sole designer in a scaling, engineering-led team, I supported Shuttle from early traction to a platform serving 20,000+ developers and supporting 120,000+ deploys.

In the meantime, the platform had matured, but the interface needed to catch up. This case study focuses on the turning point: leading a system audit and full console redesign to restore structural coherence after years of incremental drift.

Early days

My first phase with Shuttle was about defining structure. I established the website IA, created a modular visual system, and connected brand and console into a consistent direction. As the console moved toward early beta I translated infrastructure workflows into usable flows, built the initial information architecture, and introduced onboarding logic into a CLI-first product.

The problem

As the platform evolved, features were layered onto the original foundation. Nothing was catastrophically broken. That was the problem. The console worked, but patterns slowly diverged. Grays varied. Borders and radii shifted. Navigation evolved per page instead of as a unified system. What started as structure drifted into inconsistency.

For users managing multiple projects, workflows felt heavier than they should. Important actions were sometimes buried or positioned differently across screens. The interface began to feel like an accumulation of decisions rather than a single, intentional system.

For the team, the cost showed up in every new feature. Each screen required micro-decisions about which pattern to use or whether to introduce another variant. Instead of focusing on clarity, we were negotiating visual consistency. Without a strict token system, implementation slowed and alignment between design and engineering grew fragile.

Audit and reset

When I returned from a short break in 2025, I saw clear divergence between the intended system and what existed in production. Continuing to design feature by feature would result in a Frankenstein of a product.

User feedback reinforced the same pattern: better discoverability, more consistent workflows, and a console that matched Shuttle’s reliability under the hood.

The risk was subtle but real: erosion of trust and friction in everyday workflows, so I proposed stepping back. I conducted an audit across production screens, mapping inconsistencies in tokens, components, spacing, and layout logic. The pattern was obvious: this wasn’t isolated noise, but accumulated design debt.

The strategic question became whether to patch or reset. I prepared a discrepancy review outlining what drift was costing us and what consolidation could unlock. Together with product leadership, we aligned on a full redesign.

Redesigning for structural clarity

The redesign was not about making things look fresh. It was about restoring logic.

• A tighter token system for color, spacing, radii, and typography to eliminate visual drift.
• A unified card and layout language to replace fragmented panel and table styles.
• Consistent navigation and page headers so users always knew where they were and what actions were available.

The second step was restructuring the console around a clear hierarchy. The project overview became the anchor: deployments, domains, resources, and key actions lived in one place instead of being scattered across separate screens.

Setup flows were redesigned to remove ambiguity and guide users through validation step by step. Moving between sections no longer required re-learning the interface.

Across the board, patterns were standardised so new features would extend the system rather than fragment it further. We kept the console opinionated and aligned with Shuttle’s code-first philosophy. Every decision was filtered through one principle: reduce cognitive overhead and improve predictability at scale.

Outcome

For users, the console became predictable and guiding. Information hierarchy was clearer, patterns were consistent, and managing multiple projects felt structurally sound.

For the team, the redesign established a stable UI foundation. Feature work moved faster and with fewer debates because patterns were predefined and enforced.

Design and engineering were aligned again. And the interface finally matched the maturity of the platform.

Reflection

Design systems rarely fail because of one dramatic mistake. They erode through small, reasonable decisions made in isolation. In fast-moving, engineering-led environments, someone has to notice when things start to diverge and be willing to reset them. The structure doesn’t maintain itself.

If I approached this again, I would push earlier for stricter consistency between design decisions and what actually ships to prevent the drift.