Project Overview
Redesigning a mission-critical command center homepage to surface urgent signals faster
-
Reduced access to critical alerts from 6 steps to 1, improving speed and clarity in high-stakes workflows
-
Reimagined the homepage as an operational command surface rather than a static entry point
-
Designed a scalable, widget-based system enabling real-time visibility and faster decision-making across three product verticals
My Role
UX Designer
Timeline
June 2025 - Aug 2025
Tools
Figma, JIRA
Collaboration
Product managers, designers, engineers
Methods & Frameworks
Stakeholder interviews (8 participants), Affinity mapping, Comparative analysis, Prototype walkthroughs
Example, Source : Sonatus
Product & company context
Sonatus provides enterprise-grade software used by automotive OEMs to manage vehicle configurations and system operations at scale.
The Command Center functions as a central operational workspace, where engineering teams:
-
Define and manage vehicle policies
-
Track deployments and platform health
-
Surface alerts, failures, and critical system events
The Problem
The existing homepage was a static "welcome mat" that offered no real-time value.
Sonatus’s platform is organized around it's three primary products to manage vehicle software policies, but the information architecture was deeply siloed, it creates friction when users need to monitor system health or respond to issues across products.
Existing homepage, Source: Sonatus
High Friction
Critical alerts (like failed deployments) were buried 6 levels deep inside individual product pages.
Zero Visibility
There was no centralized way to see "System Health" at a glance.
Cognitive Overload
Users had to memorize complex navigation paths to find frequent information.
Old Workflow: 6 Clicks to reach critical errors.
Research
Identifying the "Dashboard Gap"
Rather than broad discovery, research focused on how users accessed critical information during real workflows.
Research goals :
-
Identify the primary users and what they expect to see when they first log in to SCC
-
Understand how the current homepage is being used and identify opportunities
-
Discover the top actions and information users want surfaced on the homepage
Methods:
-
Created a research discussion guide to ensure consistency across sessions
-
Conducted 8 stakeholder interviews across 4 teams: Field Application Engineers (FAE), Engineering, QA, and Cloud Backend
-
Performed navigation audits across all three products
-
Ran comparative analysis of operational dashboards in similar enterprise tools
If the homepage surfaced vehicle status and failed deployments upfront, it would eliminate a lot of unnecessary navigation.
- Andrew Mander
(Sr. Engineer)
Show critical alerts, campaigns pending approvals, things that demand attention.
- Girija Joshi
(Sr. QA)
Research Synthesis
Affinity mapping
I synthesized interview data through a collaborative affinity mapping session with three other designers. We transcribed interview notes, grouped observations into themes, uncovered patterns across teams, and distilled actionable insights.
Key Insights :
-
Users need clear, actionable summaries that surface key issues — not raw data, but highlighted trends, failed deployments, and time-bounded metrics that help them quickly spot what matters and take action.
-
Users need role-based dashboards that adapt to their persona and permissions — an engineer's priorities are different from a QA lead's, and the homepage should reflect that.
-
The homepage should serve as a launchpad — giving quick access to recent work, next steps, and the ability to pick up where they left off.
-
Users need integrated, self-serve support for guidance and onboarding — many relied on external documentation that didn't match their daily workflows.
Ideation
Exploring the solution space
Before landing on the final direction, I explored multiple approaches — from fixed dashboard layouts to fully modular widget systems, from dense data tables to visual-first summary cards. I explored three directions :
-
Fixed, role-based layout
-
A fully customizable grid
-
Composable widget model
The Pivot
Overcoming technical limitations
The Constraint
Ideally, the system would auto-detect a user's role (e.g., Manager vs. Engineer) to serve a personalized view.
However, backend API limitations prevented automated role detection in the current release cycle.
The Solution
A widget-based architecture to solve this without new backend infrastructure, I designed a user-configurable dashboard.
-
Old concept: System guesses what the user needs (Technically impossible).
-
New concept: User "pins" what they need (Technically feasible).
Solution
A "Single Pane of Glass"
The solution introduces a composable widget library that aggregates data from all three sub-products into a unified view. Instead of a static layout, the homepage is built from customizable cards that users can adapt to their workflows.
⚠️ Critical Alert Cards
Purpose: Immediate Triage.
Function: Instantly surfaces high-priority failures (e.g., "Deployment Failed") to the top of the feed so users don't have to dig for errors.
📊 Insight & Status Cards
-
Purpose: Monitoring.
-
Function: Visual summaries of system health, such as "Online vs. Offline Vehicles"
⚡ Productivity Cards
-
Purpose: Efficiency.
-
Function: Includes a "Recently Visited" module that deep-links users to their last active task and an "Integrated Help"card for contextual documentation.
Key design decisions :
-
Why widgets over a fixed layout? Different users across 4 teams had fundamentally different priorities. A fixed layout would optimize for one persona at the expense of others. Widgets let each user build their own dashboard.
-
Why cards with progressive detail? The summary-level cards (donut charts, status counts) give at-a-glance monitoring, while the data table beneath provides drill-down capability — serving both the "quick check" and "deep investigation" workflows I observed in research.
-
Day 1 vs. Day 30 experience: I designed the system to grow with the user — starting with sensible defaults on first login, then evolving as users customize their dashboard over time.
Prototype walkthrough
The prototype below demonstrates how the homepage evolves from Day 1 to Day 30 — showing how engineers can customize the dashboard over time by adding, rearranging, and prioritizing widgets based on their workflows.
Outcomes & Validation
The redesigned homepage was validated through prototype walkthroughs and usability testing with engineering and product stakeholders, focused on alert discovery, navigation effort, and cross-product awareness.
Faster alert discovery
Reduced from 6 clicks to 1 — critical failures now visible on first login
Cross-product visibility
Users could monitor deployments, vehicle health, and alerts from a single view for the first time
Improved workflow
"Recently Visited" and "Created by Me" modules removed repetitive navigation.
Reflection
What I learned
-
Architecture > UI: This project taught me that "pretty UI" cannot fix broken information architecture. We had to fix the structure of the data flow first.
-
Designing for Constraints: I learned how to propose solutions (like the user-configurable widget model) that respect engineering limitations while still solving the user's problem.
-
Cross-Functional Influence: Interviewing stakeholders from QA to Cloud Backend gave me the confidence to facilitate design discussions across engineering teams.