The Personas Library

When I joined Freddie Mac in late 2025, the team had a personas library. Technically.

In practice, it was a set of static graphic sheets created by a third-party consulting firm in 2020. Five years old, incomplete, and largely untouched. The kind of thing a new hire might scan on their first week, then never open again. Traditional personas in the classic sense: stock photo, name, age, job title, a little fictional vignette. Carly, 36, Underwriting Analyst. That sort of thing.

The myOptigo platform serves Freddie Mac Multifamily and has more than 30 distinct user types. 30 personas is a lot to keep current, consistent, and actually used.

When the team set their 2026 goals, updating the personas library was near the top of the list. The question was: update them into what?

The real problem wasn't that the personas were old. It was that the format itself made them almost impossible to actually use.

A refreshed set of static sheets would have the same problem in another five years.

I came to my manager with a different thesis: what if the personas weren't a designed artifact at all, but a structured data library — readable by a human, queryable by an AI, and maintainable over time without starting from scratch every few years?

The format I proposed was YAML. Plain text, structured enough for an AI to parse, simple enough for a designer to update. Each persona would live as its own README-style file following a standardized schema. Feed those files into a Copilot Notebook, and anyone on the team — designers, POs, developers, even business stakeholders — could query the library in plain language. "What are the main pain points for an Underwriting Analyst?" Done.

My manager liked it. The design system manager liked it. They asked me to present it to the broader team.

I drafted an initial schema myself, drawing on the standard building blocks of a traditional persona: job responsibilities, pain points, goals, tools used, key workflows. Then I brought it to the team.

We ran a FigJam whiteboarding session where I presented the vision and asked a simple question: if you could query a persona, what would you want to know? The feedback shaped the final schema — by the end, it reflected what the team actually needed, not just what I'd assumed.

For the research itself, I used Microsoft Teams Copilot, which has access to internal documentation available across the organization. I used a consistent prompt for every persona — same structure, same questions — asking Copilot to generate a research report covering core responsibilities, pain points, goals, and role context. The persona list itself came from my manager through her own stakeholder conversations.

The Copilot reports were dense. The YAML files are not. That compression was intentional — the schema keeps only what someone would actually need when making a design or product decision.

The library currently covers roughly half of the 30+ personas in the myOptigo ecosystem. Each lives as a structured YAML file, and together they're loaded into a Copilot Notebook that any team member can query today.

It's in beta. It works. People can use it.

The next phase is validation — user interviews with people from each represented role to verify that what Copilot surfaced actually reflects their day-to-day reality. The schemas will be updated based on what we learn.

• User validation interviews — the most important next step. Real conversations will catch the gaps that no internal document captures.
• Completing the full library — the schema and process are established; it's a matter of working through the remaining personas.
• Broader rollout — the longer-term vision is opening the library to POs, developers, and business stakeholders across the platform.
• Maintenance model — establishing a lightweight process for keeping schemas current as the platform evolves.

The goal was never to produce a prettier version of what existed before. It was to build something the team would actually reach for.