Back
Console 2.0 at UPowr
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 principles, and designed the early layouts. A designer I was managing did the hi-fi work and led user testing.
Research
I started by designing a protocol and interviewing eight operators across five roles. In each session, I asked them to list the activities they did in Console, rate them by frequency and effort, and rank them by importance. Then, I asked them to walk us through the most important activities live, thinking out loud, so we could see the friction points.
Three findings stood out, each pointing to a design principle for the rebuild.
Comparing entities took too many clicks. The parent record showed some details but not enough, so a sales call about three quotes meant opening each one in a new tab. The principle that came out of this: increase information density. We needed to consolidate what operators wanted into one place so they could see relationships at a glance.
Investigating an issue meant clicking through too many nested records. When something went wrong, operators had to traverse a hierarchy of customer → site → project → quote → job to piece together what happened. One described it like this:
"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."
The principle: tell the story. Each project had a different story, but Console couldn't tell it. We needed to make it so it could 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, we watched an operator go to the customer, then the project, before finding what they needed on the site record. The principle: lighten mental load. We needed to make actions more visible and to 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 helped shape 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. The layout had a customer details strip, a navigation sidebar for moving between records, a content area for the record in focus, and an action area for operator tasks. Presenting this early and getting feedback helped us know we were on the right track.
Two specific 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 usability problems the original design hadn't addressed.
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. Of the four surfaces, this was the biggest update. Tasks move a project forward, like preparing a quote or reviewing an installation. We put tasks in their own surface, so operators could click between records to check details and notes without leaving the task. The work and the context sat side by side.
Comparison tables on parent records. Parent records previously showed minimal info. We built scannable tables that surfaced the most-needed fields for each child record. Operators could compare without opening every record, though detailed comparisons still required clicking in.
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 Console 2.0 was released, our largest customer ran a retro in which 40% of operators rated it as an improvement. It was a good signal, 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. One wrote:
"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 became their own record. They had run across the top of every page. We pulled them into a small card in the navigation sidebar, with the full details available as a record.
Action buttons came out from behind menus. We surfaced the most-used actions directly on the page, leaving less-used ones in the menu.
An activity feed showed the story of a customer. "Tell the story" had shipped as the sidebar, but it didn't show what had happened over time. We added a chronological feed on the customer record, pulling events from across their projects, sites, and jobs.
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.