Inconsistent UI
The same "energy generated" figure used three fonts, two units (kWh vs MWh) and different colours for "up".
Who feels it: homeowners and operators comparing numbers
HelioNova builds products for two very different audiences: families watching their rooftop solar, and engineers running wind and solar parks. I designed the shared design system behind both, with foundations, 28 accessible components and copy-paste HTML that works in any framework.
Overview
HelioNova’s products had grown separately. The customer app, the installer portal and the operations console each had their own buttons, greens and chart styles, and the same "energy generated" number looked different in every one.
The goal was one system that feels warm and simple for homeowners, is precise enough for grid engineers, and is easy for any team to adopt without a framework migration.
The challenge
HelioNova had three products built by three teams over four years: the customer app (homeowners tracking rooftop solar and savings), the installer portal (surveys, quotes and installs) and the operations console (engineers monitoring wind and solar parks). Each grew its own UI. A UI audit of 140 screens found the same patterns rebuilt again and again, and the inconsistency was now costing time, trust and accessibility.
Designers and developers across HelioNova have no shared foundations or components. Every team recreates buttons, tables and metric cards in its own framework, so the same energy data looks and behaves differently in each product. This slows delivery, confuses customers who use more than one product, and leaves accessibility gaps that block public-sector and utility contracts.
The same "energy generated" figure used three fonts, two units (kWh vs MWh) and different colours for "up".
Who feels it: homeowners and operators comparing numbers
Each new feature rebuilt its own modal, table and metric card. Roughly a third of front-end effort went on UI that already existed elsewhere.
Who feels it: designers, developers, product managers
Status shown by colour alone, missing focus states, and a dark mode that failed WCAG contrast. This blocked tenders that require AA.
Who feels it: users with low vision, sales and compliance
React, Angular and server-rendered pages meant a React-only library would leave two of three teams behind.
Who feels it: engineering leads planning migrations
Design files, code and brand guidelines disagreed. Nobody could say which version of a component was "correct".
Who feels it: new joiners, QA, brand team
Customers saw different savings figures in the app and in emails, which drove support calls and doubts about the product.
Who feels it: customers, support team
How might we give every HelioNova team one shared language for building energy products, one that works in any framework, meets WCAG 2.1 AA in light and dark, and makes energy numbers look the same everywhere?
Approach
Design process
Inventory of every UI pattern
Principles, tokens and naming
Components, variants and states
HTML and CSS with live docs
Contribution, versioning and adoption
Users
Two groups use the design system directly, and two more benefit from it through the products built with it.
Principles
Calm surfaces and a nature-inspired palette, so the data is what stands out.
One way to show kWh, MW and savings, with units and change always labelled.
AA contrast in both themes, visible focus, and never colour alone for status.
Plain HTML and CSS with tokens, so any team can adopt it today.
Foundations
Each scale has ten steps. Components never use raw hex values; they use semantic tokens such as --hn-primary and --hn-danger, which switch automatically in dark mode.
Foundations
Sora gives headings and numbers a confident, geometric voice; Public Sans keeps long reading comfortable. Spacing follows a 4-point scale with four corner radii.
12.4 MWh generated today
Your rooftop panels covered 82% of this month’s bill. Here is how that compares with last year.
Components
The audit showed these 28 components covered most of the screens across all three products, including one built only for HelioNova: the energy stat card.
Documentation
Every component page follows the same structure, so once people learn one page they know them all.
One sentence on what it is for, in plain language.
Variants and states rendered as real, interactive HTML.
Copyable markup with a one-click copy button.
When to use it, and when to reach for something else.
Keyboard behaviour, ARIA roles and focus notes.
Accessibility
Low-fidelity wireframes
Each page was wireframed in greyscale first, with the same regions as the final site. On mobile the sidebar collapses behind a menu button, card grids stack into one column, colour scales wrap into two rows, and data tables turn into cards.
Desktop · 9 pages
Mobile · 8 pages
High-fidelity · interactive
Each frame below is the real documentation site, not a screenshot. Click components, switch tabs and copy code. Use "Open full screen" to explore a page at full size.
The front door
Opens with the brand promise and three facts, then lets people choose foundations or components. Everything starts here.
Foundations
Five scales named after nature (Canopy, Helio, Sky, Slate, Ember), each mapped to semantic tokens so teams never pick raw hex values.
Browse
All 28 components in a grid of live previews, so people find what they need by recognising it.
Component page
Each component page follows one template: variants and states as live examples, the HTML to copy, and accessibility notes.
Domain component
A component unique to HelioNova: a headline metric with unit, change and a small trend line, for generation and savings dashboards.
Mobile · live
Developers check the system on their phones in stand-ups and site visits, so it is fully responsive. The sidebar moves behind a menu button, card grids stack, tables become cards, and every component example stays live and tappable. Eight key pages are shown below.
Governance
Success metrics
The share of screens across the three products built with HelioNova components.
Time from design to shipped feature, before and after adoption.
One-off colours and components remaining in each product audit.
Contrast and keyboard issues found in QA, per release.
My role
I owned the system end to end: the UI audit, principles, colour, type and spacing foundations, all 28 components and their states, the documentation site, and the accessibility checks, building it with AI-assisted tools.
Closing
Questions or feedback? I’d love to hear them: yogeshmalikbe@gmail.com