Veriscouts is a San Francisco-based startup that helps people in the arts and entertainment industry discover, review, and connect with one another.
During my internship, I worked with the team to build Veriscouts’ first design system from the ground up. The goal was to create a shared product foundation that could make the interface more cohesive, reduce repeated work, and help the team design and build new features more efficiently.
As a UX/UI designer, I helped define the foundations, components, patterns, and documentation that made up the system.
My work included typography, color, spacing, elevation, icons, interaction states, and a reusable component library containing more than 250 components and variations. I also helped establish guidance around how those components should be used so the system could support real product work rather than becoming a very organized file that nobody opened again.
Veriscouts didn’t have a formal design system or shared source of truth.
Common components were recreated for different pages, similar interactions behaved differently across the product, and new features introduced additional visual decisions. As the platform expanded, every feature risked developing its own slightly different design language.
This created several problems:
The challenge wasn’t simply making the interface look more consistent. We needed a system that could support how the team actually worked.
We used Atomic Design as a framework for organizing the system, moving from foundational decisions into reusable components and larger product patterns.
The foundations defined the visual rules behind the interface:
Veriscouts served a creative audience, so the visual language needed to feel expressive without becoming unpredictable. Vibrant colors and gradients gave the brand personality, while consistent spacing, typography, and hierarchy kept the product structured and usable.
These foundations gave the team a shared set of decisions to build from instead of resolving the same visual questions every time a new screen was designed.
Once the foundations were established, I worked on reusable components for common interface needs, including:
Each component included relevant variants and interaction states rather than only showing its ideal appearance. This helped the library support the messier parts of real product design—disabled controls, validation, selected states, long content, and the many small conditions that appear once something is actually being used.
The resulting library contained more than 250 components and states that could be reused across different workflows.
The purpose wasn’t to create as many components as possible. It was to stop the team from solving the same interface problem several different ways.
A component library was only the beginning.
After establishing the core elements, we combined them into reusable patterns and templates for common product scenarios. These larger patterns gave the team a starting point for new flows and helped maintain consistency across related experiences.
The system was grounded in three principles:
The platform served a broad range of professionals across the arts and entertainment industry. The system needed to support different people, abilities, content types, and contexts.
The interface needed to feel clear and focused. Familiar patterns helped reduce unnecessary complexity and made the product easier to understand.
Repeated problems should have repeated solutions. Standardizing common interactions allowed users to build confidence as they moved through the platform.
These principles helped us evaluate decisions that couldn’t be resolved by a component alone.
A design system is only useful when people know how and when to use it.
I helped organize the system in a shared design file with guidance covering foundations, component behavior, variants, and common patterns. This gave designers, engineers, and product stakeholders a clearer reference point when discussing or building new features.
The documentation also helped explain the reasoning behind the system. Instead of only showing what a component looked like, it clarified how it should behave and where it belonged.
This created a more useful shared language between design and development and reduced the number of decisions that needed to be made from scratch.
The design system gave Veriscouts a more scalable foundation for future product work.
Designers could reuse established components when creating new flows, developers had clearer and more consistent interface references, and the product could evolve without introducing a new visual pattern every time a feature was added.
More importantly, the system connected individual design decisions into a larger product language. It helped the experience feel like one product rather than a collection of screens designed at different moments.
Building Veriscouts’ first design system taught me that a design system is not just a library of polished components. It is a product for the people designing and building the product.
The components matter, but so do the naming, documentation, flexibility, and team alignment around them. A system only creates value when people trust it enough to use it—and when it can continue evolving as the product changes.
Building the first version established the foundation. Making it understandable and useful was what turned that foundation into a working system.