Intro

When I joined Paperless Parts--a cloud-based manufacturing-quoting SaaS startup--as employee #30 in December 2020, its platform’s design was deeply inconsistent. Despite the Paperless Parts platform existing for three years, all UI design was entirely bespoke: Engineers designed interfaces as they built them; their single designer--the director of design--was stretched thin; and with uncertain runway for the company, the 10 Engineers were reasonably hesitant to slow development for design consistency.

However, the platform’s users--estimators at job shop manufacturers--are not digital natives, and thus need simple, clear and consistent UI to effectively use technology. Without that, the company was having trouble scaling platform training--so the organization was hungry for design consistency.

Throughout 2021, I founded, designed, and built Paperless Parts’ Cube Design System that now empowers a 30+ member R&D team at an 150+ member organization to independently and efficiently create highly consistent user interfaces.

Core principles

Design systems are “sets of standards to manage design at scale by reducing redundancy while creating a shared language and visual consistency across different pages and channels” - Nielsen Norman Group

Companies at Paperless Parts’ scale at the time very rarely adopt design systems, because they’re expensive to create, maintain, and adopt while the team needs to move quickly; but they clearly needed design consistency to scale platform training and adoption, so I sought out principles for a system at their scale.

After extensive research, team interviews, and battle-testing with use, I established the following:

Reduce complexity to minimize decision paralysis

With a small team and limited design resources, designers need to be autonomous and work quickly, spending minimal time on decisions to maximize their output.

To encourage this, I promoted:

  1. Using simple rules until they fail, then expanding them when they do.
    Designers should never have to second guess which elements to use or where to place them, which necessitates defining sweeping, definitive rules. Attempting to bend interfaces to existing rules before broadening the ruleset reduces a designer’s decision space, ensures design-team-wide consistent output, and limits expansion of UI complexity in the system.
  2. Never inventing UI or interaction patterns.
    In 2021 and beyond, cross-platform web application design principles have already been solidified by tech giants and consumed by millions of users over the last 10+ years; so by re-using patterns users have seen before (and never inventing new ones), you ensure lightning-fast UI comprehension and adoption. This has been especially helpful for their user base of digital immigrants: by matching behavior patterns of the few other web platforms they use, like Microsoft Teams and OneDrive, we help them build on their previous experiences to understand the platform and help them transition to the digital world.
  3. Sacrificing aesthetic UI for UX consistency.
    As artists, designers often get stuck seeking the perfect visual expression for a single feature and lose sight of the larger goal of platform-wide UX consistency. In PaperlessParts' design system, creating UI with standardized information architecture and elements comes before attempting to hone the UI’s visual style-- a practice that is maintained to date as the team builds towards platform-wide system adoption.

Ensure engineers’ needs are met

Design systems should meet engineers' needs because they’re the system’s largest consumer group, and their bespoke work during development makes them effectively designers.

Through research and interviews of the engineering team, I identified:

  1. Components are key to design-consistent development.
    Fullstack developers dislike spending time on CSS because it’s cumbersome, repetitive, and requires extensive background knowledge. Because components--reusable, pre-styled interactive elements--are standardized across interfaces and composable, designers and engineers can use them to quickly create highly consistent interfaces and work in the same “language”.
  2. Committing to patterns turns Engineers into Designers.
    Engineers are capable of producing polished, on-design-spec work without designer input if they have existing interfaces to rely on to understand UI patterns. I recommended we initially commit to uniformly using simple patterns, even at the cost of a perfect UI, so that Engineers can quickly build a library of UI patterns to depend on.
  3. Accessibility should be baked in.
    Accessible web development requires extensive background knowledge often held only by tech-savvy designers, not developers, and as such was difficult to justify prioritizing in fast-paced development. To drive consistent accessibility, we’d need to bake accessibility into our component library to make it automatic.

Be flexible with adoption

Designers and engineers inherently have different priorities. Designers seek perfection for the user experience in every feature, while engineers seek efficient, scalable implementation solutions to deliver many features quickly. However, both groups share a common goal: deliver valuable features that benefit users and help scale the company.

