From contributor to owner. This is how I helped evolve Poshmark's design system through two distinct phases — first bringing structure to a product that had outgrown itself, then rebuilding it from the ground up during a full redesign.

Project Overview

Context

When I joined Poshmark, I stepped into a product that had been evolving for over a decade. It was stable, widely used, and functionally strong — but visually, something felt off.

The same components looked different across screens. Design decisions varied from designer to designer. Everything technically worked — but the experience lacked cohesion.

What I was really looking at wasn't just inconsistency. It was a system that had outgrown its original structure.

This became the starting point of a journey that unfolded in two phases:

• Phase 1 — Understanding and improving the existing system
• Phase 2 — Rebuilding a new system from scratch during a full redesign

Understanding the Problem

What problem are we solving, and why does it matter?

<aside> 💡

Poshmark had been growing for over 14 years. The product had scaled — but the design system hadn't kept pace with it.

Over time, this created four compounding problems:

• Similar components behaved differently across flows — the same UI element could look and feel different depending on where you encountered it.
• Design decisions were made based on immediate needs — without shared guidelines, each designer solved problems locally rather than systematically.
• Foundational elements like typography, color, and spacing lacked shared rules — leaving every new screen open to interpretation.
• Engineering had to support multiple variations of the same UI element — which slowed down development and made the codebase harder to maintain.

This didn't just affect how the product looked. It made the product harder to scale, harder to build, and harder to evolve.

The temptation was to jump straight into a redesign. But the right first step was harder and less visible: Understand and bring structure to what already exists.

</aside>

Phase 1: Learning from the Existing System

Starting with Observation

Before anything could be improved, it had to be understood.

I started by auditing real product screens — capturing flows, edge cases, and variations across the app. Not to catalogue problems, but to understand the system as it actually existed, not as it was intended to exist.

This revealed three things: what patterns were already working, where inconsistencies were coming from, and what could realistically be standardized without breaking the existing experience.

But the audit surfaced something more important than a list of fixes.

<aside> 💡

Systems Don’t Work in Isolation

The deeper I went, the clearer it became: no component exists independently.

What looked like a typography problem was also a spacing problem. What looked like a color problem was also a hierarchy problem. Changing one element without accounting for its relationships created new inconsistencies somewhere else.

• Updating typography affected spacing and readability across every screen it touched
• Adjusting spacing shifted layout balance in ways that weren't always visible at component level
• Changing colors influenced hierarchy, contrast, and accessibility simultaneously

This shifted my entire approach — from fixing individual components to understanding the relationships between them.

Working on a single component in isolation wasn't just inefficient. It was misleading. The system had to be understood as a whole before any part of it could be confidently changed.

</aside>