Personas Aren't a Research Artifact. They're an Architectural Input.

When personas live as research, the website ends up describing the product. When personas live as architecture, the website ends up describing the fit.

A lot of marketing teams treat personas as a research artifact.

A doc. A slide in the Q1 strategy deck. A workshop output from the offsite. Useful at the start, archived by month three, irrelevant by month six. The persona work happens, gets celebrated, and then quietly stops being load-bearing on any decision the team actually makes.

I don't think that's what personas should be.

A buyer persona is a specific representation of one type of buyer: their job to be done, their hesitations, their decision-making style, and the language they use when they're in the market. Not a demographic average. Not a job title. One specific person, given a name, whose motivations were drawn from real buyer interviews and real customer patterns.

Personas aren't just research. They're an architectural input. They're the variable that decides which problem your home page leads with. Which proof point sits above the fold. Whether the about page is built for the buyer who's in a hurry, the buyer who needs to be convinced, or the buyer who has to convince someone else.

When personas live as research, the website ends up describing the product. When personas live as architecture, the website ends up describing the fit. Those are different websites. Different conversion behaviour. Different kinds of trust.

That's the difference. Most teams have the first kind, and most can't tell. There's no obvious moment where the failure happens. The website just slowly stops working for the buyer it was supposed to convert.

Two Ways Persona Work Fails

There are two ways to fail at persona work, and they're easy to confuse.

The first is the research artifact failure. A team does the interviews, builds the personas, ships a 40-slide deck, and then the whole thing becomes shelf ware. The personas exist. They just don't act on anything. By the time the home page goes through its next quarterly refresh, the persona doc hasn't been opened in eight months. The rewrite happens based on whoever in the room remembers the most about who the customer is. The persona is a one-time deliverable that decays. The failure isn't that the research was wrong. It's that the research was never operationalized.

The second failure is structural, and it's the one this piece is really about.

As a marketing architect, I think about this the way a building architect thinks about load-bearing walls. There's a difference between the architecture of a building and the decoration applied to it. You can repaint a room. You cannot reposition a beam without redesigning the structure around it. Most of what gets called "marketing" is decoration. Copy iterations. A/B testing. Design refreshes. Hero rewrites.

However, the architecture is the sequence of decisions about which problem the page solves, in which order, for which buyer, with which proof. If the architecture is wrong, no amount of decoration fixes it. The page just looks better while continuing to convert the wrong person.

Foundations before facade. That's the architect's order. Personas belong at the foundation, in the sweet spot where Persona, Positioning, and Product meet.

How Personas Drive Page Architecture

How a Buyer Persona Changes Your Homepage Architecture

Here's what changes when personas move from research to architecture.

The persona decides which problem the home page leads with. Every business solves more than one problem. A local home services company might solve "my basement keeps flooding and the insurance deadline is tomorrow" and "I want to renovate before my in-laws visit at Christmas." Both are real. Both are true. Only one of them is the problem that woke your best buyer up at 3 a.m. and made them open a browser. The persona is what tells you which. When personas are a research artifact, the home page leads with whichever problem the founder finds most interesting, or whichever the team built capability for most recently. When personas are architecture, the home page leads with the problem the buyer is already searching for a solution to.

The persona decides which proof point sits above the fold. A page can carry the same set of trust signals (client logos, certifications, case studies, testimonials, founder credentials) and arrange them in radically different orders. The buyer in a hurry reads logos first and skips everything else. The analytical buyer scans for certifications and dismisses the testimonials as noise. The emotional buyer wants the before-and-after photos and the founder story. When personas are a research artifact, proof order gets argued in meetings based on whoever has the loudest opinion. When personas are architecture, proof order is a function of which doubts the specific buyer arrives with, and which proofs answer those doubts directly.

The persona decides what the CTA says, and where it sits in the page sequence. "Book a call" is a different commitment than "see the spec sheet" is a different commitment than "request a sample." A buyer who hasn't yet validated whether you meet their basic criteria will not book a call. That's the wrong commitment for the stage they're in. A buyer who has already validated the basics finds "download the spec sheet" insulting, because they want to talk to a person. The persona decides which commitment matches the moment.

The persona decides what the about page exists for. Some pages on a website will almost always have to be a little Frankensteined: home, about, contact, FAQ. They serve multiple buyers by structural necessity. The mistake isn't that they exist. The mistake is when those pages mix every buyer into a single paragraph instead of giving each one their own section. The about page can hold company history and founder story and mission statement, but it should do so in clearly labelled sections, deliberately ordered so each buyer can find theirs. When personas are a research artifact, the about page is whatever the founder wrote in year one and never revisited. When personas are architecture, the about page is a structural decision: this section exists because this specific buyer needs this specific piece of context before they'll take the next step.

