Trellis Design System

Cover image showing the account merge view screens that let the user know which is going to be the active account and which is going to be the inactive one.

Trellis Design System Journey

Transforming a fragmented platform into a cohesive experience

In a hurry? Here’s the TL;DR

Overview

Trellis Platforms is a private investment solution connecting startups and investors. Over time, the product expanded and desperately needed a scalable, accessible design system to streamline design and development efforts.

Duration

6 months

My Contribution

Sole design system designer

Create responsive components

Accessibility audits

Collaborators

2 Frontend Engineers

1 Product Manager

2 QA Engineers

Problem

Trellis grew from one portal to many, each evolving independently. This fragmentation slowed down design, burdened engineering, and diluted the brand.

A lack of standardization meant new features took longer to ship, and existing features looked inconsistent. Users grew confused, and designers wasted precious hours duplicating work or second-guessing guidelines.

Everything pointed to one solution. We needed a Design System.

What did I do?

Audited inconsistencies, defined design tokens, built Figma-based design foundations, and partnered with developers to create React Storybook components.

The Impact

30% faster development

Standardized, reusable React components along with detailed documentation.

Better consistency, faster changes

Consistent visual design portals and a quicker way to make design changes.

Increased design turnaround time

Reduction in design time for new features by eliminating redundant work.

WCAG 2.1 AA compliance

WCAG standards at every level ensured better compliance and a more inclusive experience.

Interested in reading more? Here’s a deeper dive...

Why build a design system instead of fixing existing components?

Consistency

The team needed a single source of truth that all 4 portals could inherit.

Efficiency

Designers spent too long recreating patterns, and devs rebuilt the same components in different ways.

Scalability

Trellis planned expanding to a V2 designs, so a foundational system ensured future features wouldn’t break the design.

Accessibility & Responsiveness

We baked in WCAG 2.2 AA compliance and responsive compoments from day one to serve a diverse user base.

My Process

1. Auditing existing designs

I began with a comprehensive inventory of Trellis's interface elements across all four portals—Issuer, Fiduciary, Digital Locker, and the Admin Portal.

Through this audit I:

• Cataloged 34 instances of the same UI element being used differently across different portals.

• Identified 12 different button styles with inconsistent states.

• Mapped 15 different typography styles for headings and body content.

This audit was my evidence to leadership that a design system wasn't just nice-to-have - it was business critical.

Image of inconsistent buttons found in the Trellis

Inconsistencies in the form headers found on various Trellis portals.

2. Understanding team needs

I started by gathering team pain points. Speaking to the engineers, I realized that there is no one source of truth when it comes to referencing design components during development.

I realized while creating designs for different portals, UI elements were being duplicated and changed as needed and developers were unsure which components to reuse.

This also meant wasted efforts designing components every time without consistency in their designs.

3. Not reinventing the wheel.

Rather than starting from scratch, I chose to build our new design system using Material UI as the foundation. It allowing me to leverage proven components while customizing for Trellis's unique needs.

I established:

• A semantic color system derived from brand colors but optimized for digital interfaces and accessibility

• Typography scales based on responsive principles (16px base with modular scaling).

• Spacing tokens using an 8px grid system for consistent rhythm throughout interfaces

Image of the variables panel in Figma that shows all the different variables that I organized as a part of the design system work.

The different typography styles that are a part of the new design system.

4. Component Creation

Following Atomic Design methodology, I built the system layer by layer:

Atoms: Semantic colors, typography scales, spacing values, and icons established our most basic building blocks. 
‍
Molecules: Reusable form fields, button sets, and label-input combos tailored for Trellis branding. 
‍
Organisms: Larger UI segments like cards, nav bars, and complex tables for each portal’s unique needs. 
‍
Documentation: Pattern usage “dos and don’ts,” accessibility notes, and responsive design rules for each component.

For each component, I defined responsive behaviors for mobile, tablet, and desktop breakpoints, ensuring a seamless experience regardless of device.

Shows the atomic design principles used to make the design system.

5. Bridging the design to development gap

I didn't just design components, I made sure they were built to specification and had accompanying documentation for designers and engineers.

I worked with engineers to translate designs into React components in Storybook. We established naming conventions that aligned between both design and code.

The entire design system development process was done in an Agile manner with Jira workflows set up to track current design status, component development and QA.

Documentation for the Forms as a part of the new design system

Documentation for lists, and labels in the new design system.

Impact and Takeaways

Impact

Accelerated development time

React Storybook components cut build time and reduced guesswork, boosting dev productivity.

Improved product team experience

Designers no longer hunted for the right color or button style, and developers had instant clarity on usage.

Accessibility Gains

WCAG standards at every level ensured better compliance and a more inclusive experience.

Project Takeaways

Developer experience is user experience

By focusing on making the system intuitive for engineers, I ensured higher adoption and implementation quality.

Documentation is never done

I continue to refine our guidelines based on team feedback and new use cases.

Timing matters

By building the system when we did—after experiencing real pain points but before scaling further—we created something truly useful rather than theoretical.

Other projects