Team Page Design: How to Display Team Photos Without It Looking Broken

Good team page design starts with one decision made before a single photo is uploaded: pick one aspect ratio, crop every portrait to the same safe frame, and build the layout around that constraint. Most team pages don't look broken because the photography is bad. They look broken because the crop, the grid and the file sizes were never standardized.

What follows is the full working spec — layout patterns, cropping maths, compression targets, interaction behavior, accessibility, and the unglamorous governance questions like what to do when someone refuses a photo or leaves the company. It's written for the marketing and web people who have to ship the page and then maintain it for three years.

The five ways team pages actually break

A team page fails in a small number of predictable ways, and almost none of them are about photographic talent. The recurring culprits are mismatched crops, drifting backgrounds, a grid that reflows into an awkward orphan row, uncompressed files that tank the page, and a roster nobody has touched since two hires ago.

• Inconsistent crop distance. One person is framed from the chest up, the next from the waist up. Side by side at the same rendered size, the second person's head renders noticeably smaller. Nothing else on the page can compensate for this.
• Inconsistent background and color temperature. Warm office window light next to cool grey studio grey next to a beige hallway. The grid reads as a collage of found images rather than one company.
• Layout that assumes a tidy headcount. A four-column grid with 13 people leaves a single stranded card. Nine people in a three-column grid looks intentional; ten does not.
• Weight. Thirty portraits at 400 KB each is 12 MB of images on one page. On mobile that is a slow render and a Core Web Vitals problem before you've served a word of copy.
• Rot. Two people who left last quarter are still smiling at prospects, and the person who joined in March isn't there at all. This is the failure mode that damages credibility most, and it's pure process.

Notice that four of the five are solvable at spec time, for free. Only the first one requires you to go back to the photos — and even that is mostly a cropping job rather than a reshoot, provided the originals have enough resolution to crop into.

Grid, list, or something in between

Layout choice should follow from headcount and from what a visitor is meant to do on the page. A grid optimizes for scanning a group; a list optimizes for reading about individuals. Choosing the wrong one is why some team pages feel like a yearbook and others feel like an endless scroll of near-identical rows.

The grid: best for 8 to 60 people

The grid is the default for a reason. It communicates scale, it's trivially responsive, and it puts equal visual weight on everyone. Keep the card content minimal — photo, name, role, and at most one link — because a grid with four lines of bio per card stops being scannable and becomes a wall.

• Use CSS grid with auto-fit and a minimum column width rather than a hard column count, so the layout degrades gracefully from four columns to two to one without media-query gymnastics.
• Decide in advance how the last row behaves. Left-aligned stragglers look fine; centered stragglers look like a mistake unless you center them deliberately and consistently.
• Keep card heights equal. Variable-length job titles are the usual cause of ragged cards — either clamp titles to two lines or give the text block a fixed min-height.
• Order by something defensible: leadership first then alphabetical, or purely alphabetical by first name. Ordering by tenure or perceived seniority within teams creates internal politics you don't need.

The list or row layout: best for under 8 people, or for depth

When each person genuinely needs a paragraph — a professional services firm, a boutique agency, a founding team — alternate photo-left and photo-right rows and let the bio breathe. A list also lets you use a wider crop, which is more forgiving than a square and reads as more editorial.

Hybrid and segmented pages: best above 60 people

Past a certain size, one flat grid stops helping anyone. Segment by department or office with clear headings, and consider showing leadership in a richer row layout at the top with everyone else in a dense grid below. If you add filtering, make it a real control — a set of buttons or a select element — not a hover-revealed menu.

One warning about very large pages: if you're rendering 200 portraits, paginate or lazy-render. Loading 200 images into the DOM to satisfy a design instinct is a performance decision disguised as a layout decision.

Aspect ratio and the safe crop: why circles decapitate people

This is the single highest-leverage section on the page. Every rendering problem you've seen — a forehead sliced off, a chin at the bottom edge, a face floating in the top corner — comes from the same root cause: a photo cropped for one shape being displayed in another, with the browser making the decision for you.

Portraits are usually delivered in a vertical ratio such as 4:5 or 3:4, framed head-and-shoulders with the eyes roughly a third of the way down. A square (1:1) container has to remove height from that frame. A circular mask then removes the corners as well, which is where the top of the head lives. Stack those two operations and a perfectly good portrait loses its crown.

The safe-crop rule

Define one delivery ratio and one crop rule, then apply both to every image before it ever reaches the CMS. There is no standards body for this, so treat the following as a house rule rather than a specification: the eye line sits between 33% and 40% from the top of the frame, and there is at least 8% of the frame height as clear space above the head.

