Personas

Purpose

Personas replace the private assumptions each member of a team forms about the user with a small number of documented, shared and verifiable archetypes. Each one rests on interviews and survey data that can be produced when someone contests a decision. A team designing a solution is constantly deciding on someone's behalf: which feature goes first, which path is optimised, which channel is kept. With no shared reference, each member decides according to the user they imagine, and those imaginary users differ without the disagreement ever surfacing.

The technique supports prioritisation: a backlog option is judged by the persona it serves and by that persona's rank in the pool, which turns an abstract value debate into a question with a verifiable answer. It supports requirements framing: a persona's goals and needs translate into acceptance criteria and user stories, and the frustration measured in the research becomes the gap the solution has to close. It supports interaction design: a persona's digital confidence and preferred channel dictate the screen, flow and channel choices that the text of a requirement leaves open.

The deliverable is the persona card, one page per archetype, plus the pool the cards form and its ranking. The Agile Extension to the BABOK Guide states this ranking explicitly: personas are ranked to identify those that will realise the most benefit from the solution design. Requirements analysis, backlog refinement and design then consume the card, provided it is reopened there.

Personas model users. The four other techniques in the 10.43 family answer different questions: the stakeholder list records who exists (including the regulator, the sponsor and the internal reviewer, none of whom will ever become a persona), the stakeholder matrix says who carries weight and what engagement strategy follows, the onion diagram says how far from the solution each one stands. The RACI matrix says who answers for what, activity by activity, which none of the preceding three establishes. A team turns to it when the question becomes "who signs off". A persona carries goals and behaviours, with no axis of influence and no place in a hierarchy.

Usage

When to use it

• Poorly understood user segment: research replaces the team's guesses before design or redesign.
• Agile team with no customer representative available: the persona stands in for that representative during backlog refinement and user stories.
• Tacit and divergent assumptions about "the user": a validated persona gives one reference to hold decisions against.
• Prioritising a backlog or a scope: judge each option by the persona it serves and by that persona's rank.
• Iterative interaction design: one specific user's channel and digital confidence change the screen choices.
• Solution serving segments with opposing needs: the pool exposes what an average user conceals.
• Team alignment before research is funded: a provisional persona, dated, labelled "hypothesis".

When not to use it

• Small, named, reachable population: interview the five users concerned directly rather than manufacturing their archetype.
• Question of organisational power or influence: a persona has no axis of influence; take the stakeholder matrix.
• Technical solution with no human end user: no usage to model, the technical stakeholder list is enough.

Description

What a persona card carries

The Agile Extension to the BABOK Guide distinguishes two templates: the short card offers a quick one-page overview; the long card keeps the same fields and opens others, a buying motive for instance. Additional research moves a persona from one to the other. In practice the short card reads in thirty seconds, the condition for it to be useful during a meeting.

• Name and face: a realistic first name and a representative image. The photograph of an identifiable person exposes the card to image rights and to the Swiss Federal Act on Data Protection (FADP). A team reasons differently when the question becomes "what would Nadia do with this screen" rather than "what would the segment of self-employed women under 35 do".
• Context: the occupation, place and situation that explain how this person uses the solution and only those socio-demographic attributes that pass the differentiation test. Being self-employed with no fixed hours explains fragmented mobile usage, and that chain of reasoning is what justifies the attribute.
• Ranked goals: two or three goals, in order, that the persona is trying to achieve with the solution. The ranking counts as much as the list, since it gives the order in which the solution must serve them.
• Motivations: why a persona interacts with the solution the way they do, which is distinct from what they are trying to obtain. Two claims handlers can share the same goal, closing a statement, one driven by speed and the other by fear of error, and the two motivations call for opposite screens. The Agile Extension makes this a field in its own right.
• Needs: finite, verifiable requirements (safety, trust, accessibility, written proof), which translate into acceptance criteria. The Agile Extension draws the boundary: needs are finite where wants are infinite, and a field that fills up without end is a field of wants.
• Frustrations: the friction points observed in the research, with their magnitude where it is measurable (a waiting time, a number of steps, an abandoned form).
• Behaviours, digital confidence and preferred channel: what the persona already does, with which tools and through which channel they want to handle the matter. This field carries most of the design consequences.
• Representative quote: one sentence taken from the research, which restores the voice of the segment and reminds the team that the card came from somewhere.
• Differentiators: what sets this persona apart from the others in the same pool. A persona that expects the same of the solution as its neighbour has no reason to exist separately.
• Narrative form: BABOK holds that the persona is written in narrative form and lets the reader see the story from the point of view of the stakeholder group. It creates empathy that way, where a segment sheet creates none. The Agile Extension adds the "day in the life" vignette, a short narrative that helps the reader picture the user and her experience. In practice it fits in three lines and places the moment the solution enters the persona's day. A run of filled-in fields informs; the narrative is what a team remembers three months later, in a design review.

