Stark Tech
|
Shipped 2025
Defining the design standards for a specialized engineering industry tool
This project shipped in July 2025 and is currently adopted by Stark Tech's engineering department 🎉
Role
UI Developer & Design Lead
TimeLine
1 month
Team
1 Programming Manager
1 Engineering Manager
~8-10 Software Engineers
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 issues, built the solution, and got it adopted company-wide after proposing it to my supervisors!
After leaving Stark, I spent 8 months at Deloitte designing user interfaces for state & federal government clients. While I cannot share my Deloitte work and design processes, my time there reinforced the importance of web accessibility and design systems in the UX space. Hence, this case study mirrors a lot of the same design approach I've had at Deloitte (albeit a different tool stack).
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.
~25+
Components standardized
7+
New UI Templates Created
~10-15
Active BAS projects covered by new standards within weeks of adoption
4
Company-wide initiatives launched
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
Growing pains, lasting consequences
01
Engineers were designing UI with no resources — and it showed
Inconsistent project quality
Slower project delivery times
Technicians catching more errors on-site, delaying equipment installations
New team members forced to figure out everything on their own
02
UI did not pass WCAG 2.1
Existing UI components created by the programming team revealed recurring accessibility issues:
Desk Research
Looking at a screen in the bright sun
Apprentices learning on the job
Getting injured on the job (e.g. broken arm, twisted ankle)
May have low vision, hearing loss, limited mobility, etc. that could affect their ability to work
03
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
How might we improve cross-team communication, increase project efficiency, and reduce display errors — without overwhelming a team of engineers whose primary job isn’t design?
Solution
Building standards that stuck
01
Design system refresh with expanded coverage
To ensure greater design system consistency, I enhanced existing components and created new ones to address accessibility & consistency issues. The refreshed design system expanded coverage to ~25+ components and introduced 7+ new UI templates for key BAS screens, including resolving 7+ key accessibility issues.
I also worked closely with one of the devs on the programming team to build & implement a new component for more complex BAS interface projects. The goal here was to fix the components in ways the programming team can maintain & replicate them without ongoing designer support.
02
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.
There was a tradeoff, however: Standard design system documentation platforms like Storybook were not available at Stark. I explored whether to push for adopting a dedicated design tool, but this was a significant detour for an engineering team that was already stretched thin across multiple projects.
Sample page from the documentation's final draft
With this constraint in mind, I chose to build a SharePoint site since Microsoft SharePoint was already adopted company-wide. Using software that was already adopted meant higher likelihood of the documentation actually getting used.
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
Note: 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
A self-initiated project that triggered company-wide changes
01
Creating a new corporate trainer role
Implementing SOPs across our entire department (engineering)
Hiring a project coordinator to improve cross-team communications
02
03
04
Takeaways
Want to learn more?
I'd love to talk more about my design process over a call!