Personas
Method demonstration, not field research
NimbusWiz has no users. The three personas below are synthesised from product-research patterns I've seen across modernization tooling, not from interviews against this product. The pull-quotes are simply articulations of each user's stance and not interview transcripts.
This artifact is simply to record my persona definition and comparison skills. I've defined who I've designed NimbusWiz for, enough that disagreements become arguable.
A persona set is worth having only if it changes product decisions. Three users sit at the centre of every NimbusWiz design call:
- the engineer who runs systems through the pipeline
- the admin who watches fleet health
- the technical manager who signs off on the program.
Their jobs and fears differ. The product has to serve all three without flattening any of them.
The three at a glance
| Mark Flint | Kay Bell | Angie Johnson | |
|---|---|---|---|
| Role | DevOps Engineer | System Administrator | Technical Manager |
| Stance | "I don't need a better tool. I need to trust myself again." | "I'm not trying to be a hero. I'm trying to make sure nothing needs a hero." | "Show me the decision. I don't have time for the architecture." |
| Scope | Manages a backlog of dozens of Nimbus2000-class systems through the modernization pipeline | Watches fleet health across hundreds of systems and carries the institutional memory | Leads a multi-team engineering org; approves modernization budgets; reports up to executives |
| Functional job (The practical task the user needs accomplished) | Get systems through the pipeline without them failing in production | Catch problems before they escalate; produce post-mortems that hold up | Track program progress; communicate status upward; approve priorities |
| Emotional job (How the user wants to feel) | Restore trust in his own judgment after a recent failure | Convert ambient on-call anxiety into a structured practice | Maintain confidence she understands what her teams are doing |
| Social job (How the user wants to be perceived by others) | Be the engineer his manager calls when something is broken, not when it breaks | Be recognized for prevention, not just response | Translate technical reality into business narrative without losing fidelity |
| Biggest anti-goal | An AI that auto-remediates without him seeing the change | Alert noise that erodes signal over time | Dashboards that hide bad news inside green status indicators |
| Highest-priority design implication | the Modernization Advisor must show its work by default, not on request | Severity tuning belongs to Kay; summary visibility belongs to Angie | The Dashboard should lead with portfolio health and exceptional items, not with engineer-grade detail |
Why each one matters to the product
-
Mark is the user the product was built for.
The pipeline makes sense to him. The simulation gate works for him. The risk for the product isn't whether Mark adopts it; it's whether the product respects what makes him careful. Hide the reasoning behind a click and Mark stops trusting it. That's the failure mode the Modernization Advisor's Explanation panel exists to prevent. See Mark's journey for the stage-by-stage view.
-
Kay is the user the product alienates with a default skew toward executives.
She is the one who turns alerts off when they fire too often, and the one whose institutional memory becomes a single point of failure if the product doesn't have a place for it. Designing for Kay is mostly a matter of tuning: severity defaults, alert thresholds, and surface choices that respect her time on call.
-
Angie is the user the product reaches by accident, since the Dashboard is currently optimized for engineers.
She arrives via the Dashboard, looks for portfolio-shaped signals, and bounces when she finds operational detail. The product's strategic value lives in what Angie can defend in a board meeting, which means the Dashboard has to be re-thought as her primary surface, not as Mark's home page.
Where they pull against each other
The chart below names four places where the personas disagree, the design discipline each tension implies, and the resolution that serves both readers (or all three).
How these personas inform the rest of the portfolio
When a design decision is named anywhere else in the portfolio, it should reference which persona benefits and which persona pays the cost. That cross-linking is what converts personas from standalone artifacts into working context for the rest of the work.
See the journey maps for Mark and Zach (a non-technical user who isn't in this set, deliberately) for what moving through the pipeline looks like at the individual user's level.