One test governs the content of the card, and the Nielsen Norman Group states it: a detail earns its place if it changes a design decision or makes a trade-off easier, and it goes otherwise. Favourite colour, number of children and make of car fail that test almost every time. Applied field by field, it separates a usable card from a biographical note.

The differentiation test

The two IIBA guides diverge on socio-demographic attributes. BABOK describes the persona at element .4 of its section 10.43 without naming a single demographic attribute: the archetype there is centred on the goals of the group. The Agile Extension, at its section 7.7, prints them on the template: the short card carries age, occupation and location opposite the goals, the long card opens a "Demographics" field. In its Strengths section the guide states that demographic data, where it exists, is a good way to start building personas. The practitioner is therefore handed a template with age pre-printed on it, which explains how common the defect is.

The way out is in that same section 7.7. The Agile Extension names the differentiators field there and defines it by what sets this persona apart from another. Differentiator is IIBA's word for the criterion this test applies. The guide reserves that criterion for one field of the card; we apply it to all the others and to the demographic fields the same template pre-prints. The question is then put once per attribute: does this attribute separate behaviours, needs or goals, for this solution? When the answer is yes, name the mechanism. When it is no, the attribute leaves the card, however easy it was to collect.

The positive answer belongs to the practice itself. Cooper introduced the persona as an instrument of goal-directed design, and his three original personas were told apart by their goals, their tasks and their skill levels. The Nielsen Norman Group says what a cluster forms on: behaviours, attitudes, motivations, pain points and goals, to the exclusion of demographic characteristics such as age, country or income. A persona rests on a qualitative understanding of users rather than on dubious correlations between demographic or analytics variables. Clayton Christensen gave the argument its causal form: being 18 to 35 years old with a university degree does not determine a purchase; it may be correlated with the decision, but it does not cause it. The job the person is trying to get done causes the decision. His jobs to be done theory names that job.

The Nielsen Norman Group rules on age and income by name; the other verdicts are ours.

The operational rule that follows is ours: a demographic attribute returns to the card on the day it explains a behaviour it caused, and it is written there with that mechanism. The cluster forms on the observed behaviours, from which the design draws its screens and its flows.

Generations X, Y, Z and Alpha

The generational cohort is the attribute that resists the test best, because it looks as though it explains something. It fails on three independent grounds. The first, arithmetic, is enough on its own.

Period, age and cohort are bound by an identity, period = age + cohort, so a difference observed in a cross-section is consistent, to exactly the same degree, with an age effect (being thirty), with a period effect (the year of measurement) and with a cohort effect. Rudolph, Rauvola, Costanza and Zacher state it: no statistical model exists that can unambiguously identify generational effects, and as long as age, period and cohort are defined in time-related terms, they remain inextricably confounded. The same paper notes that the boundaries of the labels vary by three to nine years across studies, so two pieces of work on "millennials" are not about the same people.

The second ground is measurement. The meta-analysis by Costanza, Badger, Fraser, Severt and Gade (2012), twenty studies and 19'961 subjects, compares four generations on job satisfaction, organisational commitment and intent to leave: the corrected differences are negligible and change sign depending on the pair compared. Three years later, Costanza and Finkelstein find little solid empirical evidence of a generational difference and almost no theory that would explain why one should exist; a 2025 meta-analysis finds the same void, and the discipline has published the concept's obituary, which files it among the managerial fads.