• Pick 1:1 if your design uses circles or squares. Crop to square at source, with the extra headroom above, rather than letting CSS square a 4:5 file at display time.
• Pick 4:5 or 3:4 if your cards are vertical rectangles. This is the most natural portrait ratio and needs the least intervention.
• Never mix. If some photos are square and some are 4:5, the container will crop the odd ones out and you'll get exactly the mismatched-scale effect described earlier.
• Keep a master file at 2x or higher. You want room to re-crop when the design changes in eighteen months, and you will need a second crop for Slack, the CRM and the conference speaker page anyway.

The CSS that does the work

Three properties handle almost every case. Set an explicit aspect-ratio on the image container so the browser reserves space and doesn't shift layout as images arrive. Use object-fit: cover so photos fill the box without distortion. Then use object-position to nudge the visible region upward, because portrait subjects sit above center.

The default value of object-position is 50% 50% — dead center, which is exactly the wrong place for a face. Overriding it to something like center 30% is a one-line change that fixes most crop complaints. For the handful of photos that still sit badly, expose a per-person focal-point field in the CMS rather than editing files — it's faster and it survives future redesigns.

Two things to avoid: object-fit: fill, which stretches faces, and setting a fixed pixel height on the image without a matching width constraint, which is the other classic way to squash people. If a photo still looks wrong after all this, the source crop is wrong and no CSS will rescue it.

Consistency: what actually has to match

Teams often over-specify consistency and then fail to enforce the things that matter. Nobody notices that two people were shot with different lenses. Everyone notices when one background is white and the next is a bookshelf. Rank your requirements by how visible the mismatch is at thumbnail size in a grid.

In descending order of visibility: background tone, crop distance, color temperature, lighting direction, then wardrobe formality. Our guide to choosing headshot backgrounds covers the first of those in depth, and the plain-English lighting guide explains why two photos with the same background can still feel like they belong to different companies. If you're briefing people who will be photographed in different cities, our playbook for distributed team headshots is the operational companion to this article — that one is about producing the photos, this one is about displaying them.

The durable fix is written guidelines that a new hire's photographer, or the new hire themselves, can follow without a call. We publish a copy-paste company headshot guidelines template for exactly this, and pairing it with a week-one onboarding step is what stops the grid from drifting one hire at a time.

On retouching, set a ceiling and say it out loud in the guidelines. Consistent, restrained retouching reads as professional; heavy skin work on half the team and none on the other half reads as a mismatch — our piece on how much retouching is too much gives you defensible limits to hand a retoucher.

Hover, modal and click patterns that don't break on touch

Interaction is where team pages quietly exclude people. The two common patterns — reveal a bio on hover, or open a profile in a modal — both work fine on a desktop with a mouse and both can fail completely on a phone, a tablet or a keyboard. Design the fallback first, then add the flourish.

Hover has no reliable equivalent on touch. The CSS hover media feature exists precisely for this: it reports none when the primary input mechanism cannot conveniently hover, which is the case on most phones and tablets. Gate hover-only enhancements behind that query, so pointer-capable devices get the effect and everyone else gets the content displayed by default.

• Never put information behind hover. Names and roles are always visible. Hover may change a shadow, a scale or a color — decoration only.
• Make the whole card a link if it goes anywhere. A tiny link under a large photo is a poor touch target; aim for a comfortably sized tap area.
• If you open a modal, use the native dialog element. Opened with showModal(), it promotes the dialog to the top layer, makes the rest of the page inert, gives you a styleable backdrop and closes on Escape — none of which you then have to reimplement badly.
• Give the modal an accessible name, move focus into it on open, keep Tab and Shift+Tab inside it, and return focus to the trigger on close. Those four behaviors are the baseline the ARIA Authoring Practices Guide sets out for a modal dialog.
• Decide what a shared URL does. If someone can link to a specific person, that person needs a real URL — either a deep-linked hash the page reads on load, or a standalone profile page.

A useful test: turn off your trackpad and navigate the finished page with the Tab key only. If you can't reach every person's information and get back out of every overlay, the pattern isn't done.

File specs and compression targets

A team page is one of the most image-dense pages on a corporate site, which makes it a disproportionate performance risk. The goal is straightforward: keep the whole grid under a couple of megabytes on a wide desktop viewport, and considerably less on mobile, while keeping faces sharp at the size they're actually displayed.

