Back
Console 2.0 at UPowr
Research, product design, and design management · 2025
UPowr is a SaaS product for managing solar and battery sales, installations, and servicing. Console is its operator platform that sales, system design, and ops teams use daily to manage customer projects. By early 2025, it wasn't working for them.
"Console is really good at capturing the job as it's supposed to happen. But jobs very rarely happen as they're supposed to."
We decided to rebuild Console from the ground up. I led the research and synthesis, wrote our design principles, and mocked up early layouts. A designer I was managing led the hi-fi work and user testing.
Research
I designed a protocol and interviewed eight operators across five roles. In each session, I had them list the activities they did in Console and rank them, before walking us through the most important ones, thinking out loud.
Three findings stood out, each pointing to a design principle for the rebuild.
Comparing entities took too many clicks. A sales call about three quotes meant opening each one in a new tab. The principle that came out of this: increase information density.
Investigating an issue meant clicking through too many nested records. Operators had to traverse a hierarchy of customer → site → project → quote → job to piece together what happened.
"When you first open that first page in the Console, you should be able to get the basic information very quickly. Sometimes it's actually pretty hard to decipher what's going on."
Principle: tell the story. Show the detours, not just the happy path.
Triggering an action required guessing the right record. Console hid actions inside specific record types, often behind menus. In one interview, an operator went to the customer, then the project, before finding what they needed on the site. Principle: lighten mental load. Make actions more visible and use familiar UX patterns.
With the principles set, we pulled together a customer reference group to make sure we were building the right thing.
Customer reference group
The group included representatives from three companies that used Console daily. For twelve weeks, we'd present new work, they'd provide feedback, then we'd iterate. I shaped the format and decided what to show. The other designer facilitated.
Before the first session, I'd sketched a new project workspace layout to address the issues from the interviews. This was the first thing we validated with the group. Presenting this early and getting feedback helped us know we were on the right track.
Two changes came out of later sessions. One operator mentioned that when they needed a file, they didn't always know which record it sat on, so we added a central files page. The financial summary on a quote, a high-use surface for sales, was also rebuilt after the group walked us through its usability problems.
The CRG sharpened the work and validated the architecture before we built it at scale.
What we shipped
Three things shipped that mattered most.
The four-surface layout. What we'd validated with the CRG became the architecture for every record type.
An action area that kept context visible. Tasks, like preparing a quote or reviewing an installation, move a project forward. We put them on their own surface, so operators could click between records to check details and notes without leaving the task.
Comparison tables on parent records. We built scannable tables that surfaced the most-needed fields for each child record, so operators could compare without opening every record.
Due to our deadline, the new Console was not as polished as we would have liked. But we decided to ship, knowing we'd come back.
Outcomes
A week after launch, our largest customer ran a retro in which 40% of operators rated Console 2.0 as an improvement. The signal was real, but most operators weren't yet ready to call it a clear win.
What landed was the architecture. Operators called out the sidebar, faster loading, and more information visible at once.
"Side bar of site → project → quote on the customer record. Clear visibility of what exists and their statuses."
After launch, we made three changes based on operator feedback: customer details moved into a small card with a full record behind it, frequently used actions came out of menus, and a chronological activity feed pulled events across each customer's projects to tell the story over time.
Key lesson
What I'd do differently is set up a comparable post-launch measure before we started. We had a baseline survey, but nothing clean to compare it against, so we had to rely on retro signals and customer feedback. The signal was real, but it wasn't measurable. Next time, I'd want both.