The third is institutional. The Pew Research Center, the polling organisation whose data fed the labels, announced in May 2023 that it would run generational analysis only where historical data allows generations to be compared at similar stages of life. The same release states that it will control for age effects, period effects and demographic composition before attributing anything to a cohort. It describes a crowded field, carrying content "that is often sold as research and that is closer to clickbait or marketing mythology".

Then there is the version business analysis meets in a workshop: the digital native is said to cope alone, so the app will do. The Nielsen Norman Group put that stereotype through usability testing, with participants born between 1986 and 1997, and all three beliefs fall. They do not replace voice contact with digital channels; they supplement it. They multitask more often, without doing it better. And their grasp of how the web works is everyone else's. Cohort does not predict digital skill, which can be observed.

The way out lies in the Agile Extension's own sentence, which offers "generational or experiential" differentiators: leave the first half and take the second. "Born in 1998" separates nothing. "Has managed her insurance online since 2019, has never posted a paper form" separates, can be checked and produces a design consequence. The literature that dismantled the construct proposes the same thing: treat age as a continuum and ask what a person has lived through and what they do.

An experiential differentiator is collected with a question of fact: "tell me about the last time you handled a statement, from the first thing you did to the last". The dated episode gives a device, a channel and a moment; the habit a person reports gives their opinion of themselves. The answer is worth keeping when it names a fact that can be placed: the year of the move to the portal, the last paper form posted, the tool that replaced the previous one. The check is one question put to the card before the line is written on it: could this differentiator be contradicted by usage logs? When it cannot, the line is a self-portrait and it leaves the card.

The Sinus-Milieus

The SINUS-Institut (Heidelberg and Berlin) has spent more than forty years building a two-axis segmentation of society. The vertical axis is social situation, from the upper class to the lower class. The horizontal axis is basic values orientation, from tradition (duty, order) to individualisation and modernisation, then to the more recent reorientations. A milieu gathers people who share comparable values and a comparable social position. Date of birth enters neither axis, and that is what makes the model relevant here: it separates on measured values.

The Swiss edition, built in 2002, was rebuilt in 2024 on the basis of a representative online survey run in August 2023 with 2'036 respondents aged 16 to 75, across all the language regions. It holds ten milieus, which the institute names in German: the Konservativ-Arrivierte (13%) and the Nostalgisch-Bürgerliche (12%) are the largest, and the Progressive Realisten (6%) appeared with the 2024 revision. A microgeography product gives the milieu distribution and the purchasing power per Swiss postal code.

A milieu segments a population; a persona is the archetype of the users of one solution. The milieu carries a person's values, media use and communication preferences, and it stays silent on what they want from the claims portal. It therefore enters the research. It frames recruitment: sample the interviews so that the milieus which bear on the solution are present, a criterion that separates behaviours where an age bracket does not. It supplies a coverage check after clustering: which milieus does the pool leave out, and is that omission a decision or an accident? That check catches a pool made up entirely of people who resemble the project team. And it gives a sourced answer for the preferred-channel field, which is too often guessed.

The analyst states two limits to the client. The model is commercial and licensed: the basic information package is bought; the microgeography, the workshops and the certifications are priced separately; deeper work goes through licensed partners. A buyer takes it as given and does not audit it, and a published critique charges the institute with a lack of methodological transparency. And it moves the sorting into categories without removing it: a milieu is a better category than a generation, since it is measured on values rather than on a year of birth. Pasted onto a card in place of an observed behaviour, it fails the same test. A milieu model or a CRM segmentation answers the question "which segment do we address and on which channel", where the persona answers what a user wants from the solution.

Building the pool

1. Frame the population and the granularity
   Name who the solution serves, then set the granularity on the recurring reason that brings a person to the solution: one persona per distinct reason. The granularity chosen determines the number of personas obtained at step 4.