Start from rendered size, not from the file you were given. If a card renders a portrait at 320 CSS pixels wide, you need roughly 640 pixels of image for a 2x display — not the 4,000-pixel original. Serving the original and letting the browser scale it down is the most common and most expensive mistake on these pages.

1. 1Export three widths per person — for example 320, 640 and 960 pixels wide at your chosen ratio — and wire them up with srcset and a sizes attribute so mobile devices download the small one.
2. 2Use modern formats. Google's own compression study puts lossy WebP at 25–34% smaller than a JPEG of equivalent SSIM quality, and AVIF compresses photographic content smaller again. Keep JPEG as a fallback where your stack still requires one.
3. 3Set a per-image budget and enforce it. For a grid thumbnail, 30–60 KB is a realistic target; for a large row-layout portrait, 80–150 KB. If a file is over budget, the crop is usually too large, not the quality setting too high.
4. 4Lazy-load everything below the fold with the loading attribute, but never lazy-load the image likely to be your Largest Contentful Paint element. Google's guidance is explicit that lazy-loading the LCP image always introduces unnecessary resource load delay — and LCP counts as good at 2.5 seconds or less, measured at the 75th percentile of page loads.
5. 5Always set width and height attributes (or an aspect-ratio in CSS) so the browser reserves the space and the page doesn't jump as thirty portraits arrive at slightly different times.
6. 6Serve through an image CDN or build-time pipeline so that a marketer uploading a 6 MB phone photo can't silently break the page.

One more habit worth adopting: name files predictably — lastname-firstname-square-640.webp — rather than DSC_4471_final_v3.jpg. Two years from now, the person doing the redesign will need to match 40 files to 40 people, and predictable names are the difference between an afternoon and a week.

Alt text and the rest of accessibility

Alt text on a team page is one of the rare cases where the right answer is genuinely contested, because the correct value depends on what's already in the markup. The W3C's own images tutorial sets the principle: the text alternative has to be determined by the usage, context and content of the image, not by describing the picture for its own sake.

On a typical card where the name and role are visible text next to the photo, the photo is largely redundant. Two defensible options exist, and both are better than what most sites do:

• Treat the photo as decorative with an empty alt attribute, when the person's name and role are already adjacent readable text. W3C guidance reserves a null alt for images whose only purpose is visual decoration rather than information — which is arguably the case here, and it means a screen reader user hears the name once rather than twice.
• Use the person's name and role when the image is itself the link to their profile and no adjacent text repeats it. The alternative for a functional image should describe the function or destination, not the picture.
• Avoid the filler patterns: "headshot", "team member", "photo of employee", or the file name. They add noise and no information.
• Don't describe appearance. Age, ethnicity, body type and perceived gender are not yours to publish on someone's behalf, and they don't help anyone understand the page.

Accessibility on this page extends past alt text. Check color contrast on names and roles, which are often set in a light grey that fails at small sizes. Make sure headings step down properly if you segment by department. And confirm that any card-level hover animation respects a reduced-motion preference — a grid where forty photos scale and lift on scroll is genuinely unpleasant for some users.

While you're in the markup, consider adding Person structured data for each team member, with the job title and the employing organization. Be clear-eyed about what it buys you: a staff grid is not one of the page types Google lists for rich results, and its ProfilePage markup is aimed at author and creator profiles rather than a company roster. What Person markup gives you is a clean machine-readable statement of who works for you — useful for entity understanding, and cheap to add once your CMS already holds the fields.

When someone declines a photo

Some people will say no, and a few have serious reasons: safety concerns, an ongoing personal situation, religious observance, or simply a strong dislike of being photographed. A team page that pressures those people into visibility is both an HR problem and, in Europe, a data-protection one. Plan the opt-out into the design instead of improvising it.

Under the GDPR an employer needs a lawful basis to publish an identifiable employee photo. Legal guidance in this area generally distinguishes operationally necessary images, such as a security badge, which can rest on legitimate interests, from "nice to have" images such as a website team page, which fall to consent. Where consent is the basis, it is only valid if the employee suffers no disadvantage for refusing, and it can be withdrawn afterwards. The practical implication for a web team is that your layout has to look intentional with placeholders in it, because you will have some.

• Design a real placeholder, not a broken state. A monogram tile using the person's initials in your brand palette, at the same aspect ratio as the photos, reads as a design choice. A grey silhouette icon reads as an error.
• Keep the name and role. Omitting the person entirely is worse than showing them without a photo — it makes them invisible to colleagues and customers.
• Offer a middle option. Some people who won't sit for a photo are fine with an illustrated avatar, a back-of-head working shot, or a photo cropped further out.
• Make removal a self-service request with a named owner and a deadline — for example, removed within five working days of asking — and say so in your internal guidelines.
• Keep a record of who consented and when. A column in the same sheet that tracks the roster is enough, and it's what lets you show which basis you relied on if anyone asks.

