Shasta Cloud

7+ global enterprise clients. 50% cost reduction vs vendor hardware. AP deployment cut from 30 minutes to 10. Here's the 18-month journey from shadowing MSP technicians to shipping a production platform.

I came in as the sole UX designer alongside 3 product managers and 20+ engineers. I handled user research, information architecture, interaction design, usability testing, and developer handoff. This was my first enterprise B2B product - the sheer scale of the problem taught me more about designing for complex systems than anything before.

---

Before I designed anything, I spent two weeks sitting next to MSP technicians at three client sites. Watched them go through their day - provisioning access points, diagnosing network issues, monitoring site health across multiple locations.

What I saw was rough. One technician had 6 browser tabs open, each a different vendor dashboard, just to troubleshoot a single connectivity issue at one site. He'd copy an IP address from one system, paste it into another, check a spreadsheet for device locations, then go back to the first system to apply a fix. Something that should take 2 minutes was taking 14.

I documented 23 distinct workflows across the 3 sites. Every workflow that touched more than one vendor system required 6+ clicks to complete. Average was 8.3 clicks for what should've been 2-click operations.

---

My first instinct was to organise by function - monitoring, provisioning, alerts, reporting. Standard pattern, every networking tool does it this way. I wireframed it out and tested with 5 MSP technicians.

Results were blunt. 3 of 5 couldn't find the provisioning screen for a specific site without help. They kept trying to navigate to the site first, then looking for provisioning options within that context. My design had put provisioning in a global menu, disconnected from any site.

MSPs don't think in functions. They think in sites. "I need to fix the network at Building C" - not "I need to access the provisioning module."

So I restructured everything around a site-first hierarchy. Sites at the top level, floors and zones within each site, devices within each zone. Every function - monitoring, provisioning, alerts - accessible from inside the site context. Same 5 technicians retested: task completion dropped from 6+ clicks to 2. All 5 completed the provisioning task unassisted.

---

Vendor dashboards I'd seen during shadowing all made the same mistake - they showed every metric at once. Technicians were ignoring over 60% of what was on screen, scanning for the 3-4 numbers that actually mattered.

Card-sorting exercise with 8 technicians: "Which metrics do you check first when diagnosing an issue?" Answers clustered tightly around four things - device health, client count, bandwidth utilisation, alert severity.

I surfaced those four at the top level, progressive disclosure for everything else. Used colour-coded status indicators (green/amber/red) instead of numerical thresholds because during shadowing I'd noticed technicians making go/no-go decisions, not analytical ones. They needed "is this site healthy?" not "what's the exact throughput?"

Tested with 6 technicians in a simulated environment. Average time to spot a problem site dropped from 47 seconds (across 3 vendor dashboards) to 8 seconds.

---

The biggest time drain I observed during shadowing was access point placement. Technicians would visit a site, walk around guessing where to mount APs based on experience, install them, then come back days later to reposition the ones underperforming. One technician told me he'd moved APs at the same office three separate times.

We built a feature using LiDAR scanning on iOS. The UX challenge wasn't the scan itself - it was making scan results useful.

My first design showed a raw 3D point cloud after scanning. Technicians thought it was cool. Also useless. "Great, but where do I put the AP?" They didn't need a 3D model. They needed placement recommendations.

Redesigned the flow: scan the room → system identifies wall materials and interference automatically → overlays recommended AP positions as pins on a simplified 2D floor plan → technician confirms or adjusts → system generates an installation work order with coordinates.

Tested with 4 technicians on real site deployments. Time per AP dropped from 30 minutes to 10. Two of them specifically called out the 2D floor plan view (not the 3D scan) as what made it actually usable. Complexity in the system, simplicity in what the person sees.

---

During shadowing I kept seeing technicians pull out their phones to check site health while walking between floors. They'd open the full web dashboard on mobile Safari, pinch to zoom, scroll sideways, squint at tiny text. Painful to watch.

I designed a mobile companion focused on exactly three things: site health overview (anything broken?), alert triage (what needs attention right now?), and AP status lookup (is this specific device online?). Nothing else. No provisioning, no configuration, no reporting.

PM pushed for feature parity with the web dashboard. I pulled up the shadowing data - 92% of mobile usage fell into those three categories. Adding more would just recreate the unusable experience technicians were already dealing with. We shipped the focused version.

---

My initial dashboard was dense. Every metric visible, compact typography, minimal whitespace. I thought density meant efficiency.

The design review with my senior designer and the three PMs was honest. They flagged specific issues: alert panel competing with the site overview for attention, typography too small for the quick-scan use case, colour coding inconsistent between sections.

Went back and took a layered approach - a calm overview state with just status indicators, detail panels expanding on click. Alert panel moved to a collapsible persistent sidebar. Typography went up 2px across the board. I locked in a consistent colour system (3 status colours, 2 emphasis levels, 1 neutral) and documented it as a pattern library for engineering.

Second review passed. More importantly, the experience of getting specific, pointed feedback - not vague "make it better" but "the alert panel competes with the overview" - shaped how I've run design critiques on every project since.

---

Shadowing beats surveys for enterprise products. If I'd relied on interviews, I'd have designed a nicer vendor dashboard. Sitting next to technicians for two weeks showed me the multi-tab, multi-system reality that nobody would've described in a survey - they'd normalised it. That observation shaped the entire product.

I over-designed the first version. My instinct to show everything at once came from insecurity more than anything. I thought more information meant more useful. The card-sorting exercise proved the opposite. Restraint in enterprise dashboards is harder than density, but it's what the users actually need.

The pattern library was an afterthought and it cost us. I created design patterns during the project but only documented them formally near the end. By then, engineers had already built inconsistent versions of similar components. Starting that documentation in week 2 instead of month 14 would've saved a lot of rework.