The deeper architectural move is this: most of your website should NOT be Frankenstein pages. Most of it should be use-case pages, application pages, industry pages, persona pages. Each one talking to one specific buyer about one specific job to be done. The Frankenstein pages handle the entry traffic. The persona pages handle the conversion.

Notice the pattern. The persona isn't deciding the copy of any of these elements. The persona is deciding the sequence, the priority, and the existence of each element. That's an architectural function. It's the order things go in, what supports what, which decisions get made first.

This is the kind of pattern PersonaAudit scores against systematically. But you can see it in your own home page right now, without any tool, if you read the page as one specific buyer instead of as the average of all of them.

A note on naming. Many teams work with ideal customer profiles (ICPs) rather than personas. The two aren't identical. An ICP typically describes company-level fit; a persona describes the individual within it. But for page architecture, both demand the same question: which specific buyer is this element for? The language shifts by team. The architectural question doesn't.

The Five Buyer Archetypes (And Why They Change What Your Page Needs to Say)

What Is a Buyer Archetype?

A buyer archetype is a recurring decision-making pattern, defined not by industry or job title, but by how they decide. The archetype tells you how the buyer makes decisions. The persona tells you what they specifically care about. You need both: the archetype gives you the decision logic, the persona gives you the content.

Most personas worth building map onto a small set of these archetypes, defined by their job to be done and their decision style. The names vary by industry, but the archetypes recur:

• The buyer in a hurry. Has a deadline, needs to act now, doesn't have time to read your full story. Reads to confirm you can solve their problem fast.

• The analytical buyer. Wants the specs, the comparison, the proof. Reads to verify your claims survive scrutiny.

• The emotional buyer. Wants to feel that you understand them and that working with you will be a relief. Reads to feel the texture of what working with you is like.

• The consensus buyer. Needs to convince someone else, whether a partner, a boss, or a board. Reads to find the line they can quote to the person they need to convince.

• The skeptical buyer. Has been burned before. Reads to find the reasons NOT to trust you, and decides based on what you don't try to hide.

These archetypes apply to almost any product, in almost any industry. A home services buyer in a hurry shops differently than a home services buyer who's been planning the project for two years. A fitness program buyer who wants their body back before their wedding shops differently than one who's rebuilding after an injury. Same product. Different architecture required.

Three Patterns to Look For

Three architectural anti-patterns show up over and over. Each has a structural cause and a structural fix.

The Frankenstein Hero

A hero section written for nobody in particular because it was written for everybody.

The headline addresses the analytical buyer's need for specifics. The sub-headline was added after sales said "we need to talk about results." The third line was a compromise after the founder asked for the awards logos higher. The result is a hero that names a problem one buyer has, then immediately undercuts it with a benefit a different buyer cares about, then closes with a piece of social proof a third buyer would scan for. Each buyer arrives, sees the line that's for them, and then has to forgive the next two lines to keep reading.

• Structural cause: the hero was built by committee, not by persona.

• Structural fix: the hero leads with one buyer's problem in their language, and the secondary buyers get served in clearly labelled sections further down the page, or on dedicated entry points.

The Mismatched Proof Hierarchy

A page whose proof points are present but ordered against the actual buyer's decision-making sequence.

Client logos appear above the fold for a buyer who needs the case study first. Case studies appear before any explanation of what the product is, so the case studies have no anchor to attach to. Testimonials from one buyer archetype appear on a page that's supposed to convert a different one. The proof is there. The proof is irrelevant in the order it's been placed.

• Structural cause: proof gets added to the page in the order the team acquires it (newest case study at the top), not in the order the buyer needs it.

• Structural fix: proof is sequenced to match the order in which the buyer's doubts arise.

The Average-Buyer About Page

An about page that tries to be company history, founder story, mission statement, and team credentials simultaneously, because at some point each of those was the answer to "what should the about page do?" and nobody ever subtracted.

The page is long. The page is sincere. The page reads as a composite of every internal stakeholder who has ever cared about the brand story. No specific buyer reads it and thinks this was written for me.

• Structural cause: the about page accumulates content but never gets architected.

• Structural fix: the fix isn't necessarily to pick one buyer and trim the rest. For pages that have to serve multiple buyers, the fix is to give each archetype their own clearly labelled section, deliberately ordered, so each one can find theirs and skip the others.

In each case, the diagnosis isn't "the copy is bad." The diagnosis is the page has the wrong architecture for the persona you're trying to convert, and you can rewrite the copy infinitely without fixing it. The copy rewrite has to be downstream of the architectural decision, not a substitute for it.

The Strongest Objection

The strongest objection comes from marketers who've actually run multi-persona traffic at scale. The argument runs:

Real buyers don't fit one persona. Your traffic is 60% Persona A and 30% Persona B and 10% Persona C. If you architect the home page entirely for A, you lose B and C. And B is half your pipeline. The home page has to do multiple jobs, and that's not a Frankenstein, that's a router.

That objection is partially right, and it sharpens what Frankenstein actually means.

