Personas

Cross-Product Personas: enaio® and yuuvis®

The company-wide persona set for PM and Dev across all product lines. Seven protagonists (who a story is for) plus one lens (Business) used in Business Value and acceptance criteria but not as a story opener.

Attribute a Ticket (Use This First)

Walk the questions in order. Order matters: it resolves the cases that look like something they are not.

1. Is the actor an AI agent deciding at runtime, autonomously or semi-autonomously, what to call and with what parameters, rather than a human writing code ahead of time or clicking through a screen? → AI Agent
2. Else, does it need code interaction (script, event, API, interceptor, webhook)? → Developer / Integrator (Dexter)
3. Else, is it about the finished app being used (a screen, a workflow, accessibility)? → End User (Ulla)
4. Else, is it about proving the system is safe, auditable, or compliant, or approving a risky change? → Security & Compliance Owner (Kerstin)
5. Else, is it about keeping an already-deployed system running (availability, scaling, updates without downtime, monitoring, backup, incident response)? → Platform Operations (Ophelia)
6. Else, does it change what one installation or deployment is (schema, install, system-wide config)? → System Administrator (Cody)
7. Else, does it manage use within the existing system (users, rights, catalogs, tenant or department settings)? → Business Admin / Key User (Anna)
8. Pure business-value or cost rationale for an epic? → Business Stakeholder lens (Ben)

Worked Example

Ticket: “Add a mandatory field to the contract form.” Needs code? No. Finished app usage? No. Compliance approval? No. Keeping a live system running? No. Changes what the deployment is? Yes, it changes the form’s structure → Cody.

The Set at a Glance

Verb	Role Label	Name	Changes what	Quality lens (check in ACs)
Act	AI Agent	—	Executes actions across the system autonomously at runtime	Machine-readable errors, self-describing schemas, determinism/idempotency, response conciseness, narrow permission scoping, action-to-actor traceability
Use	End User	Ulla	Nothing, uses the finished app	Usability, accessibility, stability
Assign	Business Admin / Key User	Anna	Use within a running system	Safe self-service, guardrails
Configure	System Administrator	Cody	What one installation or deployment is	Correctness, recoverability of setup
Operate	Platform Operations	Ophelia	Keeping an already-deployed system running	Uptime, no-downtime changes, monitoring, backup
Extend	Developer / Integrator	Dexter	Behaviour through code	API stability, documentation
Control	Security & Compliance Owner	Kerstin	Nothing directly, sets and approves	Traceability, reversibility, provability
(lens)	Business Stakeholder	Ben	Nothing, justifies the epic	Long-term cost and complexity

AI Agent

Attribute	Description
Verb	Act
Type	Autonomous or semi-autonomous software actor: an LLM-based agent, chatbot backend, or automation, acting for a human user or under its own service identity
Changes	Executes actions at runtime via API, script, event hook, or UI automation, deciding live what to call and with what parameters, usually without per-step human review.
Need	Self-describing interfaces it can read as machine input, structured errors it can act on, narrow permission scoping, concise bounded responses, idempotent operations safe to retry, and complete action logging.
Background	Distinct from Dexter, who writes an integration once, offline, with time to read docs. The AI Agent decides live, composing many calls within one task with no human confirming each step, so ambiguous docs and non-idempotent operations cause real damage, not just wasted time. It consumes both Dexter’s APIs and Ulla’s finished app via UI automation, and may act under a human’s identity or its own, which brings it into Kerstin’s scope too.
Product Usage	Same surfaces as Dexter (scripting APIs, REST APIs, event hooks, MCP-style tool interfaces), plus UI automation of the finished app when no API exists.
Quality lens	Machine-readable errors, self-describing and discoverable schemas, determinism and idempotency, response conciseness and pagination, narrow permission scoping, action-to-actor traceability.
When to Use	API or tool design for autonomous callers (MCP servers, agent tool catalogs), machine-readable errors, retry semantics, permission scoping for agent identities, any story about an AI agent doing something in enaio® or yuuvis®.
When NOT to Use	• A human writing integration code once, offline → Dexter • A human using the finished app → Ulla • Approving the audit requirement the agent’s actions must satisfy → Kerstin
Difference from Dexter	Dexter writes an integration once, offline, with time to read docs. The AI Agent decides live, autonomously, composing many calls per task with no human reviewing each step.
Key Question	Can this interface be read, called, and safely retried by something with no human judgement or time to read docs, and is every action traceable to whoever it’s acting for?

