Enterprise SaaS / FinOps
CMP Platform Redesign
CloudBolt asked for a visual refresh. What the research revealed was a product built around administrators — in a market where developers needed to be in the driver's seat. This is the story of how structured research changed the entire direction of the project.
Results
"I can't show my boss the value of the tool."
Customer interview — the insight that reframed the entire project
Challenges
The brief said "visual refresh." But the real constraints ran deeper — a product built on the wrong architecture for its actual users, with no instrumentation to prove it, and an engineering team without frontend experience to execute the change. Every design decision had to account for what was structurally possible, not just what was right.
Constraints
- —Admin-focused product architecture — rebuilding for developers meant rethinking every nav pattern, terminology choice, and default state
- —No front-end framework in place — visual and interaction improvements were blocked until the engineering foundation existed
- —Limited usage and behavioral data — Heap had to be instrumented before data could inform decisions
- —Slow release cycles — design had to account for what could ship incrementally, not just what was ideal
- —No public API surface — integration and extensibility work was entirely internal
- —No dedicated front-end engineering experience — new capabilities required hiring or upskilling in parallel with design
Objectives
- ↗Reorient the product around developer self-service
- ↗Introduce a modern front-end framework
- ↗Instrument the product to gather behavioral metrics
- ↗Build a dedicated product and design team
Research
The research ran across four tracks simultaneously — internal behavioral data, a heuristic evaluation, internal team feedback, and direct customer interviews. The convergence of what each track surfaced made the direction impossible to argue against.
Internal Data
- Customers were only using 1 of every 3 available cloud providers
- VMs accounted for the majority of orders — more complex services were being ignored
- Adoption of newer software versions was low across the customer base
- Both private and public data centers were in active use — a split the UI didn't account for
What this drove
A category-based catalog entry point — restructuring the first page around service types rather than a flat list, to surface the full breadth of available services and push adoption beyond VMs.
Heuristic Evaluation
- Admin-focused interface — reflected how the product was configured, not how users worked
- Outdated and inconsistent UI components throughout
- Confusing lexicon — product terminology didn't match what customers called things
- Reporting was minimal and not actionable
- No real user flows — navigating between tasks required unnecessary context switching
What this drove
A complete reorientation from admin-first to developer-first — rebuilt navigation, rewritten product terminology, and new task flows that matched how work actually gets done rather than how the system was configured.
Internal Feedback
- Engineering and support teams repeatedly heard requests for improved visual clarity
- Reporting was the most frequently requested improvement
- Users wanted more iconography to reduce cognitive load when scanning
- Consistent demand for side navigation to reduce clicks
What this drove
The admin reporting layer and dashboard — the most consistently requested missing capability across every internal channel, validated before a single screen was designed.
Customer Interviews
10 customers · 4 weeks
- "I strive to deliver an exceptional experience for my users."
- "I can't show my boss the value of the tool."
- "I don't know what my users are doing in the platform."
- "I need developers to be able to order cloud services — not just VMs."
What this drove
Three distinct decisions: the reorder feature (from "we frequently order the same configs"), the admin dashboard (from "I can't show my boss value"), and the self-service catalog structure (from "I need developers ordering more than just VMs").
Behavioral Data
Before any design decisions were made, we instrumented the product with Heap to map actual user behavior. Two findings shaped the redesign most directly. The ordering funnel sat at 41.8% completion before the redesign — improving to ~68% post-launch.
Competitive Review
Developer tooling had moved on while CMP stood still. A review of leading platforms surfaced four patterns that were reshaping how developers expected to navigate and discover services.
High-Quality Product Images
Leading platforms use photography and visual richness to make service catalogs feel approachable rather than transactional. This drove the Blueprint View card grid with high-quality service icons — replacing a flat text list with a catalog developers wanted to browse.
Modern Filter Design
Left-rail filters consume prime real estate and feel dated against modern developer tooling. Contextual, collapsible controls keep the primary canvas clean — a direct input into the unified filter bar that later became its own design system project.
Prominent Search
Power users who know what they want should never be forced to browse. Surfacing search prominently gave them the fastest path — a direct response to the interview finding: "I need to order resources for the project I'm working on right now."
Category-Based Browsing
Top platforms orient users to categories before individual items — matching mental organization, not database structure. This became the foundational decision behind the Category View entry point, replacing a flat list that treated every service identically.
Users
CMP served three fundamentally different audiences — developers, admins, and team leads — and the original product had only designed for one of them. The redesign had to serve all three without compromising any.
Developer
"I need to quickly order resources for the project I'm working on right now."
- —Order and reorder resources fast
- —Self-service without IT bottlenecks
- —Access to the full range of cloud services
Design Payoff
Category View · Blueprint View · Reorder
Admin / IT Manager
"I can't show my boss the value of the tool."
- —Visibility into platform usage and spend
- —Control over what developers can access
- —Data to justify the investment
Design Payoff
Admin Dashboard · Resource Management
Team Lead
"I need developers to be able to order cloud services — not just VMs."
- —Team productivity without hand-holding
- —Catalog organized by project or department
- —Governance without creating friction
Design Payoff
Category View · Blueprint View
Core Developer Flow
Mapping the developer's path from login to ordered resource revealed how many unnecessary steps existed. Eliminating them drove every subsequent layout and navigation decision.
Design Process
Getting to the right solution required going back to fundamentals before touching Figma — sketching the information architecture, then stress-testing it against the grid before committing to visual execution.
01 — Sketching
Early sketches explored the category hierarchy, the relationship between browsing and search, and how the ordering flow should connect to resource management — before any visual decisions were made.
02 — Wireframing
Mid-fidelity wireframes validated the layout against the grid and tested different densities — ensuring the design held up across catalog sizes and screen widths before moving to high-fidelity.
Final Designs
Five core areas of the product were redesigned. Each decision was grounded in something we heard directly from users — not a designer preference.
Before
After
02
Blueprint View
The service listing was rebuilt around a card grid with high-quality service icons. Filters were collapsed into a single unified control. Admin reporting was removed from the primary view entirely — it had no place in a developer-focused workflow. The result was a catalog that felt like a tool developers wanted to open, not one they were required to use.
Before
After
Before
After
05
Admin Dashboard
One of the clearest gaps from customer interviews: admins had no visibility into how their platform was being used. The new dashboard gave them a live view of spending, service popularity, order volume, error rates, and customer traffic by cloud provider. It turned CMP from a tool users complained about into one they could defend — and promote — to their leadership.
"Before this, I had no way to show my leadership what the platform was actually being used for. The new dashboard changed that conversation entirely."
IT Administrator, enterprise customer — post-launch
Reflection
What I Learned
The most important decision on this project was made before any design work started: insisting on research before opening Figma. The original brief was a visual update. The research reframed the problem as a product strategy problem — and that reframe was responsible for the outcomes.
Holding design, product, and research responsibilities simultaneously created real pressure. The upside was speed and coherence — decisions didn't need to travel across function boundaries. The downside was that it's easy to rationalize shortcuts when you control the whole process. I learned to build in deliberate friction: writing down tradeoffs explicitly, sharing early work with people likely to disagree, and resisting the temptation to move to high-fidelity before structural decisions were genuinely settled.
The reorder feature was the clearest example of research paying off in ways nobody predicted from the original brief. It came directly from a single interview insight — and it became one of the most-used features in the redesigned product. That's the thing about talking to users before designing: the solutions that matter most are usually the ones you never would have invented.
Next Project
02Filter Consistency
Design Systems & Interaction