Most products attract more than one persona. Even if every visitor shares the same job title, they have different motivations, different decision styles, different things that move them. A multi-persona website isn't the failure mode. The failure mode is when those personas get mashed into the same paragraph, the same hero, the same CTA. That's the Frankenstein. The page has the multi-persona structure hidden inside copy that reads as a compromise across all of them.

Architecture-by-persona doesn't mean a single persona owns the entire page. It means the architecture is built around a sequence of decisions, each made with a specific persona in mind, rather than as the average of all personas. A home page can absolutely have sections that speak to each persona and invite them to choose their own next step. That's a deliberate router. Each section talks to one persona cleanly. Each section invites that persona forward into a page that talks only to them.

The enemy isn't the multi-persona website. The enemy is the average of all personas. The Frankenstein customer who doesn't actually exist anywhere in your real customer base.

The first version (the router) is architecture. The second version (the average) is decoration applied to a structural problem.

What to Do This Week

Open your home page. Read the hero as if you were your single best buyer, the one you'd hand-pick from your last 50 customers. Notice what they would skim past. Notice what they would pause on. Notice what they would have to forgive. Then read it as your second-best buyer and notice where the page stops working for them.

You don't need a 40-page persona doc to start. You need one specific buyer, named, with their hesitations written down. And a willingness to ask, of every page element: is this here because that buyer needs it, or because someone on the team wanted it?

The questions are architectural. The answers tell you what to keep and what to cut.

This is the foundation. The next piece in the series goes one level down, into what happens when the persona work gets skipped entirely, and the page ends up addressing a composite buyer who doesn't exist anywhere in the real customer base. There's a name for that page. It has a cost. The next piece is about both.

PersonaAudit is this tool that I built to do this systematically: to score a page against a specific persona and surface where the architecture is working and where it isn't.

Frequently Asked Questions

What does it mean to treat a persona as an architectural input?

It means the persona decides structural questions about your website. Which problem the home page leads with. Which proof sits above the fold. What the CTA commits to. What the about page is for. The persona acts as a constraint on every page-level decision, not as a research deliverable that gets archived after launch.

Why do personas become shelf ware?

Because they're built as deliverables, not as decision-making inputs. A persona that lives in a 40-slide deck gets celebrated at the offsite and forgotten by month three. No one checks the persona before the home page rewrite. No one asks which buyer the new hero is written for. The persona becomes read-only, and then unread. The fix isn't a better document. It's treating the persona as a constraint on every page-level decision, the way an architect treats a load-bearing wall.

What's the difference between a persona and a target market?

A target market is a category of people (homeowners, fitness program shoppers, small business owners). A persona is one specific person within that category, with named hesitations and a decision-making style. You can build a website for a target market by averaging. You cannot build one for a persona without choosing.

What's the difference between a buyer persona and an ideal customer profile?

An ideal customer profile (ICP) typically describes company-level fit: the right industry, company size, buying stage, and budget. A buyer persona describes the individual within that company: their job to be done, hesitations, decision-making style, and the language they use when they're searching for a solution. You need both: the ICP tells you which companies to target, the persona tells you how to talk to the person making the decision. For page architecture, it's the persona that does the work. A page can't be written for a company, only for a person.

What are buyer archetypes and how do they relate to personas?

Buyer archetypes are the recurring decision-making styles that show up across industries: the buyer in a hurry, the analytical buyer, the emotional buyer, the consensus buyer, and the skeptical buyer. Every persona maps onto one or more archetypes. The archetype tells you HOW the buyer decides. The persona tells you what specifically they care about. Both shape the page architecture.

Isn't writing for one persona just narrowing my audience unnecessarily?

When the page is architected around a sequence of persona-specific decisions, secondary buyers still get served by the rest of the architecture. A deliberate router page can address multiple personas in clearly distinct sections. The failure mode being named is the page that addresses an average buyer, a composite of all personas mixed together inside the same hero, the same paragraph, the same CTA.

What is the Frankenstein Hero?

A hero section assembled from competing stakeholder inputs. A headline written for one buyer archetype, a sub-headline added for another, a third line compromising for the founder's preferred proof. The result is a hero where every buyer has to forgive the lines that aren't for them. The structural cause is committee design. The fix is leading with one buyer's problem and serving others in clearly labelled sections elsewhere.

How do I know if my home page has the wrong architecture?

Read the page as one specific buyer, the single best customer you'd pick from your last 50. Then read it as your second-best buyer. If both readers have to forgive sentences, skim past sections, or reach the CTA without their core doubts addressed, the architecture is wrong. The copy might be fine. The order, priority, and existence of each element is what's broken.

Do I need a formal persona document to do this?

No. You need one specific buyer named, with their hesitations written down, and a willingness to ask of every page element: is this here because that buyer needs it, or because someone on the team wanted it? The discipline matters more than the document.