Appearance
End-User Roles
(Derived from PR#783 by Sven Kouwenberg — KD-0389)
Context: Kendo's buyer personas (user-personas.md) describe who purchases Kendo. This companion doc describes the different types of people who use Kendo day-to-day within a team. These are not Kendo roles (which are customizable per tenant) — they're archetypes for making product decisions.
Primary: Software Developer
Name: Robin — Mid-level Developer
| Role | Software developer in a small-to-medium team (3-10 people) |
| Technical proficiency | High — comfortable with Git, CI/CD, APIs, and CLI tools |
| Goals | Stay focused on coding with minimal context-switching; quickly find assigned work, log progress, and link branches to issues |
| Pain points | Too many clicks to get to "my work"; notifications that aren't relevant; tools that force process overhead instead of supporting flow |
| Key tasks | View assigned issues, move issues across the board, link branches, log time, comment on issues, review PR-linked issues |
| Success metric | "I spend less than 5 minutes a day on project management overhead" |
"Just show me what I need to work on and get out of my way."
Team Lead
Name: Dana — Technical Team Lead
| Role | Leads a development team; splits time between coding and coordination |
| Technical proficiency | High — also develops, but needs oversight tooling |
| Goals | Keep the team on track without micromanaging; spot blockers early; plan sprints efficiently |
| Pain points | No quick way to see who's stuck or what's overdue; sprint planning takes too long; unclear workload distribution |
| Key tasks | Sprint planning and review, assign/reassign issues, monitor board health, review time logs, manage epics |
| Success metric | "I can assess team status in under 2 minutes without asking anyone" |
"I need the big picture at a glance so I can unblock my team before they have to ask."
Product Owner
Name: Farid — Product Owner
| Role | Defines what gets built and in what order; bridges business and development |
| Technical proficiency | Moderate — understands software concepts but doesn't write code |
| Goals | Prioritize the backlog based on business value; track progress toward milestones; communicate status to stakeholders |
| Pain points | Hard to tell what's actually done vs. "in progress"; epics don't clearly show delivery progress; writing user stories that developers find actionable |
| Key tasks | Create and prioritize issues, manage epics, review sprint outcomes, triage reports/feedback, generate progress summaries |
| Success metric | "I can confidently tell stakeholders where we stand on any feature" |
"I need to know what's shipping this sprint and whether we're on track — without reading every ticket."
Admin
Name: Priya — Organization Admin
| Role | Manages the Kendo workspace: users, projects, permissions, integrations |
| Technical proficiency | High — often also a developer or team lead |
| Goals | Keep the workspace secure, organized, and correctly configured; onboard/offboard users smoothly |
| Pain points | Permission changes are tedious; hard to audit who has access to what; setup for new projects involves too many manual steps |
| Key tasks | Manage users and roles, configure projects and lanes, manage GitHub integrations, review audit logs |
| Success metric | "New team members are productive on day one; I never discover a permissions gap from an incident" |
"I want to set it up once and trust that it works — and know immediately when it doesn't."
QA / Tester
Name: Jesse — QA Engineer
| Role | Validates features, reports bugs, triages incoming reports and feedback |
| Technical proficiency | Moderate-to-high — reads code, runs tests, but primary focus is verification |
| Goals | Efficiently triage reports; ensure bugs are well-documented and actionable; track fix verification |
| Pain points | Reports lack reproduction steps; hard to see which bugs are blocked or blocking; no clear feedback loop when a fix is deployed |
| Key tasks | Triage reports (promote to issue or dismiss), create bug issues, verify fixes, track bug lifecycle, comment with test results |
| Success metric | "Every bug that reaches Done has been verified, and no report sits untriaged for more than a day" |
"I'm the quality gate — give me the tools to triage fast and verify with confidence."
Stakeholder
Name: Lena — Client / Project Stakeholder
| Role | External or non-technical stakeholder who needs visibility into project progress |
| Technical proficiency | Low — not familiar with development workflows |
| Goals | Understand project status without learning a complex tool; provide feedback that actually reaches the team |
| Pain points | Dashboards are too technical; doesn't know where to leave feedback; never sure if feedback was seen |
| Key tasks | View project progress, submit feedback or bug reports, review delivered features |
| Success metric | "I can check how things are going and give feedback without needing a walkthrough every time" |
"I don't want to learn your tool — I just want to see progress and be heard."
Overlap Matrix
Shows which goals are shared across archetypes — useful for prioritizing features with broad impact.
| Goal | Developer | Team Lead | Product Owner | Admin | QA | Stakeholder |
|---|---|---|---|---|---|---|
| Quick access to "my work" | X | X | X | |||
| Board/sprint overview | X | X | ||||
| Progress visibility | X | X | X | |||
| Report/feedback triage | X | X | ||||
| Low friction issue management | X | X | X | X | ||
| User/permission management | X | |||||
| Minimal learning curve | X | X | ||||
| Notification relevance | X | X | X | |||
| Time tracking | X | X | ||||
| Audit log access | X |
How to Use This Document
- Feature prioritization — Check which archetypes benefit. Features serving 3+ archetypes rank higher.
- Design decisions — When debating UX trade-offs, ask: "Does this serve the primary archetype (Developer)? Does it harm any other archetype?"
- User stories — Reference an archetype by name: "As Robin (Developer), I want to..." — this keeps stories grounded in real needs.
- Scope control — If a feature only serves one non-primary archetype and adds complexity for others, question whether it belongs in the current iteration.
Related
- user-personas.md — Buyer personas (who purchases Kendo)
- ../company/product-overview.md — Features that address each archetype's needs
- competitors.md — The alternatives these users have tried
- ../plans/PLAN-020-watch-system/ — Watch system plan (notification strategy driven by these archetypes)