Stark Tech
|
Shipped 2025
Defining the design system & UI style guide for a specialized engineering industry tool
This project shipped in July 2025 and is currently adopted by Stark Tech's engineering department 🎉
At Stark Tech, I built documentation defining the refreshed design system & team project workflow for an IoT building automation platform. This was a self-initiated project — I identified the gap, built the solution, and got it adopted company-wide after proposing it to management.
Role
Design System Documentation
UX Audit
Accessibility Compliance
TimeLine
1 month
Team
1 Programming Manager
1 Engineering Manager
~8-10 Software Engineers
Results Summary
The new standards covered ~10-15+ active BAS projects within weeks of its July 2025 adoption — reducing project turnaround times — and triggered 4 new company-wide initiatives launched by management to standardize cross-team communication and training.
Context
A fast-growing company outpacing its older processes
Stark Tech is an engineering company specializing in building automation systems (BAS) — IoT user interfaces that control building conditions like HVAC and lighting. Over the past couple of years, they have expanded their services across New York, Florida, New Jersey, and Pennsylvania.
The Orlando office became Stark's largest Florida office, with staff nearly doubling in size over a few years. But rapid growth brought a familiar problem: the company had scaled its headcount without scaling its processes. Teams operated in silos, workflows were undocumented, and there was no standardized approach to designing the interfaces their engineers built every day.
Problem
Engineers were designing UI with no resources — and it showed
Before I joined, Stark's programming team was responsible for both programming BAS system functions and designing the BAS interfaces — with no resources, training, or standards to guide them through either of them. The only way to learn was through trial & error in QA sessions with management.
This had significant consequences for Stark internally:
Inconsistent project quality
Slower project delivery times
Technicians catching more errors on-site, delaying equipment installations
New team members are forced to figure out everything on their own
Interfaces did not pass WCAG 2.1
Auditing existing interfaces revealed recurring accessibility issues:
Poor legibility for both text & graphics
For instance, this card’s contrast ratio is 3.99:1 for normal-sized text and 1:59:1 for smaller text. Neither pass WCAG 2.1 AA.
No clear sections for groups of technical data
Equipment summary screens grouped equipment data without any headings or labels, violating WCAG guidelines on structure.
Inconsistent navigation & screen names
On certain pages, labels on sidebar navigation & sidebar menus did not match.
Lack of context for abbreviations
Building floor plan screens used abbreviated room names with no visible context, legend, or glossary.
Desk Research
Looking at a screen in the bright sun
Apprentice technicians learning on the job
Getting injured on the job (e.g. broken arm, twisted ankle)
May have low vision, hearing loss, limited mobility, etc. due to aging
Inconsistency was a safety risk — not just a QA issue
Stark’s design & dev environment for BAS interfaces — Schneider Electric — directly links UI components to live HVAC functions. Inconsistent component use caused live display errors flagged by technicians on the field, delaying the programming team’s active projects. Left unresolved, these could snowball into critical equipment failures affecting room temperatures, air quality in occupied buildings, and more.
The interface where points are connected to design system components in Schneider Electric's dev environment
Define
Solution
UX audit of existing components
To address accessibility issues, I audited Stark’s existing component library against WCAG 2.1. As a result, I identified & resolved 7+ key accessibility issues across multiple design system components — from contrast ratios to menu navigation inconsistencies.
Design system refresh with expanded coverage
To ensure greater consistency, I applied targeted UI enhancements to existing components and created new ones where gaps existed. The refreshed design system expanded coverage to ~25+ components and introduced 7+ new UI templates for key BAS screens. This also included closely collaborating with one of the devs on the team to build & implement a new component for more complex BAS configurations.
Documentation built for engineers, not designers
When I joined Stark Tech, devs were forced to figure out building BAS interfaces on their own via trial & error in QA sessions. To remedy this, I authored documentation for devs to reference at any time they needed it. Standardized design token tools like Storybook were not available at Stark, so I built a SharePoint site to house everything.
Sample page from the documentation's final draft
Being the sole designer at a company that is predominantly engineers & trade workers, I intentionally written the documentation to be concise & easy to follow. It included:
A defined UI style guide covering foundations like fonts, colors, and spacing
Design system best practices & component specs
Accessible design basics & resources (e.g. the WebAIM contrast checker)
Step-by-step standard operating processes for building BAS interfaces
Worth noting: This was not an assigned project! I independently identified these issues and developed solutions on my own initiative before proposing them to management for formal adoption.
Results
Creating a new corporate trainer role
Implementing SOPs across our entire department (engineering)
Hiring a project coordinator to improve cross-team communications
Takeaways
Want to learn more?
I'd love to walk you through the full case study and talk more about my process over a call!