RESPONSIVE DESIGN REVIEWS · TABLET WORKFLOW

Tablet Review Workflow for Agency Clients

Most agencies nail mobile and desktop reviews — then ship to clients without ever opening a tablet. This guide gives your team a repeatable, structured tablet review stage so nothing slips through the cracks.

📖 Part of the WordPress Feedback for Responsive Design Reviews pillar guide.

Why Tablet Gets Skipped — and Why That’s a Problem

The mobile-first mindset has done a lot of good for web design — but it quietly created a blind spot. Teams design for 375px phones and 1440px desktops. Tablets live in the middle, and they’re easy to deprioritise when deadlines are tight.

Yet tablet usage consistently accounts for 8–12% of web traffic across most industries — higher in e-commerce, education, and healthcare. For agency clients, that’s a meaningful slice of their audience. Shipping a layout that breaks at 768px isn’t a minor bug; it’s a visible quality failure.

The real issue isn’t that teams don’t care about tablets — it’s that there’s no formal review stage for them. Mobile gets a QA pass. Desktop gets client sign-off. Tablet gets “it looked fine in the browser dev tools.” That’s not a workflow; it’s a hope.

8–12%

Average tablet share of web traffic — higher in e-commerce and education sectors.

3 Breakpoints

Mobile, tablet, and desktop each need a dedicated review pass — not just a resize in DevTools.

1 Approval Stage

Tablet sign-off should be a formal, documented step in your client approval process.

What a Proper Tablet Review Actually Covers

A tablet review isn’t just “does it look okay at 768px?” It’s a structured audit across layout, typography, interaction, and content integrity. Here’s what your checklist should include:

Layout & Grid

Column stacking behaviour at 768px and 1024px
Navigation collapses correctly (hamburger vs full nav)
Hero image/text ratio doesn't break or overlap
Sidebars collapse or reflow as intended
Card grids don't produce orphaned single columns

Typography & Readability

Font sizes are legible without zooming
Line lengths don't exceed ~80 characters
Headings scale proportionally between breakpoints
No text is clipped, hidden, or overflows its container
Buttons and CTAs have adequate tap target size (44×44px min)

Images & Media

Images scale without distortion or cropping focal points
Videos and embeds maintain correct aspect ratio
Background images cover their containers correctly
Gallery layouts don't produce awkward gaps

Forms & Interactions

Form fields are full-width and easy to tap
Dropdowns and date pickers are usable with touch
Hover states have a touch equivalent (focus/active)
Modals and popups don't overflow the viewport

The 5-Stage Tablet Review Workflow

Treat tablet review as a named, scheduled stage — not a last-minute check. Here’s the process we recommend for agency teams.

Define Tablet Scope

Agree which breakpoints to test (768px, 1024px) and which real devices or emulators to use before work begins.

Internal QA Pass

Your developer or QA lead runs through the full checklist on a staging build. Document every issue with screenshots and element references.

Fix & Re-test

Resolve all flagged issues, then run the checklist again. Don’t skip the re-test — fixes often introduce new regressions.

Client Review Round

Share the tablet-specific staging link with the client. Provide a simple feedback form scoped to tablet view — not a general feedback session.

Formal Sign-Off

Client approves tablet view in writing — separate from mobile and desktop sign-off. This is your documented approval gate.

How to Share Tablet Previews with Clients

One of the biggest friction points in tablet review is getting clients to actually look at the right thing. If you send a staging link and say “check it on your tablet,” you’ll get feedback about the desktop version they opened on their laptop.

A better approach is to use a tool that lets you present the page at a fixed viewport width — so the client sees exactly what you want them to review, regardless of the device they’re on. This is where purpose-built WordPress review tools earn their keep.

Best practices for tablet client previews:

Send a viewport-locked preview link set to 768px or 1024px width
Include annotated screenshots of the key pages for clients who won't click through
Scope the feedback form to tablet-specific questions only — don't mix with desktop feedback
Record a short Loom walkthrough of the tablet layout to guide the client's eye
Set a clear deadline for tablet feedback — separate from the overall project timeline

Common Tablet Layout Issues — and How to Catch Them Early

Experience shows the same categories of tablet issues appear on almost every project. Knowing where to look saves time in both QA and client review rounds.

The Awkward In-Between

Tablet layouts often inherit styles from both mobile and desktop without being fully optimised for either. A three-column desktop grid that collapses to a single mobile column may produce an odd two-column layout on tablet that looks unintentional. Always test the mid-range explicitly.

Navigation Collapse Timing

Many themes collapse the navigation to a hamburger at 768px — but on a 1024px tablet in landscape mode, the full desktop nav may appear too cramped. Define your collapse breakpoint deliberately and test both portrait and landscape orientations.

Touch Target Failures

Desktop designs often use small hover-triggered elements — dropdown menus, icon buttons, tooltip triggers — that are unusable with a finger. On tablet, every interactive element needs a minimum 44×44px tap target. This is one of the most common client complaints post-launch.

Making Tablet Sign-Off a Real Approval Gate

The final piece of the puzzle is accountability. Without a formal sign-off mechanism, tablet review remains informal — and informal means optional, which means skipped.

Build tablet approval into your project contract and your project management tool. It should appear as a named milestone: “Tablet Review — Client Approved” with a date and a name attached. This does three things:

It signals to the client that tablet is a first-class deliverable, not a bonus
It protects your agency from post-launch "the tablet looks broken" complaints
It creates a paper trail if scope disputes arise later

Use a dedicated feedback tool — not email — so every piece of tablet feedback is timestamped, attributed, and linked to the exact element the client is commenting on. When the client clicks “Approve” on the tablet view, that’s your gate. Everything after that is out of scope.

Frequently Asked Questions

Test at a minimum of 768px (portrait tablet) and 1024px (landscape tablet or small laptop). If your client’s analytics show significant iPad Pro usage, also test at 1280px. Always test both portrait and landscape orientations — they can produce very different layouts.

DevTools is good for catching layout and typography issues, but it doesn’t replicate real touch behaviour, font rendering differences, or browser-specific quirks on iOS Safari and Android Chrome. For client-facing projects, run at least one pass on a physical device. A mid-range iPad is sufficient for most agency work.

The most reliable approach is to use a review tool that locks the preview to a specific viewport width — so the client sees the tablet layout even if they open the link on a desktop browser. Pair this with a short screen recording walking through the tablet view, and most clients will engage properly.

Yes. Combining all three into a single “responsive review” round typically results in clients focusing only on desktop. Separate approval stages — one per breakpoint — ensure each view gets proper attention and creates clear accountability in your project records.

Navigation collapse timing is the most frequent issue — specifically, the breakpoint at which the desktop nav switches to a mobile hamburger menu. On tablets, this transition often happens at an awkward width that leaves either a cramped full nav or an unnecessary hamburger. Define this breakpoint explicitly in your CSS rather than relying on theme defaults.

Tablet review is one stage in a complete responsive feedback workflow. The pillar guide — WordPress Feedback for Responsive Design Reviews — covers how to structure the full process across all breakpoints, from initial design handoff through to final client sign-off.

Stop Treating Tablet as an Afterthought

Add tablet review as a named approval stage on your next project and you’ll ship more polished work — and have fewer post-launch conversations you didn’t want to have.

Read the Full Responsive Review Guide →

Part of the WordPress Feedback for Responsive Design Reviews pillar series.