Case Study: Kenza Cloud

 

At a glance

• Role: UX Architect / Lead UX (Audit → Research → UX Architecture → Design System → Testing)

• Product: Kenza Cloud — remote monitoring and control for Mitsubishi Electric HVAC/VRF systems (including scheduling/performance insights).

• Context: Pre-launch pilot with long-term Mitsubishi customers (many in the Southern U.S.), technicians often certified on the equipment

• Tools + methods: Figma prototypes / Dev Mode handoff, workshops, focus groups, Maze surveys + tree testing, heuristic review, accessibility audit aligned to WCAG guidance

The situation

Kenza Cloud is a cloud-based B2B platform that helps teams monitor, schedule, troubleshoot, and analyze HVAC system performance remotely. 

When I joined, the platform was already built enough to run a pilot—but the UX was designed more like a “mechanical tool”:

• Lots of task-heavy screens

• limited accessibility consideration

• weak guidance for first-time users

• and a registration experience that pushed people to call their Account Executive to figure things out

This mattered because Kenza Cloud is used by people who are busy and technical—if the UI slows them down, they won’t adopt it.

 

The goal

Make Kenza Cloud easier to understand and easier to use—without blowing up the existing codebase.
This was not a “redesign fantasy.” It was a real-world improvement inside real constraints.

 

 

 

We found some bumps in the road ( discovery) 

 

1) The product was already developed

We needed to reuse existing patterns and make high-impact changes that fit the current framework.

2) Mixed user types (not just technicians)

The early structure assumed “technician-first,” but the pilot feedback showed we needed a broader model.

3) Accessibility gaps

We didn’t have time for a full rebuild, but we had to address the basics and align to widely accepted accessibility standards (WCAG). 

4) Design system mismatch

The UI was built using an HTML template system (inspired by Material-style principles), but we didn’t have a clean component library in Figma to match it—so handoff was messy. (Material’s approach is component-driven; we needed the same discipline in design files.) 

 

Discovery (how I got smart fast)

1) Heuristic review (my starting point)

I kicked off with a heuristic evaluation because I had zero HVAC background and needed a structured way to find usability breakdowns quickly. (This is a common expert UX audit method.) 

What it gave us:

• a shared list of issues everyone could see

• a starting set of questions for stakeholders

• a way to prioritize without guessing

2) Internal interviews + domain learning

After a few weeks of demos, meetings, and learning the HVAC world, I identified internal experts who understood:

• the real user roles

• the real job pressures

• the business model (pilot → launch)

3) Focus groups (cross-functional reality check)

We ran 3 virtual focus group sessions, pulling in people like:

• HVAC Technicians

• Sales

• Product Management

• Engineers

Key insights we heard (the “ouch” moments):

• Users landed on an empty dashboard after registering (no guidance, no next steps)

• Pilot customers struggled with registration, often needing to call their Account Executive

• Technicians wanted to customize data points, and some wanted data to be more visually readable (not just raw tables)

4) Maze follow-up surveys + collaboration

We opened a Maze account to capture feedback at scale and keep the team aligned. Maze supports surveys, prototype testing, and other studies, and it’s built for quick insight-sharing across teams. 

• 3 surveys

• 53 total participants

• Sessions recorded and reused in internal discussions

 

Personas (who we designed for)

Based on focus group + survey patterns, we aligned on four core personas:

1. HVAC Technician – installs/maintains hardware; needs fast troubleshooting + clear status

2. Owner – owns equipment/property; cares about cost, reliability, comfort outcomes

3. Building Manager – manages schedules and day-to-day operations

4. Office Manager – handles account management, billing, and support coordination

This let us define “better UX” in a realistic way—even before public launch.

 

Prioritization (how we kept it realistic)

We grouped findings into a simple decision model:

Priority

Meaning

Why it mattered

Urgent

Impact adoption + daily usability

Fix now to support pilot → launch

Medium

Higher cost, moderate value

Plan into a roadmap

Low

Nice-to-have polish

Don’t distract the team

This helped business stakeholders and engineering make tradeoffs without drama.

 

The opportunity areas we were greenlit to improve immediately

​

1) Navigation/findability

We used tree testing with focus group participants to validate how users expect to find things (especially important as more features come online). Tree testing is specifically used to evaluate navigation structure and labeling. 

2) User group creation 

We uncovered the need for:

• admins with full access

• multiple roles under one account

• fewer “one person = one account” dead ends

3) Permissions + role-based experiences

The platform needed distinct experiences based on role and access—not everyone should see the same controls, alerts, and account tools.

4) Registration + onboarding walkthrough

Registration wasn’t just a UX flow—it was a marketing moment and a trust moment. We started here to set a strong foundation.

 

Task analysis / key user flows 

Because the product already existed, I focused on using what was there, then simplifying.

Flows we documented and improved:

• Registration (Sign up / Sign in)

• New user onboarding walkthrough

• Controls flow (individual vs batch control) Dashboard

• Monitoring/scheduling 

• Alerts

• Membership management

• Alert management

 

Accessibility audit 

Accessibility was limited, so we ran a targeted audit and prioritized “must-fix” issues aligned to WCAG’s core ideas (perceivable, operable, understandable, robust). Checklist focus areas:

• keyboard access

• color contrast / readable type

• form labeling/errors

• focus order/navigation clarity

• accessible help patterns

 

Design execution 

The challenge

The existing UI was based on an HTML template system, so we didn’t have clean Figma components that matched the real UI.

The solution: build a practical design system

We built a system that:

• created consistent components and patterns

• reduced visual inconsistency (colors, spacing, copy)

• supported accessibility improvements (contrast, typography rules)

• improved developer handoff using Figma’s Dev Mode workflow 

• I used an atomic-style approach (breaking the UI into small reusable building blocks that scale into larger patterns). 

Why that mattered: it made it easier for the dev team to implement changes without inventing new UI every sprint.

 

Usability testing (how we validated quickly)

Constraint: limited time + resources

We created a master prototype to test multiple features efficiently.

• 22 moderated sessions

• used Maze to capture insights + keep results shareable with stakeholders, recorded sessions, and used clips to support decisions

Our KPI’s  

We didn’t redesign everything. We focused on high-leverage UX improvements that fit the existing build.

• We treated registration and onboarding like a core product, not “extra screens.”

• We used tree testing to stop guessing about navigation. 

• We made roles + permissions a first-class part of the UX architecture, because the platform was never “technician-only.”

• We upgraded the design system and handoff process so engineering could move faster with fewer misunderstandings (Dev Mode supports developer-friendly inspection and clearer handoff). We used WCAG principles as a baseline for accessibility, even under time constraints.

Outcomes (kept honest, still strong)

Because this was a pilot-stage product, the “win” was building a roadmap and improvements that were feasible and aligned:

• Clearer onboarding and registration direction

• Role-based structure that matched how organizations actually manage properties and HVAC systems

• Navigation improvements grounded in user testing (not internal opinions) A more consistent UI system that reduced friction in design-to-dev handoff (Dev Mode workflow support) 

• Accessibility baseline improvements aligned to WCAG guidance 

 

What I learned

This project reminded me of something simple:

B2B users don’t want “more.” They want less friction.
Technicians don’t want to admire the UI—they want to solve problems faster, trust what they’re seeing, and move on.

And when the product isn’t launched yet, “better” has to be defined by:

• clarity

• predictability

• findability

• and adoption-ready onboarding

​

​

​​

​

​

​