How Should You Design a Partners Page That Actually Sends You Work?

How should you design a partners page that actually sends you work?

Design it for three readers at once: a prospect checking whether you work with the tools they own, a partner deciding whether to refer you, and a partner's customer who just clicked a link. Most partner pages serve only the first, badly, with a wall of logos and no way to act.

We build these pages for B2B companies and we have watched a lot of them underperform. The failure is almost never visual. It is that nobody decided what the page is for, so it became a place to put logos, and a logo wall is a decoration rather than a mechanism.

This is how we approach it now, including the parts that are uncomfortable to recommend.

Why do most partner pages do nothing?

Because they answer a question nobody asked. A grid of partner logos tells a visitor you have partners. It does not tell them whether you integrate with the thing they use, whether that integration is any good, or what happens next if it is.

Nielsen Norman Group's B2B usability research, published by Jakob Nielsen on 31 May 2006, found that B2B sites achieved only a 58 percent task success rate against 66 percent for mainstream websites. The study ran 79 participants across 179 B2B sites through 12 focus groups, 55 one on one sessions and 7 field studies. Its core diagnosis was internally focused design: sites built around how the company sees itself rather than what a visitor is trying to do.

A logo wall is that diagnosis in a single component. It is organised around your business development achievements. The visitor's question is something else entirely.

What are the three audiences and what does each need?

The prospect needs to confirm compatibility and see proof it works. The partner needs a page they are proud to link to, with correct positioning and assets they can reuse. The partner's customer, arriving cold, needs to understand who you are within about five seconds and find one obvious action.

These three needs conflict less than you would expect. All three want specifics rather than adjectives. All three want to see the integration or the relationship described concretely. All three are annoyed by a form standing between them and basic information.

What differs is entry point. The prospect arrives from your navigation. The partner arrives from a bookmark. The partner's customer arrives from an external link, often deep, often on a phone. Design for all three arrivals and the page gets simpler, not more complicated.

What should sit above the fold?

A sentence saying what kind of partnerships these are, a search or filter if you have more than about a dozen, and the single most important partner relationship you have. Not a hero image of a handshake. Not a headline about building the future together.

The filter matters more than teams expect. A visitor with a specific tool in mind wants to type its name, not scan a grid. If your list is long enough to need scrolling, it is long enough to need search, and that is a build decision rather than a design flourish.

Give the page a working heading that says the thing. Partners and integrations beats Ecosystem. The plainer word wins on a page whose whole job is matching a visitor's mental model to your list. Our piece on website navigation UX makes the same argument one level up.

What goes on an individual partner's page?

What the partnership actually does, in plain language, and what a customer gets from it. Then the mechanics: what is required to use it, what it costs if anything, and how to start. Then proof, meaning a real example rather than a testimonial about how great the relationship is.

We have built this pattern on client sites where each partner is a CMS entry, which keeps the detail consistent and lets a partnerships manager add one without a developer. That structure is the difference between a page that is current and one that quietly lists a partner you stopped working with in 2024.

The mechanics section is the part everyone skips and the part a serious buyer reads first. If using the integration requires a plan tier they are not on, say so on the page. Finding that out on a sales call wastes everyone's time and costs you trust.

Should pricing be on the page?

Where a partnership has a cost, yes. This is the clearest finding in the NN/g research and the most consistently ignored. When users were asked to prioritise 28 types of B2B information, they ranked price highest, 29 percent above product availability in second place. Most sites withheld it anyway.

The same research documented what happens when you hide information behind registration. Nielsen recommends moving information outside those barriers so prospects can research without surrendering contact details, establishing credibility before asking for personal information.

We understand why companies resist this. The counter argument is that a prospect who cannot find pricing does not call you, they call someone whose pricing they found. That study is from 2006 and this behaviour has only hardened since. Our piece on pricing page design applies the same logic to the main event.

What do partners actually need from the page?

Something they can send to their own customers without editing. That means your description of the partnership has to be accurate from their side too, not just flattering from yours. Partners notice when a page positions them as a feature of your product.

Give them assets in an obvious place: your logo in the formats they will need, a short and a long description of your company, and a correct one line description of the partnership. Every partner marketing team rewrites this from scratch otherwise, and every rewrite is a chance to describe you wrong.

Also give them a stable URL. Partner pages get rebuilt and the links in their collateral break silently. If you restructure, redirect properly. Redirect properly so their collateral keeps working, rather than letting the old URL 404 quietly.

What about the partner's customer arriving cold?

Treat that arrival as a landing page, because it is one. Someone clicked a link from a company they already trust. They know nothing about you. The page needs to establish what you do before it talks about the partnership, which is the reverse of how these pages are usually written.

One short line at the top does it. Say what you are, then say how you work with the partner they came from. Two sentences. Then the action.

Keep that action singular. A partner page with four competing calls to action converts on none of them. Pick the one that matches the relationship, whether that is booking a call, starting a trial, or reading the integration docs.

Does page speed matter on a page like this?

More than on most, because logo walls are image heavy and partner pages are often the first page an external visitor sees. Google's Core Web Vitals guidance sets the good thresholds at 2.5 seconds for Largest Contentful Paint, 200 milliseconds for Interaction to Next Paint, and 0.1 for Cumulative Layout Shift, measured at the 75th percentile of page loads.

Layout shift is the specific risk here. A grid of logos that loads without reserved space pushes content around as each image arrives, which is exactly what CLS measures. Set dimensions on every logo and the problem disappears.

The performance is achievable. On the Axis Align build we hold a 98 PageSpeed score with a 0.7 second load, and on Sachem Hill a 0.8 second median load time. Image heavy pages are not automatically slow. They are slow when nobody budgets for them. Our article on fixing cumulative layout shift covers the specifics.

How do you know if the page is working?

By tracking what people do next, not how many visit. A partners page with steady traffic and no onward action is a page that answered a question and ended the conversation. That is a design problem, not a traffic problem.

The signals worth watching are filter use, clicks into individual partner detail, and the single action you chose. If people filter and then leave, your list has a gap. If they never filter, your list is short enough not to need it, or the filter is not visible.

Ask your partners too. They will tell you plainly whether they send people to this page or to a document they made themselves. If it is the latter, that document is your brief.

What would we build first?

One well made partner detail page for your most important relationship, before you build the index. Get the structure right where it matters most, learn what information you actually need to collect from partners, then scale the pattern.

Building the grid first is the common order and it produces a template full of fields nobody can fill. Starting from one real, complete example tells you what the model should be, which is a much better position to build a CMS structure from.

If you want help designing a partner page that gives your partners something to link to, or turning a logo wall into something with a mechanism behind it, we are happy to walk through it. Find us at phoenix.studio.