One design consequence worth stating plainly: if you expect more than a couple of placeholders, do not build a layout where every tile is a full-bleed photo with text overlaid on it. That pattern collapses without an image. A card layout with the photo in a fixed-ratio slot above the text degrades cleanly.

Keeping the page current after departures

The team page is the most reliably stale page on a corporate website because it is the only one whose accuracy depends on events outside the marketing team. Nobody files a ticket when a person leaves. Solve it with ownership and a trigger, not with good intentions and a calendar reminder that gets snoozed.

Two mechanisms work. The first is to hook the page into your existing offboarding checklist, so "remove from website team page" sits next to "revoke SSO" and gets done in the same hour. The second is a standing monthly reconciliation between the HR roster and the published page, owned by one named person, that takes ten minutes when the first mechanism is working.

1. 1Add a website line to onboarding and offboarding. Onboarding produces a photo and a bio; offboarding removes both.
2. 2Store the roster as data, not as hand-built HTML. A CMS collection or a simple structured file means removing a person is one record deletion, not a hunt through markup.
3. 3Decide what happens to a departed person's URL. If they had an individual profile page, redirect it to the team index rather than leaving a 404 or, worse, a live page.
4. 4Check for orphan references. Departed employees are often still quoted on case studies, listed as blog authors, or embedded in a press page.
5. 5Set a display-date or review-date field on the page so you can tell at a glance when the roster was last reconciled.

Departures also create a photo debt: you now have a grid with gaps that need to be filled at the pace of hiring rather than at the pace of an annual photo day. That mismatch is exactly why a lot of teams end up with a mixed grid — a few polished studio photos surrounded by cropped phone snaps.

Filling gaps between photo days

Between organized shoots you have three realistic options for a new joiner: send them to a local photographer, coach them through a self-shot portrait, or generate one. Each has a different failure mode, and picking the wrong one for your situation is how grids become inconsistent in the first place.

A local photographer gives you the best individual result and the worst consistency across cities, unless you brief them tightly on background, crop and lighting. A self-shot portrait can look genuinely good with a window and a plain wall — our DIY method walks through it — but quality varies with the person's patience. An AI headshot generator gives you a consistent background and crop across everyone, which is the specific problem a grid has, but it produces a portrait that is a rendering of the person rather than a photograph of them, and it can struggle with unusual glasses, textured hair and fine jewellery.

Be honest internally about that trade-off rather than pretending it doesn't exist. We've written a direct comparison of AI headshots and hiring a photographer that lays out where each one wins. The deciding criterion is usually scrutiny: a leadership page whose photos get reused in press coverage and conference programs justifies a real shoot, while a 60-person engineering grid nobody inspects at full size is a different calculation entirely.

Whichever route you take, the acceptance criteria are the same as everything above: correct ratio, correct crop distance, background within tolerance, file under budget. Write those four lines into the brief, whether the brief goes to a photographer, to the new hire, or to a piece of software. A grid stays coherent because somebody specified it, not because everyone independently happened to make the same choices.

The pre-launch checklist

Before the page ships, run it against a short list. Most of these take under a minute each and every one of them catches a defect that is embarrassing to fix in public. Print it, put it in the ticket, and make it a required step for any future redesign of the same page.

• Every photo uses the same aspect ratio and the same crop distance, verified by looking at the grid at thumbnail size rather than at each file individually.
• No head is cut off at any breakpoint, including the awkward tablet width where the grid changes column count.
• Total image weight for the page is within budget on both desktop and mobile viewports.
• Width and height (or aspect-ratio) are set on every image; no layout shift on load.
• The likely LCP image is not lazy-loaded, and everything below the fold is.
• The page is fully navigable and readable with the keyboard alone, and every modal returns focus correctly.
• Alt attributes follow one consistent rule across all images, not a mix of three.
• Placeholders for people without photos look designed, and names and roles are present for everyone.
• The roster matches the HR list as of today, and a named person owns the next reconciliation.

A team page is a small piece of design with an unusually long tail of maintenance. Get the ratio, the crop rule and the ownership right at the start, and the page stays credible for years with almost no effort. Skip them, and you'll be re-cropping forty photos by hand the week before a funding announcement.