In service of this, I opted to be highly flexible with Engineering adoption of our system, and encourage the following practices to get to platform-wide system adoption:

  1. Modifications to existing interfaces should update to system component usage when within scope.
  2. Major additions to existing features should include an on-spec full UI refresh when within scope.
  3. All new interfaces should be completely on-design-spec.

These practices have proven extremely effective at growing system usage over time, with Engineers now seeking the design team out with UI refresh opportunities that fit within their work.

Commit now, expect change later

Designers can be hesitant to adopt design systems early because they don’t want to commit to UI patterns or visual styling that may become outdated, preferring to plan a system out and validate it before use.

While I understand this fear, I firmly believe the only way to build a design system without an oversized investment is organically, design by design. Committing to any UI patterns, standardized elements, and uniform colors is better than none; and the act of committing to a pattern and pushing it until it breaks forces you to discover additional system rules as you build--deriving innovation from constraints.

Additionally, welcoming and preparing for inevitable future changes inspired my implementation that allows for on-demand instantaneous global style changes.

Key innovations

In order to achieve my intended principles, I needed the elements of our system (colors, typography, and components) to:

  1. Be few in number, to reduce the creative decision space and minimize decision paralysis
  2. Have sweeping, definitive rules for their intended usage, so we’d derive innovation from constraints
  3. Have a simple developer experience with built-in accessibility to encourage adoption
  4. Enable us to quickly evolve our visual style in step with our brand in the future

These needs inspired the following innovations:

Semantic theme system

Design systems commonly use a palette approach to theme (color, typography, shadows and more used by components and interfaces), offering a wide selection of values to draw from without prescribing how they’re used (i.e. color swatches with a range of saturation values for each). This works well at large companies with well-documented rules and a UI review process, but fails at smaller organizations where a palette’s abundant flexibility and designer autonomy results in inconsistent interfaces and designer decision paralysis.

For our small scale, I was inspired by a portion of Material UI to build a semantic color system, where a minimal set of well-categorized colors with distinct allowed UI roles dictate each element’s color.

Our semantic colors alongside examples of how they're used.

I intentionally limited our color set to a small palette to reduce our designers’ decision space, prevent a spiring increase in system complexity, and ensure team-wide consistent output. I also applied the same semantic system to our typography and shadows, and built that theme into our design software and code component libraries.

Centralizing our theme and styling elements based on their UI role enables global style control, allowing us to instantaneously adapt our visual style in step with our brand. It also allows us to quickly build alternate themes, such as dark mode or high-contrast for accessibility.

A prototype dark mode theme applied to our build-a-quote page, made possible by our semantic theme.

Theme-driven component library

To deliver on the promises of our principles and implement our theme, I built two parallel component (standard UI elements that are composed into interfaces) libraries in Figma (for designers) and in our React codebase (for developers).

Each library draws directly from our theme, enabling its intended global style control and alternate theme capabilities. Parity between both libraries ensures developers can recreate mockups 1:1 in our codebase and quickly access component code documentation from mocks.

I build our code library on top of Chakra-UI, a powerful component system and CSS-in-JS solution that unlocked two benefits:

  1. Global component style control
    Chakra-UI’s advanced theming allows designers to quickly add or manipulate the available sizes, variants, and color schemes for components separately from their core functionality, enabling us to instantly change component styling platform-wide.
  2. Ensuring elements are styled by role for our semantic theme
    Chakra-UI’s CSS-in-JS solution allows developers to use theme tokens for colors, typography, shadows, spacing, and more--ensuring interface elements are style by role and enabling the benefits of our semantic theme system. Offering prefab spacing values also helped enforce adoption of the 8-pt grid.

To see the entire code library, visit its documentation at storybook.paperlessparts.com.

Results

Since the system’s inception in early 2021, the company has grown 5x, and the R&D team has grown from 11 to 30+, with three designers across three product pods. Thanks to the system, patience, and collaboration with engineers, the product definition process is now design-centered, with Designers and Engineers working in lockstep to ensure system-compliant development.

New designers have cited the system as being extremely comprehensive while maintaining simplicity, while new engineers are impressed by the completeness and ease-of-use of the component library. Both groups use the system enthusiastically, and the team continues to grow both the component library and design system rules as we learn more.