Helion by Helios Nexus
Helion by Helios Nexus is a SaaS for solar-energy companies to manage leads, proposals, installations, and inventory in one place. I joined early, when the product was still an idea and the founder was shifting direction - from selling solar installations directly to homeowners to building a tool for the companies that handle those installations.
Product Design
Design System
Timeline: 2024 to 2025
My role focused on UX and UI design, as well as creating the design system used throughout the product. I worked directly with the founder to translate his research and workflows into a structured interface that could support everything from sales to operations.
Over four months, we moved the product from a rough concept to a fully designed MVP, preparing it for development and investor demos.
My role focused on UX and UI design, as well as creating the design system used throughout the product. I worked directly with the founder to translate his research and workflows into a structured interface that could support everything from sales to operations.
Over four months, we moved the product from a rough concept to a fully designed MVP, preparing it for development and investor demos.
My role focused on UX and UI design, as well as creating the design system used throughout the product. I worked directly with the founder to translate his research and workflows into a structured interface that could support everything from sales to operations.
Over four months, we moved the product from a rough concept to a fully designed MVP, preparing it for development and investor demos.
The Challenge
When I joined, the founder had a clear vision but no unified structure for how the product would work. Solar companies today rely on separate tools to manage leads, generate proposals, track installations, and monitor inventory. Each team use their own system - separate applications, spreadsheets, PDFs, and chat threads - which created delays, duplicate data, and limited visibility across departments.
Our goal was to bring everything into one platform. We needed to design a system that could handle the complexity of solar operations without feeling heavy or disjointed. It had to be something a small local installer could use easily, but that could also scale for larger companies with multiple teams and ongoing projects.
The Challenge
When I joined, the founder had a clear vision but no unified structure for how the product would work. Solar companies today rely on separate tools to manage leads, generate proposals, track installations, and monitor inventory. Each team use their own system - separate applications, spreadsheets, PDFs, and chat threads - which created delays, duplicate data, and limited visibility across departments.
Our goal was to bring everything into one platform. We needed to design a system that could handle the complexity of solar operations without feeling heavy or disjointed. It had to be something a small local installer could use easily, but that could also scale for larger companies with multiple teams and ongoing projects.
The Challenge
When I joined, the founder had a clear vision but no unified structure for how the product would work. Solar companies today rely on separate tools to manage leads, generate proposals, track installations, and monitor inventory. Each team use their own system - separate applications, spreadsheets, PDFs, and chat threads - which created delays, duplicate data, and limited visibility across departments.
Our goal was to bring everything into one platform. We needed to design a system that could handle the complexity of solar operations without feeling heavy or disjointed. It had to be something a small local installer could use easily, but that could also scale for larger companies with multiple teams and ongoing projects.
Approach
We started with discovery. The founder had already collected feedback from dozens of independent solar sales representatives and solar companies, so my first step was to map their workflows and identify where information was getting lost between tools. Most of the friction came from handoffs - sales to operations, operations to installation, and installation to inventory.
I outlined four core modules that would define the platform: Leads, Proposals, Installations, and Inventory. Together, they formed a simple, repeatable loop that could scale to any company size.
I drew the initial wireframes around those workflows and then focused on creating a design system in Figma to keep elements consistent. The system covered typography, colors, layout spacing, and reusable components for tables, cards, filters, and boards. With those foundations in place, I could move quickly - every new screen used the same structure, so the interface felt predictable from the start.
I worked in short cycles, meeting every two weeks to review progress and adjust priorities. Most feedback came directly through Figma comments, keeping iteration fast and lightweight.
Approach
We started with discovery. The founder had already collected feedback from dozens of independent solar sales representatives and solar companies, so my first step was to map their workflows and identify where information was getting lost between tools. Most of the friction came from handoffs - sales to operations, operations to installation, and installation to inventory.
I outlined four core modules that would define the platform: Leads, Proposals, Installations, and Inventory. Together, they formed a simple, repeatable loop that could scale to any company size.
I drew the initial wireframes around those workflows and then focused on creating a design system in Figma to keep elements consistent. The system covered typography, colors, layout spacing, and reusable components for tables, cards, filters, and boards. With those foundations in place, I could move quickly - every new screen used the same structure, so the interface felt predictable from the start.
I worked in short cycles, meeting every two weeks to review progress and adjust priorities. Most feedback came directly through Figma comments, keeping iteration fast and lightweight.
Approach
We started with discovery. The founder had already collected feedback from dozens of independent solar sales representatives and solar companies, so my first step was to map their workflows and identify where information was getting lost between tools. Most of the friction came from handoffs - sales to operations, operations to installation, and installation to inventory.
I outlined four core modules that would define the platform: Leads, Proposals, Installations, and Inventory. Together, they formed a simple, repeatable loop that could scale to any company size.
I drew the initial wireframes around those workflows and then focused on creating a design system in Figma to keep elements consistent. The system covered typography, colors, layout spacing, and reusable components for tables, cards, filters, and boards. With those foundations in place, I could move quickly - every new screen used the same structure, so the interface felt predictable from the start.
I worked in short cycles, meeting every two weeks to review progress and adjust priorities. Most feedback came directly through Figma comments, keeping iteration fast and lightweight.
Design Decisions
Because Helion touched so many workflows, the main challenge was keeping the product simple while still powerful enough to handle detailed operational data.
One of the early design choices was to standardize the layout and behavior across a majority of the core modules. Basic controls and inputs all follow the same structure, so users don't have to relearn patterns as they move from Leads to Installations to Inventory. This consistency made the product easier to navigate and simplified handoff to development.
I also had to balance speed versus depth. The founder wanted an MVP ready quickly, which meant prioritizing essential flows over advanced features.
Another key decision was to anchor the experience around clarity rather than decoration. Solar operations involve long timelines and a lot of data, so visual calm mattered more than visual flair. I used restrained color, generous spacing, and consistent hierarchy to make information easy to scan, especially for users managing dozens of projects at once.
Finally, we worked within the limits of an early-stage tech stack. I simplified certain interactions - like in-line editing and dynamic filtering - to ensure that the developer could implement them reliably. The goal was to deliver something clean and dependable, even if it meant saving more complex interactions for a later phase.
Design Decisions
Because Helion touched so many workflows, the main challenge was keeping the product simple while still powerful enough to handle detailed operational data.
One of the early design choices was to standardize the layout and behavior across a majority of the core modules. Basic controls and inputs all follow the same structure, so users don't have to relearn patterns as they move from Leads to Installations to Inventory. This consistency made the product easier to navigate and simplified handoff to development.
I also had to balance speed versus depth. The founder wanted an MVP ready quickly, which meant prioritizing essential flows over advanced features.
Another key decision was to anchor the experience around clarity rather than decoration. Solar operations involve long timelines and a lot of data, so visual calm mattered more than visual flair. I used restrained color, generous spacing, and consistent hierarchy to make information easy to scan, especially for users managing dozens of projects at once.
Finally, we worked within the limits of an early-stage tech stack. I simplified certain interactions - like in-line editing and dynamic filtering - to ensure that the developer could implement them reliably. The goal was to deliver something clean and dependable, even if it meant saving more complex interactions for a later phase.
Design Decisions
Because Helion touched so many workflows, the main challenge was keeping the product simple while still powerful enough to handle detailed operational data.
One of the early design choices was to standardize the layout and behavior across a majority of the core modules. Basic controls and inputs all follow the same structure, so users don't have to relearn patterns as they move from Leads to Installations to Inventory. This consistency made the product easier to navigate and simplified handoff to development.
I also had to balance speed versus depth. The founder wanted an MVP ready quickly, which meant prioritizing essential flows over advanced features.
Another key decision was to anchor the experience around clarity rather than decoration. Solar operations involve long timelines and a lot of data, so visual calm mattered more than visual flair. I used restrained color, generous spacing, and consistent hierarchy to make information easy to scan, especially for users managing dozens of projects at once.
Finally, we worked within the limits of an early-stage tech stack. I simplified certain interactions - like in-line editing and dynamic filtering - to ensure that the developer could implement them reliably. The goal was to deliver something clean and dependable, even if it meant saving more complex interactions for a later phase.
Design System Detail: Colors
Color variables were used across all components to keep the interface consistent and easy to adjust. Each color in the system—brand, surface, text, and border colors—is defined as a variable, which means changes cascade through every component automatically.
This makes it simple to refine contrast and balance as the design matures. It also sets up the system for the future: when the product adds a light mode, we can introduce an additional color mode without rebuilding or restyling components.
Design System Detail: Colors
Color variables were used across all components to keep the interface consistent and easy to adjust. Each color in the system—brand, surface, text, and border colors—is defined as a variable, which means changes cascade through every component automatically.
This makes it simple to refine contrast and balance as the design matures. It also sets up the system for the future: when the product adds a light mode, we can introduce an additional color mode without rebuilding or restyling components.
Design System Detail: Colors
Color variables were used across all components to keep the interface consistent and easy to adjust. Each color in the system—brand, surface, text, and border colors—is defined as a variable, which means changes cascade through every component automatically.
This makes it simple to refine contrast and balance as the design matures. It also sets up the system for the future: when the product adds a light mode, we can introduce an additional color mode without rebuilding or restyling components.
Impact
Helion hasn’t launched publicly yet, but early feedback from investors and industry peers has been positive. The unified structure and consistent design language helped the founder demonstrate the product’s potential clearly and secure investment even before development was complete.
For myself, the design system made the process faster and more predictable. I reused components across modules instead of rebuilding variations for each workflow. This consistency reduced implementation errors and improved my efficiency to meet a very tight deadline.
For future users, the expected impact is straightforward: a single system that replaces fragmented tools and makes it easier to manage every stage of a solar project. Sales teams can track leads and send proposals faster, project managers can see installation progress in real time, and inventory data stays synchronized throughout.
While it’s still early, the design direction has set the foundation for a product that can grow gradually to add financing and more.
Impact
Helion hasn’t launched publicly yet, but early feedback from investors and industry peers has been positive. The unified structure and consistent design language helped the founder demonstrate the product’s potential clearly and secure investment even before development was complete.
For myself, the design system made the process faster and more predictable. I reused components across modules instead of rebuilding variations for each workflow. This consistency reduced implementation errors and improved my efficiency to meet a very tight deadline.
For future users, the expected impact is straightforward: a single system that replaces fragmented tools and makes it easier to manage every stage of a solar project. Sales teams can track leads and send proposals faster, project managers can see installation progress in real time, and inventory data stays synchronized throughout.
While it’s still early, the design direction has set the foundation for a product that can grow gradually to add financing and more.
Impact
Helion hasn’t launched publicly yet, but early feedback from investors and industry peers has been positive. The unified structure and consistent design language helped the founder demonstrate the product’s potential clearly and secure investment even before development was complete.
For myself, the design system made the process faster and more predictable. I reused components across modules instead of rebuilding variations for each workflow. This consistency reduced implementation errors and improved my efficiency to meet a very tight deadline.
For future users, the expected impact is straightforward: a single system that replaces fragmented tools and makes it easier to manage every stage of a solar project. Sales teams can track leads and send proposals faster, project managers can see installation progress in real time, and inventory data stays synchronized throughout.
While it’s still early, the design direction has set the foundation for a product that can grow gradually to add financing and more.
Reflection
This project taught me how to design for scale while working within the constraints of a startup. Building the design system first created a foundation that made every other decision faster and more consistent.
Working closely with the founder also reminded me how important it is to balance ambition with practicality. We had to move quickly but still design in a way that could grow later without starting over.
Reflection
This project taught me how to design for scale while working within the constraints of a startup. Building the design system first created a foundation that made every other decision faster and more consistent.
Working closely with the founder also reminded me how important it is to balance ambition with practicality. We had to move quickly but still design in a way that could grow later without starting over.
Reflection
This project taught me how to design for scale while working within the constraints of a startup. Building the design system first created a foundation that made every other decision faster and more consistent.
Working closely with the founder also reminded me how important it is to balance ambition with practicality. We had to move quickly but still design in a way that could grow later without starting over.
© 2023–2026 John Konnakkottu. All rights reserved.