2. Run the research
   BABOK names the interview and the survey. The order matters: qualitative first (semi-structured interviews, field observation), which surfaces attitudes and motivations, then quantitative (survey, analytics) to validate the reasons observed and measure their weight. Analytics alone shows what people do without ever saying why, and a persona built on analytics alone stays hollow.
3. Cluster
   Gather the observed goals, attitudes and behaviours into clusters. A cluster forms on a difference in behaviour towards the solution: two people of the same age in the same canton can belong to opposite clusters, and two people with nothing biographical in common can form a single one.
4. Merge and cut
   Merge the clusters that ask the same thing of the solution, drop the ones the research supports too weakly. A pool of three to five personas stays memorable and therefore usable.
5. Write the card
   Short card first, long card only where a decision commits the organisation. Every field passes the decisive-detail test before it is written, and the narrative vignette is written last, once the goals are ranked.
6. Rank the pool
   Order the personas by the benefit they will draw from the solution design, which the Agile Extension states explicitly. The ranking criterion is announced before the ranking is made: a benefit criterion and a usage-volume criterion give different orders, both defensible. A rank that does not say what it rests on records the team's preferences. The rank then settles matters dispassionately when two personas want incompatible things.
7. Keep the cards alive
   Put them back in front of the team at every design review and every refinement session, in the form "which of our personas does this proposal serve and at what rank". This is the step where most persona efforts die and the only one that pays back the previous ones.
8. Revise
   Date every card and revisit it when the market, the product or the segment moves. A persona ages, and an expired card does not say so.

The provisional persona and the labelling rule

The two IIBA guides contradict each other on the central point of the technique. BABOK states that personas are created "based upon knowledge rather than opinion": research precedes the archetype. The Agile Extension concedes the opposite in its Strengths section: when the data is missing it is sometimes necessary to invent personas from little more than a few dry facts about the intended end users, provided a representative pool is still identified.

The contradiction turns on the label the card carries. A provisional persona, dated, carrying the word "hypothesis" and the list of the research that will confirm it, is a legitimate way to align a team: it gives the team a common object to contradict, and the first interview will correct it. The same card without the label is the defect the technique exists to prevent.

The Interaction Design Foundation names the four families of personas: the goal-directed persona, the role-based persona and the engaging persona all come out of research, while the fictional persona is drawn from the team's assumptions. The first three ship as results. The fourth ships as a hypothesis, and it carries the date on which it will be verified or abandoned.

The label is a banner on the card, "unvalidated hypothesis, research planned, N interviews, due date", and the card loses that banner only on the day the research is done. The discipline costs nothing. Its absence costs the credibility of the whole pool, because one invented and undeclared card casts doubt on every card that was not invented.

The persona in a data initiative

IIBA's Guide to Business Data Analytics (§3.16) uses the persona for a differentiator that marketing does not keep: what the person can do with data. A persona built for a dashboard carries how they consume and produce data, their familiarity with analysis and the form in which a result becomes usable to them. Those three traits drive design decisions: the level of aggregation, the choice of charts, how often the result is made available.

A gap in analytical familiarity justifies two personas only when it changes what is delivered to them. Where it changes nothing, it belongs in a column of the stakeholder list.

What makes the exercise fail

Undeclared invention

A card written from what the team believes it knows looks exactly like a card that came out of research: same template, same first name, same quote. Presented as a result, it inverts the premise of the technique, since it gives opinions the authority of knowledge and freezes them in an artefact nobody will contest again. The countermeasure is procedural: every claim on a card traces back to its source in the research, and a card whose interviews cannot be produced carries the hypothesis banner or stays in the drawer.

The demographic caricature

"Woman aged 25 to 54, graduate, interested in wellbeing" lines up attributes, none of which separates a behaviour, and the defect sits in each attribute taken on its own. Narrowing the age bracket to five years would give a narrower card and an equally mute one. The differentiation test is therefore run attribute by attribute. A card whose lines drive no design decision is a marketing segmentation lodged in the wrong template, which the Nielsen Norman Group counts among its five documented causes of failure.

The pool that fragments

