Back

Design leadership at an early-stage trading startup

Building a design function from zero inside a developer-first team: processes, a design system, a full platform redesign, and three major features in 8 months

When I joined the company, there was no design function at all. The product was built by engineers, shipped by engineers, and reviewed by engineers. Interfaces were assembled from whatever component libraries were at hand, and every screen looked like it belonged to a different product.

I came in as the first and only designer, with a design lead title and a simple mandate: make design a real part of how the company builds. Not a service desk that draws screens on request, but a function that shapes what gets built and why.

This case is not about one feature. It is about turning a developer-first startup into a company with a working design culture, while shipping a full platform redesign and three major features at the same time.

Redesign + 3 Features
8 months
Designer on the Team
1
Design Function
0 → 1
The platform before and after the redesign, side by side

Starting point

The honest picture at the start: no design files, no component library, no naming conventions, no handoff process. Feature specs lived in chat threads. Engineers made UI decisions during implementation because there was nobody else to make them.

This is normal for an early startup, and I don't think it was wrong. It got the product to market. But it stopped scaling the moment the team wanted to move faster and look like a serious platform.

My first two weeks were spent doing an audit instead of designing. I catalogued every screen, every state, every inconsistency. I counted 9 different button styles, 14 shades of gray, and 3 unrelated ways to show an error. That audit became my main argument in every conversation that followed. It is much easier to sell a design system when you can show the exact cost of not having one.

Earning a place in a developer-first team

You cannot install design processes in an engineering culture by writing a policy document. Nobody reads it, and nobody owes you anything. What worked was making design useful to engineers first, before asking anything from them.

I started with the things that were slowing developers down: missing states, undefined edge cases, unclear copy. Every spec I delivered covered loading, empty, error, and edge states before an engineer had to ask. After about a month, engineers started coming to me before writing code, not after. That was the actual moment design became part of the flow — not when it was announced, but when it became the path of least resistance.

From there I formalized the process step by step:

A weekly design review that engineers and the founders actually attend, capped at 30 minutes. A definition of ready: no ticket goes into development without approved designs and states. A handoff format in Figma with tokens, specs, and interaction notes in one place. A feedback loop after release, where we compare what shipped against what was designed.

None of this is revolutionary. The hard part was making it stick in a team where "just ship it" was the default answer to everything.

UI Rework After Handoff
-38%
Avg. Spec Turnaround
2 days → 4 hrs
The design process board showing the flow from idea to release with design gates

Design system from zero

The design system was built in parallel with everything else, because there was no time to build it separately. Every screen I redesigned produced components, and every component went straight into the library.

I set up the foundation first: a token architecture for color, spacing, and typography, synced with the codebase through CSS custom properties so that a change in Figma maps directly to a variable in code. Engineers can implement a component without asking me what a specific hex value means.

The system grew to around 80 components with documented states and usage rules. For a solo designer, the system is not a nice-to-have. It is the only way one person can keep an entire platform consistent while shipping at startup speed. Once the core library was stable, engineers started assembling simple screens themselves using existing components, and the results didn't need my corrections. That freed me up for the work that actually required a designer.

Components in the Library
~80
System-Built Screens
92%
Button Styles
9 → 1
Design system overview showing tokens, core components, and their code counterparts

Redesign and three features at once

The main constraint of this period: the company could not stop shipping to do a redesign. So the redesign, the design system, and three new major features moved in parallel over 8 months.

The redesign covered every surface of the platform: navigation, trading screens, onboarding, settings, notifications. Instead of a big-bang release, we rolled it out section by section, starting with the areas users see most. Each redesigned section immediately used the new system, so the platform converged toward consistency instead of waiting for a single launch day.

The three features shipped in the same window, each one designed from the first PRD draft to release:

The first was a complete rework of the core trading flow, where I redesigned the order placement logic and reduced the number of steps to open a position from 6 to 3.

The second was a rewards and progression layer that gave users a reason to come back daily. I owned the mechanics design here, not just the screens — the reward logic, the pacing, the anti-abuse constraints.

The third was a social layer where users can follow and copy other traders. This one required the most research: I ran competitor teardowns and user interviews to figure out which trust signals actually matter before someone copies a stranger's trades.

Doing all of this at once only worked because of the system and the process. Without them, one designer physically cannot hold four workstreams. With them, most screens assembled themselves, and my time went into the decisions that mattered.

Steps to Open a Position
6 → 3
Onboarding Completion
+21%
UI-related Support Tickets
-27%
Key screens from the three features: trading flow, rewards, and copy trading
Username selection flow diagram covering empty, taken, too-short, and too-long validation states, with a note on debouncing the availability check

More than interfaces

At a startup this size, "design lead" means whatever the company needs it to mean this week. Beyond the interfaces, I took ownership of things that would normally sit with a PM or an analyst.

I ran feature prioritization sessions with the founders, using effort-versus-impact scoring to decide what enters the next cycle. I wrote the PRDs for all three major features. I set up the basic product analytics events so we could measure what we shipped instead of guessing, and after each release I prepared a short results review that fed directly into the next planning round.

I also handled everything visual outside the product: marketing graphics, landing pages, app store assets, and email templates. When there is one designer, there is no "someone else" for this work. I treated it as an advantage — the product, the marketing, and the brand stayed in one visual language because they came from one hand.

Prioritization board and the analytics dashboard used for post-release reviews

Defining the design language

The most lasting part of this work is not any single screen. It is the set of principles the company now designs against, even in conversations where I am not in the room.

We wrote them down early and kept them short: density over decoration, because traders read numbers, not illustrations. Every state designed, because half-designed screens create bugs, not just ugliness. One way to do one thing, because two patterns for the same action means both are wrong. Ship, measure, adjust, because a design that never met users is just an opinion.

These principles now show up in engineering discussions and founder decisions without me pushing them. That is the point of the role. A design lead at a startup succeeds when the company keeps making good design decisions on the days the designer is not there.

Outcome

In 8 months the company went from having no design function to having a working one: a live design system, a predictable process embedded in development, a fully redesigned platform, and three major features in production.

The numbers I care about most are the boring ones. Less rework, fewer support tickets, faster specs. They mean the process works, not just that the screens look better. The company can now hire its second designer into a structure that already exists, instead of into chaos — and the system I built is the onboarding document.

Major Features Shipped
3
Platform Redesigned
100%
30-day Retention
+14%