Persona clustering: why 1,000 workplaces do not need 1,000 desktops
The question before every technology decision is not „which platform?“ but „how do people work?“. From the interview questions through the architecture phases to the operating model — a continuous path that regularly ends with less infrastructure than planned.
Digital workplace initiatives often start with the answer already fixed: one platform, one delivery model, one licence package — rolled out across the entire workforce. That is easy to plan and expensive to run, because it meets requirements that do not exist in that form.
Persona clustering reverses the order. First the working pattern is established, then the technology assigned. One detail decides the quality of the result: clustering is done by working behaviour, not by job title. Two people in the same department with an identical job title can fall into entirely different personas — and two people from accounting and sales into the same one.
This article describes the complete path: which data comes first, with which questions it is gathered, how the clusters emerge, where they dock into architecture work under TOGAF, which dependencies they create — and what follows from that for operations and technology.
Step 1 — data basis
What is gathered before the clustering
Conversations instead of assumptions
HR, team leads, the works council, management — and above all the employees themselves. Talk only to IT and you get IT’s view of the work, not the work.
Building and site plans
Fixed workplaces, desk-sharing ratios, production areas, shift zones. The floor plan reveals whether a persistent desktop makes sense at all.
An existing employee survey
Usually already available and rarely evaluated for IT purposes. It contains points of friction in daily work that no inventory tool records.
Device and application inventory
Which applications actually run, how often, on which device — and which of them are long since SaaS and need no Windows behind them.
Step 2 — question set
Four fields of questions to take work apart
A question set is not a checklist to be ticked off. It is built so that the same thing gets described from different angles — and so that contradictions between those angles become visible. That is exactly where the interesting findings lie: when a team lead describes a way of working that daily practice replaced with a workaround long ago.
How is work done today?
The current state, described from daily work — not from the org chart.
- Which application is opened first in the morning, which is still open in the evening?
- How long does a typical session last — minutes or the whole day?
- Is the device shared, and if so, how often does the person change?
- In how many places is work done during a normal week?
- Which peripherals are indispensable — scanner, scales, label printer, headset, signature pad?
- What happens if the network fails for an hour?
What carries, what chafes?
The question skipped most often — and the one that guards against making things worse.
- What works well today and must on no account disappear?
- Where is time lost every day, and how much?
- Which workarounds have established themselves — exports, private devices, paper lists, second accounts?
- Which disruption leads to a service desk call, which is silently accepted?
- Which application is used reluctantly although it is mandatory — and why?
Where does the organisation want to go?
Without a target picture the clustering becomes a snapshot — and the architecture ages before it is implemented.
- Which business goals of the next three years directly affect how people work?
- Are sites, floor space or shift models changing?
- Which line-of-business applications will foreseeably move to the cloud, which stay on-premises permanently?
- Which regulatory requirements are being added — sector, data residency, audit obligations?
- Are there works agreements that restrict delivery models or monitoring?
- How are growth, acquisitions or spin-offs planned?
How do people want their way of working to change?
The employees’ own vision — it decides whether the later solution is accepted.
- How would you like to work in two years if you could choose freely?
- What would be a clear step backwards from today for you?
- Which restriction would you accept if something else improved in return?
- Which task would you happily hand over to a system?
- Which experience from an earlier change cost trust?
Surveys of this kind touch co-determination and data protection. Scope, voluntariness and the logic of evaluation belong settled before the first conversation — particularly when telemetry is used as a cross-check.
Step 3 — clusters
Seven personas as a typical result
The following patterns appear regularly in mid-sized and large organisations . The specific shape — and whether there turn out to be four, six or eight clusters — follows from the answers gathered, not from the template. The seventh group is new and still rarely considered — yet it is currently growing fastest.
Knowledge Worker
Fixed workplace, two monitors, an office suite plus one or two line-of-business applications. Heavy customisation of their own environment, little movement between locations.
Hybrid Worker
Three days in the office, two remote, changing desks under desk sharing. The workplace has to follow the person, not the other way round.
Frontline Worker
Production, warehouse, shift work. Short sessions at shared terminals, often with gloves on or under time pressure. Two or three applications, nothing else.
Power User
CAD, video editing, software development. Graphics load, high memory demand, long sessions and little tolerance for latency.
Task Worker
Email, one ERP login, one browser tool. A clearly bounded set of tasks, little customisation needed.
The sixth case
The cluster that needs no virtualisation: anyone who spends the whole working day in SaaS applications needs no virtual Windows desktop — but einen sicheren, verwalteten Browser-Zugang.
AI agents and autonomous systems
Die Gruppe ohne Mensch dahinter. Aus Sicherheitssicht verhalten sich Agenten wie specialised employees: they sign in, access applications and data and carry out actions. Only faster, at greater scale and without anyone sitting in Echtzeit zusieht.
On the seventh group: it is overdue to stop limiting clustering to people . What an agent does day to day differs, from an access control point of view, barely from what a case handler does — it signs in, opens applications, reads and writes data. The difference lies in speed, volume, and in the fact that nobody in Echtzeit danebensteht.
A plain consequence follows: Conditional access, compliance rules, application governance and data classification have to apply to non-human identities genauso sauber definiert werden just as to any knowledge worker or frontline worker. Leave this group out of the architecture and you accumulate blind spots faster than transparency — and only notice once an agent has done something that nobody can attribute.
Der unbequeme Befund
The greatest leverage lies in what does not get built
Once the clustering is in place, many organisations show the same picture: a considerable share of the workforce already works entirely in cloud services. ERP in the browser, CRM as SaaS, the line-of-business application hosted by a provider. For this group a virtual desktop is an intermediate layer without benefit — with its own costs, its own operating effort and its own attack surface.
original plan
browser access suffices
virtueller Bereitstellung
An illustrative example to show the method — not a depiction of an actual project. Real proportions vary considerably by sector, application landscape and cloud maturity.
The result is servers that never had to be ordered — and complexity that never had to arise.
Schritt 4 — Einordnung
Where personas TOGAF ADM andocken
Persona clustering is not a method beside architecture work but a supply into it. The question set feeds the requirements management at the centre of the Architecture Development Method — and is carried forward there across all phases, not filed away once.
Management
Step 5 — dependency architecture
No persona can be treated isoliert entscheiden
Every persona hangs on a chain. Make a decision at the end of the chain without knowing the beginning and you create exactly the special cases that make operations expensive later.
Ortsbindung
Client-Typ
Residenz
Berechtigung
Latenz
Peripherie
Shared dependencies
The power user’s line-of-business application and the task worker’s browser tool often access the same data source. Move it and both clusters are affected — auch wenn nur eines davon migriert werden sollte.
Peripherie als harte Grenze
A label printer, a signature pad or a set of scales help decide the delivery model. Peripherals are the most common reason why a solution that fits in theory fails in daily use.
Identity before infrastructure
Sign-in method and permission model act across all clusters. One persona with badge sign-in forces decisions that all the others have to carry.
Latenz ist standortgebunden
Dieselbe Persona kann an zwei Standorten unterschiedliche Anforderungen haben. The chain therefore does not end at the persona but at the combination of persona and location.
Schritt 6 — Betriebsmodell
What operations je Cluster bedeutet
Personas often disappear after the rollout — operations return to treating everyone alike, and the complexity saved comes back through the service desk . That is why the operating model belongs in the same structure.
| Persona | Service hours & priority | Change cadence | Monitoring-Tiefe |
|---|---|---|---|
| Knowledge Worker | Standard hours, standard priority | Geplante Wartungsfenster, Nutzer kann verschieben | Application availability, sign-in duration |
| Hybrid Worker | Extended service hours, location-independent support | Image-basiert, Aktualisierung ohne Nutzerbeteiligung | Plus connection quality from home |
| Frontline Worker | Shift coverage, high priority — a stoppage is a production stoppage | Only outside the shift, a short window, a fallback device needed | Device status and peripherals, not only the session |
| Power User | Regelarbeitszeit, spezialisierter Support | Agreed individually, a test instance before any change | Ressourcenauslastung, Grafiklast, Reaktionszeit |
| Task Worker | Standard hours, standard priority | Centrally, without consulting individual users | Sammelmetriken, keine Einzelbetrachtung |
| SaaS-nativ | Support shifts to identity and device | Paced by the provider — the task is observation, not planning | Access and device compliance instead of session metrics |
| KI-Agenten | No service hours in the classic sense — instead escalation on anomalous behaviour | Check version state and permissions periodically, revocation possible at any time | Which action, on which data, on whose behalf — complete traceability |
Three points decide whether the structure survives day-to-day operation. First, every persona needs a named business owner, not only a technical one. Second, there has to be a rule for exceptions — who decides when someone falls out of a cluster, and whether that becomes an individual case or a new persona. Third, a fixed review cycle belongs with it, because working patterns change faster than Infrastruktur.
Schritt 7 — Technical requirements
Vom Arbeitsmuster zur technical variable
Every row of this table traces back to an answer from the question set. That is the real purpose of the method: a technical requirement whose origin nobody can name is, in case of doubt, not a requirement.
| Anforderung | Abgeleitet aus | Effect on the architecture |
|---|---|---|
| Sessiontyp | Session length, device switching, need for customisation | Persistent, non-persistent or multi-session — determines sizing and imaging |
| Profilverfahren | Degree of customisation, sign-in frequency, expected sign-in duration | Profil-Container, Roaming oder bewusst kein Profil |
| Compute and graphics demand | Applikationsprofil, Datenvolumen, Darstellungsanforderung | Instanztypen, GPU-Bedarf, Skalierungsverhalten |
| Latenzbudget | Location, kind of interaction, tolerance for delay | Regionswahl, Protokollkonfiguration, Netzanbindung |
| Peripheral support | Indispensable devices at the workplace | Redirection capability — the most common knock-out criterion for a model |
| Authentifizierung | Device turnover, environmental conditions, protection requirement | Badge/NFC, PIN, mehrstufige Verfahren, bedingter Zugriff |
| Identity type | Is a human or a system acting — and on whose behalf? | Human versus non-human identity: its own permission logic, its own lifespan, its own logging |
| Datenresidenz | Regulatorik, Branchenanforderung, Betriebsvereinbarung | Region, storage location, separation of data holdings |
| Availability | Consequences of an outage for the business process | Redundancy, fallback, offline capability |
| Lizenzierung | Intensity of use, feature need, time in use | Licence tier per persona instead of a uniform top tier |
| Skalierung | Daily and shift pattern of use | Automated start-up and shutdown, capacity planning |
Approach
Sieben Schritte, in dieser Reihenfolge
Daten sammeln
Bestehende Quellen zuerst: HR-Struktur, Grundrisse, Device and application inventory, an existing employee survey. New surveys only where a gap remains.
Run the question set
Have the same working situation described from several perspectives. Contradictions are not noise but the actual result.
Arbeitsmuster identifizieren
Location dependence, session length, device sharing, application profile, protection requirement. Do not group by department — that produces clusters which do not exist in daily work.
Personas definieren
Describe each persona across four dimensions: applications, device, security and compliance requirement, licence need. Only when all four hold is the cluster finished.
Record the dependencies
Draw the chain from persona to device for each cluster and mark the shared elements. They determine the order of implementation later.
Technologie zuordnen — oder verwerfen
Only now is the platform decision made, separately per persona. A legitimate Ergebnis lautet: keine Virtualisierung erforderlich.
Betriebsmodell festlegen
Service hours, change cadence, monitoring, responsibilities and review cycle per cluster — before the first user is migrated.
Wie viele Personas sind bei Ihnen definiert?
The practical test is simple: can you say in one sentence for each user group why it receives exactly this delivery model — and can that justification be traced back to an answer that was gathered? If the justification is the same for every group, it is not a persona structure but a rollout.
Weiterdiskutieren
This article is part of Workplace Decoded.
I share analyses, frameworks and comparisons on the digital workplace — vendor-neutral and evidence-based. If you would like to comment on persona clustering, add to it or enrich it with your own experience, LinkedIn is the quickest route to a conversation.
Oder per E-Mail: kontakt@sofianesalmi.com