User Persona & Customer Journey Matrix Markdown Table Template
A persona matrix compresses user research into something a product team can argue with. Each row is a pattern you saw repeatedly in interviews, support tickets, and usage data: a kind of person, the situation they are in, what keeps going wrong for them, and what your product does about it. Product managers cite it in PRDs to justify scope, designers use it to decide whose workflow a screen is optimized for, and marketing borrows its language for positioning.
Edit This Template
Edit cells, add rows, or sort — the Markdown updates livePaste cells from Excel or Google Sheets into the first header to replace the table · Tab / Enter / arrows move · Shift+F10 opens row & column actions
When to Use This Table
Its usefulness depends entirely on where the rows came from. A persona built from a dozen interviews and a few hundred support tickets settles debates; a persona assembled in a workshop from what the team believes about customers just restates those beliefs with a cartoon name attached. Both kinds are allowed, but they must be labelled differently. An assumption-based proto-persona is a hypothesis to test, and the table should say so until research confirms or replaces it.
A good matrix is short (most products have two to four personas worth designing for), describes behaviour and context rather than demographics, names one primary persona per product surface, and ties every pain point to evidence. A bad one includes age, hobbies, and a stock photo that change no decision, lists pain points the product does not address, and is never revisited after the kickoff deck.
Formatting This Table in Markdown
A user persona & customer journey matrix table puts a few things in cells that Markdown treats as syntax. These are the ones to watch so it renders correctly on GitHub, GitLab, Obsidian and docs sites.
A line break in the source ends the row
Each table row must be one line of source: a literal newline inside a pain-point cell splits the row and leaves stray cells. Use
<br>for visible breaks; see line breaks in cells.Hyphens and numbers do not make lists in cells
Writing
- First pain pointor1. First pain pointin a cell shows the characters literally. The portable pattern is• item<br>• item, as in the template;<ul><li>works on GitHub but not in every renderer.Long cells: fold the detail or switch to persona cards
Several bullets per cell across three text columns make tall rows with narrow columns. Keep the matrix for one-line comparisons, put each persona’s full story under its own heading, or fold extra pain points into a
<details>element, which GitHub renders inside cells.
What Goes in Each Column
| Column | Alignment | What to put here |
|---|---|---|
| User Persona Archetype | left :--- | A memorable name in bold plus, ideally, a short behavioural label: “Terminal Terry”, the README maintainer. Alliterative names help people refer to personas in meetings, but the label carries the meaning. Mark unvalidated rows as proto-personas so nobody mistakes a hypothesis for a finding. |
| Typical Role & Seniority | left :--- | The job titles and seniority you actually recruited and heard from, written as a range when it varied (“Data analyst to analytics lead”). Titles are a recruiting filter, not the segmentation itself: two people with the same title can behave like different personas. |
| Core Daily Pain Points | left :--- | Two or three observed problems, each phrased as a situation and its cost, separated with <br> so they stack inside the cell (see line breaks in cells). Include only pains your product could plausibly address; problems outside your scope belong in the research report, not here. |
| Primary Product Value | left :--- | The specific capability or plan that answers the pains in the same row, named the way it appears in the product. If you cannot point to a feature, tier, or roadmap item, that gap is a finding worth surfacing rather than a cell to fill with a slogan. |
| Tech Literacy | center :---: | A level from a scale you define once, centered, such as High, Medium, or Low, with each level described by behaviour: High lives in a terminal and edits raw Markdown, Low only uses visual editors. Without definitions, every team member reads the labels differently. |
How to Fill It In
- 1Gather evidence before writing rows: recordings or notes from user interviews, tagged support conversations, survey answers, and product analytics such as which entry points and features each segment uses. Note how many sources sit behind each pattern you intend to promote to a persona.
- 2Cluster by behaviour and goal, not by job title. Sort interview notes into groups that share a trigger, a workflow, and a frustration; a cluster that keeps reappearing across different titles is stronger than one tied to a single company.
- 3Write each pain point in the participant’s words where possible and link the source (interview ID, ticket number). Quotes keep the table honest when someone later asks whether a pain is real.
- 4Map every persona to the product surface or plan that serves it, choose one primary persona per surface, and record the trade-off explicitly when two personas want conflicting things.
- 5Add a last-validated date and revisit after each research round or when analytics show a segment growing or shrinking. Retire personas that no longer match anyone you are recruiting.
Ready-to-Paste Variations
Evidence-backed personas
Adds the columns that show how much research stands behind each row. Reviewers can see at a glance which personas are validated and which are still proto-personas.
| Persona | Sources | Interviews | Status | Last validated |
| :--- | :--- | ---: | :---: | :---: |
| Terminal Terry | Interviews, GitHub issues, CLI usage logs | 9 | Validated | YYYY-MM |
| Data Dana | Interviews, support tickets tagged “CSV” | 6 | Validated | YYYY-MM |
| Founder Felix | Team workshop only | 0 | Proto-persona | — |Jobs-to-be-done framing
Replaces role and demographics with the situation, motivation, and expected outcome. Useful when people with very different titles hire the product for the same job.
| When I… | I want to… | So I can… | Current workaround |
| :--- | :--- | :--- | :--- |
| paste query results into a pull request | turn them into an aligned table | get the review approved without reformatting | Hand-typing pipes in the editor |
| compare three pricing plans in docs | start from a ready-made layout | publish the page today | Copying a table from an old page |
| hand a spreadsheet to engineers | export it as Markdown | keep the spec in the repository | Screenshots pasted into the wiki |Persona-to-feature priority grid
Shows who each feature is for and how much it matters to them. Read down a column to find features that serve nobody important, and across a row to see whether a persona is neglected.
| Feature | Terminal Terry | Data Dana | Product Priya |
| :--- | :---: | :---: | :---: |
| CSV and SQL paste detection | Low | **High** | Medium |
| Keyboard-only editing | **High** | Medium | Low |
| Visual grid editor | Low | Medium | **High** |
| Template library | Medium | Low | **High** |Common Mistakes
Filling rows with invented demographics: age, marital status, hobbies, a stock photo.
Keep only attributes that change a design or messaging decision and that you observed. If an attribute would not alter what you build for this person, delete it; it mostly adds stereotypes.
Segmenting by job title alone.
Group by behaviour, goal, and context. A senior engineer who maintains docs and one who never touches them need different things, while a PM and an analyst may share the same workflow and belong in one persona.
Writing pain points as feature requests (“wants a CSV import button”).
Record the underlying problem and its cost: “re-types exported query results by hand before each review, about ten minutes a time”. The solution can then be designed instead of copied from the request.
Treating every persona as primary.
Pick one primary persona per screen or plan and design for them first. Secondary personas must not be blocked, but they do not get to dictate defaults, and the matrix should say which is which.
Related Markdown Table Templates
Browse all 50 templatesCompetitor & Product SWOT Analysis Matrix
Strategic SWOT analysis matrix mapping internal strengths, operational weaknesses, market opportunities, and competitive threats.
Technical SEO Audit & Meta Tags Matrix
Technical SEO spreadsheet matrix recording URL routes, target search keywords, title tag lengths, meta descriptions, and indexation status.
Software Release Changelog & Notes
Semantic versioning changelog recording release versions, deployment dates, feature highlights, bugfixes, and breaking updates.
User Persona & Customer Journey Matrix: Frequently Asked Questions
How many interviews are enough to build a persona?
There is no fixed number. Interview people from each suspected segment until the last few conversations add no new patterns, then stop. If a persona rests on one or two interviews, label it provisional and keep recruiting for that segment.
What is a proto-persona?
A persona drafted from the team’s existing knowledge and assumptions, usually in a workshop, before dedicated research. It is useful for aligning a team quickly, as long as it is marked as a hypothesis and replaced or confirmed by research before major bets depend on it.
Should personas include names and photos?
Names make personas easy to refer to in discussion. Photos are riskier: they quietly fix an age, gender, and ethnicity the research never established, which can bias design and hiring of test participants. Many teams use a name and an illustration or icon instead.
How do personas relate to market segments?
Segments size a market by measurable attributes such as company size or industry, which suits sales planning. Personas explain behaviour and motivation, which suits product design. One segment can contain several personas, and one persona can cut across segments.