A cloud-services platform built feature by feature, by different teams, over many years — until nothing felt like it belonged together.
FCI SmartCloud provides IaaS, PaaS, and SaaS services to help businesses of all sizes modernize their operations. When I joined, the product had grown organically — each feature was built separately, components weren't shared, and the experience felt inconsistent across every screen.
The goal wasn't to redesign the surface. The goal was to rebuild the foundation: understand what actually existed, establish the system underneath, and then make the product feel like one thing.
I was the lead product designer working closely with product managers and engineering leads across two product tracks simultaneously.
System architecture, design system, UX research, mobile app design, Figma ownership.
Roadmap, stakeholder alignment, feature prioritization.
Component implementation, design system integration, technical constraints.
API design, service logic, platform infrastructure.
Test planning, design review for edge cases and error states.
Business direction, Hackathon sponsor, final approval.
The platform served two distinct user types with very different needs and technical literacy levels.
Technical users managing cloud resources, provisioning services, and monitoring infrastructure. They need control, precision, and fast access to system status.
Non-technical managers evaluating cloud adoption. They need clarity on what the platform does and trust that it's reliable — without reading a manual.
Engineers deploying and managing applications on the platform. They value efficiency, good error messaging, and predictable behavior.
Users who needed to monitor and manage their cloud resources on the go — the audience for the first mobile app I designed for this product.
Before I joined, each feature had been built in isolation. The components used on the product were not always consistent — some screens used different button styles, spacing tokens, and navigation patterns for the same interaction. There was no shared sitemap that accurately reflected the live product.
We couldn't stop shipping to refactor everything. The design system had to be built incrementally, replacing components as features were updated — not as a big-bang redesign.
I audited the live product, not the documentation. Every screen, every flow, every component — mapped to understand what actually existed before deciding what to change.
Users couldn't predict where features lived. The navigation had grown without a consistent information architecture, so mental models broke across sections.
The same action — e.g., confirming a deletion — triggered different modal patterns depending on which part of the product the user was in.
Users who needed to check service status or respond to alerts on the go had no mobile option — they relied entirely on desktop.
Error messages were technical and often untranslated for non-developer users, leaving business decision-makers unable to self-resolve issues.
I conducted interviews with 8 internal users (IT admins, developers, and one business manager) and reviewed support tickets to identify recurring friction patterns.
Users grouped features by service type (compute, storage, networking), but the navigation was grouped by when features were built. The two didn't match.
Non-technical users skipped error modals entirely when they didn't understand them — they called support instead. Error copy was an invisible UX problem.
3 out of 8 users said they checked service health via Slack notifications because there was no mobile view — a workaround that masked the gap in the product.
I assumed denser information on the dashboard would feel more "powerful" to enterprise users. Testing showed the opposite: simpler layouts got faster task completion. I adapted the design to the simpler version.
The project was scoped into two phases: foundation (design system + IA) and expansion (mobile app + new features).
| User Story | Scope | Priority | Status |
|---|---|---|---|
| As an IT admin, I want consistent navigation so I can find features without guessing | IA Rebuild + Nav Component | High | ✅ Done |
| As a developer, I want error messages that tell me what to do next, not just what went wrong | Error state redesign + copy | High | ✅ Done |
| As a business manager, I want a dashboard I can understand at a glance without technical knowledge | Dashboard redesign | High | ✅ Done |
| As a user on the go, I want to check service status and respond to alerts from my phone | Mobile App (iOS + Android) | Medium | ✅ Done |
| As a future designer, I want a design system I can extend without breaking what's there | Design System Tokens + Docs | Medium | ✅ Done |
| As an admin, I want bulk actions on resources so I don't repeat the same operation 20 times | Bulk action patterns | Low | 🔄 In progress |
Selected screens from the redesigned platform. Replace the placeholders below with actual screenshots from your Figma file.
→ View all screens in the Figma prototype
The redesign delivered a unified product experience across web and mobile — the first time SmartCloud felt like a single platform rather than a collection of features.
If you're building something that needs someone careful with the details and curious about the data — I'd like to hear about it.