Role
Frontend Developer, Head of Design, Principal Designer
Year
2024
Client
Design & Component System
Industry
Field Services Management, HVAC, Partner Services
Team
Skills

ACDocs Design System

SmartAC Design, Component and Document System

Figma Files

As I started at SmartAC, there was already really high bar of quality set for design. Whether it was the various apps, dashboards or the consumer homepage, the design aesthetic was top notch. Beneath all of that gorgeous design, however, was a sea of untamed chaotic waters. Frame 371891. Group 52. Pages with ambiguous names. Commonplace when design languages are being figured out, lack of organization in the systems is usually considered a "nice to have." Something that keeps getting punted until someone has time to fix it.

But, when you're working on building products at the fast-clip needed to support a rocketship startup like SmartAC, the daily work always takes more precedence.

I'll be honest that I didn't have the magic answer immediately. Partly because of the aforementioned daily work needs of a busy company. Also due to the sheer high-volume of illustrations, disparate designs, experiments and visual language that was available. What needed to stick around? What would I sunset to make way for new visual language concepts that fit the products ever growing needs. Finding the right place to start the clean-up, consolidation, and ultimate refreshing and consolidation of the product components was my first focus.

Navigating Figma

What made the most sense was starting at what would make the most impact - bringing order, organization, and consistency to the Figma files that were being used as governing documents for our product building. One thing that's always bugged me about file governance is when the documentation blends too seamlessly with the work itself.

Clear separation of disciplines with visual language makes it easy to recognize what is production-ready artwork vs elements that are meant to document the flow, journey, and communicate information to teams.

ACDocs was born from this. Manrope was the new font I was bringing into the SmartAC product proper, but ACDocs utilized Roboto Mono instead. A clear differentiator, using a monospaced font to further indicate its technical usage.

Throughout Figma files, we are constantly making notes, checklists, explanations, and detail. To standardize, I created a pre-built set of elements, cards, diagram components,tags and similar that were then used in a consistent, repeatable manner. A big part of my role was not only to create these items or set-up the system, but making sure implementation was adopted.

ACDocs Road Signs

ACDocs Info Cards & Lists

ACDocs Figma Thumbnail Covers for File Status

ACDocs Figma User Story Headers with Status

Putting it Together

The goal isn’t just to show a single screen. We show the whole story. Give the full context. Every user story gets its own dedicated frame, with a consistent structure that makes it easy for anyone on the team to jump in and understand what’s happening. At the top, we lock in the details: the theme, the epic, the manager, platform, and status. That way, no matter how far down the design flow you are, the context is always right there.

Instead of burying explanations in a separate doc, we annotate directly in the file. Yellow tags highlight what each section means: title, storynumber, user story, demos, new designs and the deep explanation of a user's journey through the project.

This makes the file itself a hub for truth. If someone wants to see the original platform story, there’s a link right there. Understanding the motivation behind the actions helps stakeholders and others recognize the patterns and decisions.

Prototypes get their own space because of how critical they are to the final product. A static screen only tells you what something looks like, but a prototype shows how it behaves. That’s the heart of user experience. Every story includes direct access to scenario demos and full flows, so anyone can actually click through and feel how the pieces fit together. This ensures engineers, stakeholders, and designers all share the same understanding of not just what we’re building, but *how* it needs to work.

This system also doubles as a walkthrough tool. By pointing directly to flows like “Review & Save” or “Add Thermostat Zone,” we’re able to show not just the final screen, but the decision-making path. It’s built to scale: the more complex the system gets, the more valuable it is to keep everything in one visual narrative. Instead of chasing scattered tickets and design explorations, anyone can step into the Figma file and see the complete story in one place.

Color & Theme

Colors are the foundation of any designsystem. SmartAC's product had to work two-fold: as its own brand and be excellent for white-labeling. A built-in, cost-effect white-labeled app in every customer's pocket a primary benefit of the SmartAC system. My duty was to make sure every partner brand felt as great as SmartAC's.

Every brand has a primary color. That color has a HUE value. The rest is simple:

  • Take the Brand HUE
  • Swap it with the Generic Theme's HUE
  • If Light Mode, make S:7
  • If Dark Mode, make S:15
  • Keep the Generic Theme's LUMINANCE the same
  • H:0 S:0 L:56 now becomes H:220 S:7 L:56

Our Component System was built on ShadCN/Radix UI, which uses -named colors throughout the UI. By mapping those named colors to our values, I created a clean, scalable, white-labeling powerhouse.

Why does all this matter? SmartAC was a brand that had multiple-levels of hierarchy. That quickly creates box-within-box problems which clutter the UI. Everything feels busy, even if it's not. By making these differentiations subtle, we get the benefit of hierarchy, without all the noise. When dealing with lots of information, that matters.

Copyright 2026 Q Manning • Built in Austin, TX