Nobody memorises twelve personas born of a wish to spare everyone's feelings inside the organisation, and the team falls back on its imaginary user. Two personas that call for the same design are one persona.

The card written and never reopened

This failure is the most frequent and the most expensive: the Nielsen Norman Group ranks it first among its five causes of persona failure, and the whole research spend is already committed when it happens. It is prevented by writing the persona into an existing ritual: the name of the persona served appears in the definition of every backlog item, and a design review opens with the card on the wall.

Construction in a silo

Personas developed by the research team alone, then presented as a finished deliverable, land as an outside judgement, and the Nielsen Norman Group makes this its third cause of failure. Bringing stakeholders into the clustering session costs half a day and buys the support that will decide whether the cards are used later.

Absent sponsorship

A leadership team convinced that it already knows the user does not yield to a card, whatever the quality of the research behind it. The Nielsen Norman Group ranks this cause second, just behind the card that is never used. Sponsorship is therefore checked before the research is committed to.

The card too polished to be revised

A document laid out like a brochure discourages correction and becomes wrong. An editable, dated, versioned format is corrected on the day an interview contradicts a frustration.

AI considerations

The strongest point of application is synthesis. Twelve semi-structured interviews produce several hours of transcript and hundreds of open-ended survey answers, and clustering that material by hand is slow and gets more uneven as the analyst tires. A language model extracts the goals, frustrations and channels mentioned, proposes candidate clusters and cites the passages that ground them. The analyst then works on a first draft to validate, correct and cut. One check makes this use acceptable: every proposed cluster must be traceable to the excerpts that support it, and a cluster with no excerpt is deleted.

The model also drafts wording variants of the same card for a team review, which speeds up settling a text several people have to accept. And it applies the decisive-detail test field by field, asking of each field which decision it informs, a systematic review task where the machine is more consistent than a human at the end of a session.

Since Cooper, the technique has drawn its authority from research conducted with real users, and a persona asked of a model with no interview or survey behind it produces exactly the artefact the technique exists to prevent: a plausible fiction, indistinguishable from a card built out of interviews, empty of the evidence that would make it trustworthy. The Nielsen Norman Group tested these "synthetic users", which are generated profiles that mimic a user group and supply artificial research results produced without studying anyone. It judges them too shallow for most research activities: one-dimensional answers, missing behavioural nuance, systematic agreeableness towards whatever the researcher expects. The same article concedes one use, developing proto-personas later refined with real participants, and it states the principle that makes it acceptable: treat any synthetic output as a hypothesis to be validated by real research. That is the labelling rule, applied to the machine.

Interview transcripts routinely carry sensitive data within the meaning of the FADP, on health, financial situation or family circumstances, and interviews in the insurance sector carry it almost every time. Anonymisation precedes any transfer to an external synthesis tool, and the consent obtained at the interview explicitly covers that processing.

Examples

The technique's deliverable is a filled-in persona card. The five techniques in the 10.43 family share the same case: a Swiss caisse-maladie digitising its claims handling, with a self-service portal for the insured and automated intake of invoices from healthcare providers.

The rank 1 goal, knowing the out-of-pocket amount before booking, calls for a running count of the deductible consumed and the co-payment reached, kept up to date and readable without a long authentication. The measured frustration, three weeks between sending and a statement she cannot reconcile with what she paid, calls for status tracking of the file and a statement that follows the invoice line by line. Those requirements come out of the pairing of goal and frustration, which is how a persona is read. The differentiation test runs on the card itself: "34" drives no line on the card, whereas being self-employed with no fixed hours drives the fragmented mobile usage and the CHF 2'500 deductible drives the rank 1 goal.

A single persona would mislead. The pool holds four, and its ranking is the technique's second deliverable. Sandra Bieri, 41, a claims handler, processes around 120 statements a day from a fixed workstation: the solution gains her speed on a task that is already tooled. Yann Rochat, 52, a self-employed physiotherapist in Vevey, submits close to 180 invoices a month from his practice-management software, which already sends them electronically: all the solution takes off him is the telephone follow-up of rejected invoices. Markus Wyss, 58, rarely uses healthcare and wants written confirmation he can understand and file: he handles two or three statements a year and will keep paper, so the solution removes almost no friction for him.

