Product design built in partnership with founders, engineers, and internal teams.
Design Systems
Services
A component library can be full of useful work and still be difficult to trust. Designers cannot tell which version to use, engineering maintains a different implementation, and every new feature introduces another exception.
Truesight develops design systems that connect reusable patterns with the guidance and ownership needed to keep them useful. We help teams standardize recurring decisions so they can spend more attention on the product problems that actually require new thinking.
01 // 05
Give teams a shared foundation for the decisions they keep making.
A design system is the shared foundation used to design and maintain an interface across features, products, or teams. It brings together visual foundations, reusable components, interaction patterns, documentation, and a way to manage change. Its usefulness depends on how well those parts reflect the work people are actually doing.
The need often appears as delivery expands. Several designers solve the same pattern differently, product areas drift apart, or a library created for an earlier release no longer matches the live experience. A merger, rebrand, or new product family can make those differences harder to manage. The organization may have plenty of reusable assets without a reliable system for choosing, applying, and improving them.
We build or consolidate the agreed foundations, components, and guidance around priority product needs. Existing discovery can inform the scope, and collaboration with engineering helps connect design decisions to implementation. Production code components can be included when expressly scoped; a design library alone should not be presented as an adopted, fully implemented system.
Duration
6–10 weeks
Engagement
Team size
Founder to Enterprise
Focus
Reusable Components + Design Operations
02 // 05
A shared library helps only when teams know they can rely on it.
A designer selects a component from the library, changes it to fit a new state, and saves the result locally. Another team encounters the same need and creates its own version. Engineering already has a working pattern, but its options and naming differ from the design file. By the next release, there are several answers to a question the organization believed it had standardized.
The cost appears throughout delivery. Reviews catch the same spacing, hierarchy, and interaction differences repeatedly. Developers have to ask which version reflects the intended behavior. A small change to a shared pattern becomes difficult to coordinate because no one knows where it is used or who can approve the update. New team members learn exceptions by encountering them in unfinished work.
Replacing the library will not resolve the issue unless the system also explains use, ownership, and change. Teams need components that cover real states, documentation that answers practical questions, and a clear route for needs the system does not yet support. Otherwise, local workarounds remain easier than contributing to the shared foundation.
03 // 05
Build the reusable parts around real work, then define how they stay useful.
We establish the system's initial scope from the products, patterns, and delivery problems that matter most. We review existing assets with design and engineering, identify what should be retained, and agree which recurring decisions belong in the shared foundation. The first release is sized for use and adoption rather than an exhaustive library that takes months to reach a product team.
We develop the foundations, components, and guidance together, applying them to representative screens to expose missing states or awkward rules. Alongside the design work, we define contribution, review, and ownership practices that fit the organization. The handoff includes an adoption sequence and implementation priorities so the team knows how the system should move from a design file into daily delivery.
Design Tokens & Visual Foundations
Define shared values and rules for color, typography, spacing, and other recurring visual decisions. Organize them so design and engineering can apply changes with a common understanding of their purpose.
Reusable Component & Pattern Libraries
Create components, variants, and interaction patterns for the agreed product scope. Include the states and combinations needed for representative workflows rather than only idealized examples.
Design System Documentation & Governance
Document when to use each pattern, where its limits are, and how changes are proposed and reviewed. Establish ownership and contribution guidance suited to the teams maintaining the system.
Design-to-Code Alignment & Adoption
Map design components to implementation needs and define a practical rollout sequence. Coordinate with engineering on naming, behavior, and review, with code component delivery included only where agreed.
“I've watched Garrhet's work develop over the years, and his ability to keep learning has always impressed me. He's constantly experimenting with new tools and approaches, and you can see that reflected in the quality of what he produces. He has a great eye for design, but he also understands how technology can make the finished product better. He's the kind of creative you want on your team.”
05 // 05
Teams can spend less time rebuilding the familiar parts of the product.
Routine interface work has a more dependable starting point. Designers can select patterns with a clearer understanding of their behavior and limits. Engineers can see how those choices relate to the implementation, and reviewers have an agreed reference for common decisions. Reuse becomes more practical because the shared components account for the states and constraints people encounter in actual work.
Coordination improves when the system has clear owners and a route for change. A new requirement can become a deliberate contribution rather than another private variation. Documentation gives new employees and collaborators somewhere to look before interrupting the person who remembers the history. The system cannot remove every discussion, but it can keep familiar questions from consuming the same attention release after release.
As adoption grows, the organization gains a more manageable way to keep experiences consistent and improve shared patterns. Changes can be planned against known dependencies instead of rediscovered separately across product areas. That value depends on implementation, maintenance, and continued use; a library left outside the delivery process will not produce it. A useful system makes those responsibilities explicit and gives teams a practical foundation to maintain together.
Build a system your team can use on the next release.
Start with the recurring patterns and delivery friction your teams already know. We will help define a useful first scope, build the shared foundation, and establish how it should be adopted and maintained.
Single Projects
Focused work with a defined outcome.
For organizations that need to solve a specific problem, build something new, or move an important initiative across the finish line.
For organizations that need to solve a specific problem, build something new, or move an important initiative across the finish line.
Starting at
$15,000
Defined scope
Clear project outcome
Senior-led strategy and design
Documentation and handoff
Ongoing Sprints
Senior-level support that stays with the work.
For organizations with evolving priorities that need ongoing strategy, design, development, creative leadership, or implementation capacity.
For organizations with evolving priorities that need ongoing strategy, design, development, creative leadership, or implementation capacity.
Starting at
Reserved Truesight capacity
Ongoing prioritization
Senior creative direction
Flexible related workstreams