Cross-Persona Tensions in NimbusWiz

The triangle · three personas, four tensions

T4 automation MARK DevOps Engineer KAY System Administrator ANGIE Technical Manager T1 · T3 confidence score rollback button T2 alerts vs. visibility no named dyadic tension
two tensions
one tension
none named
spans all three (T4)

Design disciplines · what the four tensions imply

  1. Layer surfaces, don't flatten them. The same data renders differently for different readers. The confidence score and the rollback feature are both examples.
  2. Default to the quieter persona on notification, the louder on visibility. Wake up Kay only when you must. Show Angie everything.
  3. Distinguish intent in the data model, not just the UI. Planned rollback and failed rollback are different events. The product's schema should know that before the dashboard does.
  4. Gate automation features on all three personas, not just the one they were built for. An AI feature that serves Mark but alienates Kay will fail in adoption regardless of its technical strength.
T1 · The confidence score
MARK ↔ ANGIE
Mark wants the denominator
A score he can audit: what data went into 84%, what it excludes, how reliable it has been historically.
Angie wants the translation
"High confidence" rendered as "proceed with comfort" or "pause until we learn more." Ninety seconds before her board meeting.
ResolutionLayered presentation. Default view is Angie's translation, plainly worded. One click away is Mark's audit panel: inputs, exclusions, historical calibration. Same score, rendered twice for different readers.
T2 · Alert sensitivity vs. status visibility
KAY ↔ ANGIE
Kay wants fewer alerts, tuned to signal
She mutes alerts to protect her sleep. Two weeks of false positives and she stops trusting the channel.
Angie wants status visibility
She asks why nobody escalated. A quiet dashboard surprises her in the board meeting.
ResolutionSeverity is tuned for Kay; summary visibility is unmuted for Angie. Kay adjusts thresholds against her own false-positive ratio. Angie sees a rolling count of warnings and criticals, whether or not Kay was woken up by them. A product decision about who gets woken up vs. who gets informed, not a UX setting.
T3 · The rollback button
MARK ↔ ANGIE
Mark values the button
A rollback-heavy system reads as reassuring: he has an out under pressure.
Angie values the metric
A rollback-heavy system reads as alarming: the program looks unstable in executive reporting.
ResolutionDistinguish in the data model between "rollback used as designed" (a planned safety net) and "rollback triggered by an unexpected failure" (a program signal). The first is what Mark needs to see normalized. The second is what Angie needs to see surfaced. Combining them is a data-model failure, not a UI choice.
T4 · The automation boundary
ALL THREE
Kay wants knowledge captured
Her institutional memory shared, not erased. She annotates; her voice survives.
Mark wants judgment trained
A tool that makes him smarter, not one that closes tickets while he sleeps.
Angie wants engineers empowered
A program that adds leverage to her team, not one that argues for headcount cuts.
Resolution · doesn't resolve cleanlyEvery new AI or automation feature in NimbusWiz must answer three questions before it ships. Does it respect Kay's desire to share, not erase, her knowledge? Does it train Mark's judgment rather than substitute for it? Does it make Angie's engineers more valuable, or less? Any feature that fails one will face resistance out of proportion to its technical quality.