Making Persona Review Part of Your Process

You've seen how personas work. You've used them to catch problems in your own work. The harder question is how to make this a regular practice instead of a one-time exercise.

Start small. Three to five personas representing populations your ministry actually serves — or populations who struggle with your current services — is enough to start. Resist the urge to cover every possible BC resident before you've used any personas at all.

In the first month, build your core personas from data you already have: service usage stats, consultation records, demographic information, feedback from frontline staff. Focus on diversity of access needs rather than demographic variety — a persona representing someone without reliable internet reveals different barriers than one representing someone without English fluency, even if both are "underserved."

In months two and three, put those personas to work on existing documents and services. Note which insights were most valuable. Revise your personas based on what you learn and share them with your team. In month four and beyond, add new personas as you identify gaps and build ministry-specific scenarios like the ones in Part 3.

The goal isn't comprehensiveness. It's usefulness.

None of this works if people can't find it. Keep your personas in a shared drive folder your team can navigate without asking for help — your core provincial personas (Margaret, James, Amira, and Dev from Part 2), any ministry-specific personas you've built, prompting templates you can copy and adapt, and examples from past reviews where personas identified real problems.

When someone joins your team or starts a new project, they should be able to find and use these resources in five minutes. If it takes longer than that, the folder structure is working against you. Once your library is in place, there are several ways this work typically goes wrong.

The most common mistake is confusing personas with stereotypes. If your persona feels like a caricature, go back to your data. "Old people don't like technology" is a stereotype. "Margaret has a smartphone but gets frustrated when apps don't work predictably" is a persona detail grounded in actual behaviour. The difference is specificity — and specificity is what makes personas useful.

A related mistake is using personas to skip consultation. They don't replace talking to actual people. What they do is help you prepare better questions and design better consultation processes. Think of this work as preparation for consultation, not a substitute for it.

Watch out for analysis paralysis. You don't need 20 personas, and you don't need to satisfy every possible user perfectly. Three to five personas representing your most underserved populations, focused on identifying major barriers, will catch most of what matters.

The pitfall that tends to bite later is set-it-and-forget-it. Demographics change. Technology access changes. Barriers evolve. Set an annual review date for your personas and update them when new demographic data releases or when a review reveals your persona missed something real.

One thing personas often flatten is intersectionality. People aren't just "senior" or "rural" or "newcomer" — they can be all three. A senior newcomer in rural BC faces different barriers than an urban senior or a rural resident who's lived there for decades. When you build or review a persona, ask what unique barriers might emerge from combinations of characteristics, not just individual ones.

The last one is easy to miss: generic prompting undermines even well-built personas. Using the same vague prompt for every review is one of the easiest ways to get generic results. Customize your prompts for the specific document, include relevant ministry context, and ask targeted questions based on what you actually need to know.

You'll know personas are working when your team starts referencing them in discussions without prompting — when documents get revised based on persona insights before finalization rather than after complaints, and when "we didn't think about that population" stops being a regular occurrence in your reviews.

Those are process signals. The outcome signals take longer but are more concrete: completion rates for forms and applications go up, post-launch accessibility complaints go down, and the equity section in your cabinet submission reflects real analysis rather than a box checked at the end.

None of this happens immediately. But it compounds. The ministry that builds this practice now is the one fielding questions from other ministries in two years.

Before You Finalize

Run through these six questions before you sign off on any major document, service, or policy: 1) Would this work without reliable high-speed internet? 2) Is the language accessible to people unfamiliar with government terminology? 3) Can someone complete this without traveling to a service location during business hours? 4) Does it work with screen readers and mobile devices? 5) Have we provided alternatives for people with different access needs? 6) Have we reviewed this through at least two different persona perspectives?

If you answered "no" or "I'm not sure" to any of these, you've found your next area for improvement.

The best persona reviews are ones you don't have to remember to schedule — they're already built into your normal process. When you draft a new policy, persona review is on your standard checklist. When you evaluate vendor proposals, persona-based questions are part of your evaluation criteria. When you plan consultation, personas help you identify who might face barriers to participating.

Thirty minutes during your draft review process catches most major issues. That's half an afternoon compared to weeks of post-launch fixes.

Start with one project. Pick one persona. Spend 30 minutes reviewing your work through their eyes and make at least one change based on what you find.

This series has covered why personas matter — and why technically sound work can still fail the people it's meant to serve (Part 1) — how to build personas grounded in real BC data rather than assumptions (Part 2), how to apply them across policy review, service design, and vendor evaluation (Part 3), and how to make them part of your regular process rather than a one-time exercise. The tools are there. The personas are there. What's left is using them.

The goal isn't serving everyone perfectly. It's serving more people better than you do now. Personas help you see where your work unintentionally creates barriers for people you're trying to help — and they help you see it while changes are still easy to make. Margaret, James, Amira, and Dev aren't hypothetical. They're in your service area right now, trying to access what you're building. The question is whether your work is ready for them.