End User (Ulla)

Attribute	Description
Verb	Use
Age / Role	41 / Case Worker, Regional Government Office
Changes	Nothing. Uses the finished application
Need	Stable, fast, accessible, and predictable interfaces so daily work is never disrupted.
Background	Processes structured cases every day (applications, files, contracts, HR). Context varies across public authorities, insurance, healthcare, manufacturing and across working locations (office, field, travel), but she always works with the same interfaces for hours, often under time pressure. Unexpected behaviour, slow response, or no keyboard operation has real consequences.
Product Usage	Every end-user interface: webclient, explorer, mobile apps, Microsoft integrations, browser add-ins. Never a configuration or administration tool.
Quality lens	Usability, accessibility (BITV/WCAG), rendering stability, keyboard navigation, performance, findability, correct preview and display, clear feedback when access is denied.
When to Use	Any story about the finished app being used: workflows, screens, accessibility, performance, search and retrieval, export and restore.
When NOT to Use	Anything that opens a config or admin tool. She is who configuration is done for, never the one doing it.
Key Question	Does the interface stay stable, accessible, and predictable, regardless of what was configured behind it?

Business Admin / Key User (Anna)

Attribute	Description
Verb	Assign
Age / Role	36 / Key User or Team Lead in a department (customer side)
Changes	Use within a running system: users, groups, roles, rights, catalogs, tenant or department settings, cleanup within her own scope
Need	To administer her department’s or tenant’s use of the system safely, without deep technical knowledge and without waiting for IT or a developer.
Background	A business person, not an IT specialist, who knows her department’s processes best. Within an already-configured system she manages who may access what, maintains catalogs and value lists, and adjusts settings. She is the first person colleagues ask, so she is effectively first-level support for her own department or tenant. She works only within boundaries someone else set up, and never sees the underlying infrastructure.
Product Usage	Scoped admin surfaces: enaio® editor in Fachadmin scope (roles, rights, catalogs within assigned cabinets); yuuvis® Apps Admin Console; Momentum tenant administration (users, groups, roles, catalogs). yuuvis® RAD’s management-studio covers the same ground for legacy customers still migrating to Momentum. Never the system’s structure, infrastructure, or code.
Quality lens	Safe self-service: guardrails, safe defaults, scoped views, visibility of impact before acting, protection against irreversible mistakes.
When to Use	Roles and rights assignment, catalog and value-list maintenance, tenant or department settings, self-service configuration, first-level support within her own organisation.
When NOT to Use	• Defining what objects, fields, or workflows exist, or installing/updating → Cody • Cross-installation or vendor-side diagnostic support on someone else’s system → Cody (Support-Mitarbeiter facet) • Anything needing a script or API call → Dexter • Security or compliance accountability → Kerstin
Difference from Cody	Anna decides who may do what inside a system Cody has already built, and only within her own tenant or cabinet. Cody decides what the system is, and sees the infrastructure she never does.
Key Question	Can I set up my department’s access and lists safely, without breaking anything or calling IT?

System Administrator (Cody)