The insurer chose expected benefit from the design, measured as the share of current friction the solution removes. Nadia takes rank 1, the only one to receive a capability that exists nowhere today, then Sandra, Yann and Markus, by decreasing friction removed. A usage-volume criterion would have put Sandra at rank 1, just as legitimately.

An average persona merging the two insured members would produce a 46-year-old member, moderately at ease with digital tools, indifferent to channel, and the design that followed would serve neither Nadia nor Markus.

Visualisations

The persona card is a spatial artefact. The layout carries the reading hierarchy, and a reader with only ten seconds has to come away with the rank 1 goal.

The pool has its own visualisation, distinct from the card: one row per persona in rank order, the announced criterion at the head of the table, the friction removed stated for each. A reader sees at a glance why the rank is what it is, which no single card shows.

Every zone of the card earns its place by informing a named decision, and the table below applies the rule zone by zone before a card is frozen. The differentiation test goes into the first of those zones, "Identity and context", attribute by attribute.

Cost

Tooling

No purchase gates the technique. An interview guide shared in an ordinary document frames the data collection and guarantees the same questions are put to everyone, the condition of honest clustering. A video-conferencing tool with recording and automatic transcription covers remote interviews, which run as well as they do in person. A spreadsheet or a deck of cards is enough to cluster the observations. A collaborative whiteboard (Miro, Mural, FigJam) makes that step workable with distributed stakeholders, who then take part in the clustering itself. The card itself lives in a document or slide template, provided it stays editable and can carry the hypothesis banner for as long as the research is outstanding.

Persona authoring tools, canvases and card generators, are worth it for an organisation that produces personas repeatedly across several products and wants a consistent form. A research repository centralises transcripts, survey answers and coded excerpts, which allows a persona to be re-derived or revalidated later without redoing the fieldwork; it pays for itself as soon as the organisation runs enough studies to lose track of the earlier ones. Analytics and CRM segmentation tools, finally, validate the clusters quantitatively: they measure the real weight of the reasons observed in interviews and correct an overestimated cluster. The Nielsen Norman Group states their limit: personas built on analytics alone miss the attitudes and motivations, so these tools confirm a qualitative hypothesis already formed. Licensed milieu models, the Sinus-Milieus and their equivalents, are used the same way: they frame the recruitment of the sample and flag the milieus a pool leaves out.

Sources

