Persona
12
Target specific users with SaaS Persona patterns. Discover how to segment your marketing message by showing tailored benefits for 'Managers,' 'Developers,' or 'Founders' in a single view.
Figma file available
.webp)
Related patterns
A persona section helps a visitor recognize where a product fits their role, organization, or working situation. It translates a broad proposition into a more specific answer: what can this help someone like me accomplish? The most useful sections connect audience labels to actual differences in needs, workflows, evidence, and next steps.
This pattern is different from a decorative row of job titles. Naming developers, founders, and enterprises can make a page seem inclusive without explaining anything. A convincing persona section shows why those audiences need different information while preserving a coherent account of the same product.
Choose an audience distinction that changes the argument
Start with the differences that matter to evaluation. A developer may need implementation detail, while a department lead may need visibility into operations. An agency managing several clients may need an account structure that a single internal team does not. Those distinctions give the section a reason to exist.
Avoid segmenting only because several labels are popular in SaaS marketing. If every audience receives the same paragraph with a different title, the categories are not doing useful work. Ask what question each group is trying to answer and what proof would help them answer it.
Keep the level of classification clear. Roles, industries, company stages, and use cases are different dimensions. They can appear on the same page, but a visitor should not have to decide whether being a developer prevents them from also choosing the startup category.
Ground a persona in its working context
The Peec AI capture explicitly identifies agencies. Its text connects that audience with pitching new business and serving clients, while the adjacent product image shows a workspace list with different relationship labels. The composition links the audience to a multi-client working context rather than relying only on a generic agency badge.
The visible onboarding action also reflects that audience. This is the useful relationship to study: audience, workflow, product evidence, and next step reinforce one another. The screenshot does not establish current service capabilities, customer relationships, or onboarding behavior; it shows how the captured page presents them.
When adapting this approach, use an interface detail that substantiates the audience claim. A multi-project selector can support a claim about managing several engagements. A generic dashboard image may offer little explanation of why an agency would use the product differently from an internal team.
Separate role needs from organization needs
The Prelude capture uses a six-cell grid. The top row names leadership, developers, and department heads; the bottom row names startups, scale-ups, and enterprises. Each cell has its own short description. The first row is organized around roles, while the second is organized around company stage or scale.
This arrangement makes several entry points visible without requiring interaction. It also asks the design to clarify that these are overlapping perspectives, not mutually exclusive user types. A developer at an enterprise may find both cells relevant. Separate group headings or a clear visual hierarchy can make that relationship easier to understand.
Use the two dimensions only if both help visitors evaluate fit. Otherwise, a smaller set of focused audience cards may be clearer. More categories can broaden apparent coverage while weakening the specificity of the promise in each category.
Write around outcomes and constraints rather than stereotypes
Describe what the audience needs to accomplish, which constraints shape that work, and how the product addresses them. A developer's paragraph might discuss integration and diagnosing problems. A manager's paragraph might discuss oversight and coordination. Avoid treating a role as a personality type or making unsupported assumptions about everyone who holds it.
Make the differences concrete enough to survive removal of the heading. If a reader cannot identify which audience a paragraph serves without seeing its label, it may be too generic. Replace interchangeable claims about efficiency with an explanation of the relevant task or decision.
Use language the audience recognizes without making other visitors feel excluded. A persona section can provide a route into more detailed material; it does not need to contain all specialist vocabulary on the main page. Define an unfamiliar concept when it is necessary to understand the benefit.
Give each audience a meaningful route forward
The next step should match the uncertainty raised by the section. Developers may want documentation or an integration example. An agency may want a multi-client workflow demonstration. An enterprise evaluator may want a detailed discussion of administration, procurement, or deployment options.
Avoid sending every audience card to the same generic signup page while implying that each route contains tailored information. A shared destination can be appropriate when it genuinely serves all audiences, but the label should describe what the visitor will find there.
Do not require visitors to declare an identity just to understand the product. Audience navigation can be helpful without becoming a gate. Someone exploring several roles should be able to compare perspectives and return without losing their place or being forced into a permanently selected persona.
Choose a grid, tabs, or dedicated section deliberately
A grid makes categories available for comparison and supports scanning. It becomes less useful when each category needs a long explanation. Tabs reduce visible content, but they also hide alternatives and add interaction. Dedicated sections can give an important audience more substantial proof while making the page longer.
Choose according to the amount of difference between audiences. If the same product capabilities support all groups with only a different emphasis, concise visible cards may be sufficient. If the workflows differ substantially, a tabbed detail area or separate landing pages may provide a clearer account.
For interactive layouts, preserve a recognizable active state and operable controls. A screenshot of a visible grid does not demonstrate the behavior of tabs in another implementation. Evaluate the actual component with keyboard use, narrow screens, and long translated labels before deciding that the pattern is complete.
Keep claims consistent across audience paths
Tailored copy should not produce contradictory accounts of the product. A feature described as available to one audience should have a clear relationship to plan eligibility or configuration. Do not imply that the same capability is included everywhere simply because the audience section omits those details.
Maintain a shared source of truth for the underlying claims and allow the emphasis to vary. If a capability changes, review all audience pages that describe it. Persona sections can become stale independently when each one is maintained as a separate marketing story.
Also check terminology. The main navigation, audience cards, destination pages, and product interface should not use several incompatible names for the same workflow. A visitor who follows an agency route should be able to recognize the corresponding concept when they reach the product.
Make audience selection understandable on small screens
Stacked cards should retain their grouping and hierarchy. If roles and company stages appear in separate rows on desktop, those relationships can disappear in a single mobile column. Use meaningful group labels when the classification matters, rather than depending entirely on position.
Keep labels readable and avoid treating icons as the only way to distinguish categories. A crown or code symbol may support a label, but it should not require interpretation before the visitor can identify the relevant content. Links need a clear destination purpose and a visible focus state.
If a selected audience changes content, make the change apparent without unexpectedly moving the visitor to another part of the page. Preserve access to other choices and ensure that hidden content does not leave confusing links in the focus order.
Test recognition and fit rather than category clicks alone
Ask visitors to explain which audience path seems relevant and why. A click does not prove that the classification made sense; it may indicate that someone was searching for a less ambiguous explanation. Watch for people choosing several categories because none provides a recognizable working context.
Then test the destination. Can the visitor find the information the persona section promised? Does the workflow evidence support the audience-specific claim? Does someone with overlapping roles have a practical way to compare paths without repeating a qualification form?
Use the SaaSFrame persona collection to compare audience grids with focused audience sections. Look for references whose segmentation reflects a meaningful difference in work, then adapt the copy, evidence, and next action to your actual users.
Questions to resolve before adding a persona section
Should personas be based on role or company size? Use the dimension that changes what the visitor needs to evaluate. If both matter, group them clearly and acknowledge that they can overlap.
How many audiences should be shown? Show the audiences you can describe specifically and support with evidence. A long list of interchangeable claims is less useful than a smaller set of recognizable working situations.
Does every persona need its own page? No. A short section can be enough when the differences are modest. Create a dedicated route when the audience needs substantial additional proof, workflow detail, or a different next step.