Houston Design System

I built Eduzz's Houston Design System from the ground up — tokens, components, and the build standard for product teams.

DeliveryJuly 2022
ClientEduzz
RoleUI Designer
Duration12 months

Context

Eduzz is a full platform for monetizing knowledge, with products spanning online course creation (Nutror), business management (Orbita), ticket sales (Blinket), checkout (Checkout Sun), and community (Space).

The portfolio grew fast, and design didn't keep up with structure. For a company selling digital products, a fragmented experience across platforms isn't aesthetic noise — it's a trust problem. Giving design a foundation became a condition for scaling without multiplying the chaos.

Problem

Each product made design decisions in isolation. Without a single source of truth, every delivery started from scratch.

The base was Google's Material Design, hardcoded straight into the codebase, with no tokens or reuse across teams.

  • Hand-coded components, generating variations even within the same product.
  • Divergent iconography across platforms, with no criteria.
  • Users felt like they were in different products from the same company.
  • The business carried constant rework and stalled scale.

Process

In the early phases, decisions were made together with design leadership. From the architecture stage on, I acted as UI Designer, focused on building the design system itself: it was on me to decide the structure and validate every contribution.

Diagnosis

Before creating components, I mapped the state of each product: what already existed and where there was only hardcode. This guided where to start.

Principles

I defined the principles (simplicity, consistency, evidence) and organized the system into layers: tokens, components, documentation.

Foundation

I defined the color, spacing, and typography that support the tokens. I also decided to create a proprietary icon library.

Components

I designed the components in order of impact on the product: first the ones used most day-to-day, then the ones with the greatest technical complexity.

Handoff

Every finished component went through a structured handoff to the dev team: behavior, states, and usage documented before any code.

Test

Once coded, the design team tested each component: behavior and states. Adjustments happened before publication.

Solution

The answer was a layered system — tokens, components, documentation, iconography, and navigation — sustaining coherence across the whole platform.

Layered architecture

Map of Houston's documentation, organized into four major layers.

a. Foundations

  • a1. About Houston DS
  • a2. Architecture
  • a3. Tokens
  • a4. Grid

b. Libraries

  • b1. Icons
  • b2. Illustrations
  • b3. Core components
  • b4. Templates
  • b5. Help components
  • b6. Team components

c. Handoff

  • c1. Core components
  • c2. Team components

d. Others

  • d1. Zeroheight
  • d2. Github

Tokens as foundation

Each product had its own variations of color, typography, and spacing — some deliberate, others accumulated hardcode. Organizing this base was one of the most complex parts of the project: generic enough to serve everyone, specific enough to preserve each product's identity.

Tokens don't show up on screen, and the team wanted to see components first. I prioritized them anyway: without this foundation, every color or typography adjustment would turn into find-and-replace across dozens of files.

  • Color
  • Typography
  • Spacing (squish and stack)
  • Border
  • Shadow
  • Opacity

50+ components

I followed the atomic design order: atoms first — button, field, icon — then molecules combining them, and only then more complex organisms.

Icon governance

With several designers contributing, standardizing required process. I created an iconography manual in Notion — grid, stroke, and proportion — and ran an immersion workshop.

Ver o recorte do manual de iconografia →

Illustration library

A curated bank of illustrations, customized to each product's color. Used in error screens, empty states, and other supporting moments, like onboarding.

Writing guide

Each product wrote errors, success messages, or tooltips its own way. The writing guide extended the same governance from icons to words: brand tone of voice and a microcopy standard per component type — error and success messages, buttons, labels, tooltips, toasts, dialogs.

Documentation

All design documentation lived in Zeroheight — usage rules, anatomy, content. A component was only "done" once published on Github and documented in Zeroheight.

Figma
Github
Notion
Zeroheight

Rollout and adoption

Adoption doesn't come bundled with documentation. It took bringing the system to the team: teaching its use and following up on day-to-day application.

Workshops with the design team, accessible documentation, and active presence in reviews to validate the application of the standards.

In Figma, onboarding was hands-on: I showed how to consume the library's components and how to create team components when a product had a need the core didn't cover.

Results

Despite the results it had been delivering, the company's new leadership chose to discontinue Houston, adopting a different direction. During iterations with the designers and developers who used the system, we reached numbers worth recording:

  • 7 Products adopted the system
  • −30% Handoff time
  • −25% Prototyping tasks
  • +30% Screen development
  • 2 days Front-end for a POC

Growing a product with no design foundation?

Tell me the context — design system, tokens, or your first component library. Diagnosis comes before scope.

Send a message