• IIBA, A Guide to the Business Analysis Body of Knowledge (BABOK Guide) v3, §10.43 Stakeholder List, Map, or Personas (element .4 Personas): definition of the persona, the rule of knowledge rather than opinion ("knowledge rather than opinion"), interviews and surveys as the elicitation techniques, the narrative form of the card.
• IIBA, Agile Extension to the BABOK Guide v2, §7.7 Personas: short and long templates, motivations, finite needs, differentiators, ranking of personas by expected benefit from the solution design and the admission that personas are invented from a few dry facts when data is missing.
• Cooper, A., The Inmates Are Running the Asylum (Sams Publishing, 1999): the origin work of the technique, which introduces the persona as an instrument of interaction design.
• Nielsen Norman Group, Personas Make Users Memorable (Taylor Dykes): definition, structure of the card and the decisive-detail test ("if it would not affect the final design or help make any decision easier, remove it").
• Nielsen Norman Group, Why Personas Fail (Kim Flaherty): the five documented causes of failure, in order: the persona created but never used, the absence of leadership sponsorship, construction in a silo, the communication failure about what a persona is and a fundamental flaw in the persona itself.
• Nielsen Norman Group, Synthetic Users: If, When, and How to Use AI-Generated "Research": an assessment of AI-generated user profiles, their limits, the conceded use of proto-personas to be refined later with real participants and the rule of treating any synthetic output as a hypothesis to be confirmed by real research, which is where the label the provisional persona carries comes from.
• Interaction Design Foundation, Personas – A Simple Introduction: the four families of personas, goal-directed, role-based, engaging and fictional (drawn from team assumptions).
• Nielsen Norman Group, Personas vs. Archetypes (Page Laubheimer, 2022): a cluster forms on behaviours, attitudes, motivations, pain points and goals, to the exclusion of demographic characteristics such as age, country or income.
• Nielsen Norman Group, 3 Persona Types: Lightweight, Qualitative, and Statistical (Page Laubheimer, 2020): a persona rests on a qualitative understanding of users, rather than on dubious correlations between demographic or analytics variables.
• Nielsen Norman Group, Millennials as Digital Natives: Myths & Realities (Kate Moran, 2016): the digital-native stereotype put through usability testing and refuted on all three of its points.
• Rudolph, C. W., Rauvola, R. S., Costanza, D. P., & Zacher, H. (2021), Generations and Generational Differences: Debunking Myths in Organizational Science and Practice and Paving New Paths Forward, Journal of Business and Psychology 36(6), 945-967, DOI 10.1007/s10869-020-09715-2: the identification problem between age, period and cohort, as well as the instability of the labels' boundaries.
• Costanza, D. P., Badger, J. M., Fraser, R. L., Severt, J. B., & Gade, P. A. (2012), Generational Differences in Work-Related Attitudes: A Meta-analysis, Journal of Business and Psychology 27(4), 375-394, DOI 10.1007/s10869-012-9259-4: twenty studies, 19'961 subjects, no meaningful generational difference in work attitudes.
• Costanza, D. P., & Finkelstein, L. M. (2015), Generationally Based Differences in the Workplace: Is There a There There?, Industrial and Organizational Psychology 8(3), 308-323, DOI 10.1017/iop.2015.15: little solid empirical evidence and almost no theory.
• Ravid, D. M., Costanza, D. P., et al. (2025), Generational differences at work? A meta-analysis and qualitative investigation, Journal of Organizational Behavior, DOI 10.1002/job.2827: the most recent meta-analysis and the same result.
• Rudolph, C. W., & Zacher, H. (2022), Generations, We Hardly Knew Ye: An Obituary, Group & Organization Management 47(5), 928-935, DOI 10.1177/10596011221098307: the generational construct as a managerial fad and the lifespan-development alternative.
• Pew Research Center, How Pew Research Center will report on generations moving forward (Kim Parker, 22 May 2023): the polling organisation publicly restricting the use of its own generational labels.
• Nobel, C., Clay Christensen's Milkshake Marketing (Harvard Business School Working Knowledge, 2011): the causal formulation, being 18 to 35 with a degree is correlated with the purchase decision and does not cause it.
• Christensen, C. M., Hall, T., Dillon, K., & Duncan, D. S., Know Your Customers' "Jobs to Be Done" (Harvard Business Review, September 2016): the canonical statement of jobs to be done, where the cause of the decision is the job to get done.
• W3C Web Accessibility Initiative, Older Users and Web Accessibility: the real mechanisms of ageing (vision, dexterity, hearing and cognition), the one case where age is itself the mechanism.
• SINUS-Institut, Sinus-Milieus Switzerland: the model, its two non-demographic axes (social situation and basic values orientation) and the ten Swiss milieus.
• SINUS-Institut, Sinus-Milieus Schweiz: Update 2024: the 2024 revision, its August 2023 survey of 2'036 respondents aged 16 to 75 and the milieu that appeared with it.
• Ilg, W. (2014), Sinus-Milieu-Studien: Viel genutzt, kaum hinterfragt, Zeitschrift für Pädagogik und Theologie 1/2014, p. 68 ff.: the published critique charging the model with a lack of methodological transparency.
• Cooper, A., Reimann, R., Cronin, D., & Noessel, C., About Face: The Essentials of Interaction Design (Wiley): the goal-directed design method, of which the persona is the instrument.
• IIBA, Guide to Business Data Analytics, §3.16 Stakeholder List, Map, or Personas: the persona in a data initiative, carrying data consumption, familiarity with analysis and the usable form of a result.