Attribute	Description
Verb	Configure
Age / Role	42 / ECM Consultant or System Administrator or Support professional (OS Professional Services, partner, or customer central IT)
Changes	What one installation or deployment is: schema, object definitions, mapping, install, system-wide config. Hands off to Ophelia once it’s running.
Need	To set up and configure one deployment reliably and safely, so it does what the customer needs before it goes live.
Background	Carries whole-system, technical responsibility for getting one deployment right. Defines the data model (object types, fields, forms, workflows, schema and mapping), and runs the initial deployment (Helm charts, config files, fonts, probes, DLC config on yuuvis®). Hands off to Ophelia once the system is live and running. On enaio® this is often the same person; on yuuvis® it is usually a different team. He also carries a diagnostic facet: analysing reported incidents on other installations or tenants without operating or developing them himself (reading logs and processing history, explaining “why did X happen to this document”), limited intervention only.
Product Usage	enaio® editor; yuuvis® Momentum schema, mapping, and deployment configuration (Helm charts, config files). yuuvis® RAD’s designer covers the same ground for legacy customers still migrating to Momentum, not sold on new projects.
Quality lens	Correctness and recoverability of setup: traceable configuration switches, startup validation, clear errors on misconfiguration. For the diagnostic facet: traceability per object, logs tied to the object, run and processing overviews.
When to Use	Object and schema definition, form and workflow design, initial installation, SSO setup, deployment, mapping definitions, and (as a facet) cross-installation diagnostic support.
When NOT to Use	• Assigning rights within one tenant, catalogs, or in-house first-level support → Anna • Keeping an already-deployed system running → Ophelia • Extending through code → Dexter • Owning a security or compliance requirement → Kerstin (Cody often implements the fix she requires)
Difference	Versus Anna: Cody builds the whole deployment; Anna administers one tenant’s or department’s use of it. Versus Ophelia: Cody sets up one deployment then hands off; Ophelia keeps it running afterward, always, on both product lines. Versus Dexter: Cody configures through tools; Dexter writes code.
Key Question	Is this installation or deployment set up and configured correctly so it does what the customer needs?

Platform Operations (Ophelia)

Attribute	Description
Verb	Operate
Age / Role	39 / System Operator, Site Reliability, or Operations Engineer, keeping a live deployment running
Changes	Keeps an already-deployed system available: availability, scaling, live updates, monitoring, backup, incident resolution. Never touches business configuration (that’s Anna) or the deployment’s structure (that’s Cody).
Need	Zero-downtime operation, with clear signals when something is wrong.
Background	Every deployment needs someone to keep it running after Cody hands it off. On enaio®‘s on-premises, single-tenant installs, a mistake here affects one customer, so this is often the same person as Cody. On yuuvis®‘s shared multi-tenant platform, a mistake affects every tenant at once, a much bigger blast radius, so this is almost always a separate, dedicated team.
Product Usage	enaio® administrator and enterprise-manager (users, security, licensing, servers, archiving jobs); yuuvis® platform monitoring, health and readiness signals, scaling controls, backup and restore tooling, incident response and runbooks.
Quality lens	Availability without downtime, meaningful health and readiness signals, configuration changes that don’t require a restart, clear runbooks.
When to Use	Availability, scaling, live updates, monitoring, backup, and incident response on an already-deployed system.
When NOT to Use	• Setting up a specific project’s or tenant’s deployment → Cody • Changing a tenant’s own users, rights, or catalogs → Anna • Writing product code → Dexter
Difference from Cody	Cody sets up a deployment, then hands off. Ophelia keeps it running afterward. Same split on both product lines, only the staffing differs: usually one person on enaio®, usually a dedicated team on yuuvis®.
Key Question	Is the deployment available and healthy, and can we change it without taking it down?

Developer / Integrator (Dexter)

Attribute	Description
Verb	Extend
Age / Role	32 / Software Developer, System Integrator, or Technical Consultant
Changes	Behaviour through code: scripts, APIs, integrations, automations, usually inside a project or partner solution
Need	Stable endpoint behaviour, clear error semantics, idempotency, deterministic sorting and pagination, and understandable schema and search semantics, so integrations work reliably without reverse-engineering.
Background	Builds on top of the system: scripts, APIs, integrations, automations. Works at the customer, at a partner, or independently. Knows his language and environment well, the ECM only as far as the task needs. Poor docs, hidden side effects, and unannounced breaking changes cost him disproportionate time. Explicit boundary: consumes the platform, never configures it.
Product Usage	Scripting APIs, event hooks, REST APIs, SDKs, interceptors, webhooks. Little or no use of graphical interfaces.
Quality lens	API stability, complete and accurate documentation, predictable errors, idempotency, deterministic pagination and sorting, versioning, no silent breaking changes.
When to Use	API design, scripting and event model, interceptors and webhooks, technical interface docs, API error responses, versioning, and interface stability. Anything that requires writing code.
When NOT to Use	• Configuring through a tool, without code → Cody (deployment-wide) or Anna (tenant/department) • Using the finished app → Ulla
Difference from Cody	Dexter writes code against the system; Cody configures it through tools. Clickable in editor, designer, or management-studio = Cody. Needs a script, event handler, interceptor, or API call = Dexter.
Key Question	Does the interface behave as the documentation promises, and will it stay that way?

Security & Compliance Owner (Kerstin)

Attribute	Description
Verb	Control
Age / Role	52 / Head of IT Applications (accountable for the production system)
Changes	Nothing directly. Sets requirements, reviews, and approves
Need	Secure, controlled, traceable, reversible, and compliant production, with proof of who accessed what, even under impersonation.
Background	Accountable for a production system with real users and data. Approves changes only if safe, traceable, and reversible, because she must explain failures to management, data protection, and auditors. Owns security posture and compliance: access control, complete and immutable audit trail, deletion reasons, retention and deletion periods, audit-proof archiving, GoBD and GDPR compliance, hardening. She sets the requirement and reviews; she does not operate herself.
Product Usage	Monitors deployments and system state, reads audit logs, reviews access, approves releases. Rarely operates configuration tools herself.
Quality lens	Traceability, reversibility, provability: complete immutable audit trail, access review including impersonation, retention and deletion periods, confirmation before damage, rollback.
When to Use	Security tickets, compliance and audit, access reviews, retention and legal hold, audit-proof archiving, deployment safety, rollback, data protection, hardening.
When NOT to Use	• Actually configuring the system or implementing the fix → Cody (or Dexter if it needs code) • Assigning day-to-day tenant or department rights → Anna • (She owns the requirement; the doer appears in the AC)
Difference from Cody	Kerstin owns the why (must be auditable, provable, access-controlled, reversible) and approves. Cody owns the how and implements. A security ticket opens with Kerstin even when Cody or Dexter does the work.
Key Question	What happens if something goes wrong, and can I prove it, explain it, and reverse it afterward?

Business Stakeholder (Ben) — Lens, Not a Protagonist

Attribute	Description
Verb	(epic-level lens)
Age / Role	45 / Platform & Operations Manager
Changes	Nothing. Justifies the epic, or clarifies scope before implementation
Need	Fewer tools, shared components, a sustainable architecture, and, for clarification work, solid statements on effort, risk, and dependencies before committing to build.
Background	Views the system over years. Counts support tickets, maintenance effort, and duplicated solutions. Every workaround today is cost tomorrow. Approves modernisation because the status quo is a technical and organisational risk. Measures success in reduced complexity, not features. The yuuvis®-side “Product Owner” persona for spike and clarification stories is the same non-protagonist role, just triggered by a scoping decision rather than a cost argument.
Product Usage	No direct use of configuration tools or functional interfaces.
Quality lens	Long-term cost, complexity, consolidation, reuse across products; for spikes, credible estimates of effort, risk, and dependencies.
When to Use	At epic level, in Business Value, to justify architecture investment, legacy replacement, or platform consolidation. Also for spike or clarification stories where the deliverable is a decision, not a feature.
When NOT to Use	Never as a story protagonist for a feature. If you are writing “As Ben, I want…”, the story belongs to Ulla, Anna, Cody, Ophelia, Dexter, or Kerstin.
Key Question	Does this decision reduce long-term complexity and cost, or does it just move it?

Deliberately Not Personas

• Product Owner (internal, and the yuuvis® clarification/spike-story sense): the story author, or a scoping/decision role, not a target user. Folds into the Ben lens.
• Support Agent: a need (diagnostics, clear errors, reproducibility), not its own persona. In-house first-level support for one’s own department or tenant rides on Anna. Cross-installation, vendor-side diagnostic support (yuuvis®‘s Support-Mitarbeiter) rides on Cody’s diagnostic facet.
• Sales: not a distinct relationship to the system. Demo-quality UI requests are Ulla-shaped, same accessibility and stability requirement, different motive. Competitive or market rationale belongs to the Ben lens. Demo or trial environment tooling is internal go-to-market work, not part of the customer lifecycle this set describes.