The kickoff deck has a slide that says “We design mobile-first.” Another agency’s plan starts with a full desktop homepage and promises phone layouts later. Either way, you will be asked to approve designs in a certain order, and that order decides what you see before you sign off.
Choose the starting view that exposes the project’s hardest design problem early, then schedule the other views. A phone-first project can leave desktop decisions vague, while a desktop-first project can leave the phone layout to the last week. The three approval stages below keep either gap visible.
This guide is about planning and approving a redesign. If the page is already built and you need to review it, the pre-launch checklist walks you through that.
Agree on Three Approval Stages
Whichever view leads, ask for these three checkpoints in the project plan. They describe what to see before each sign-off, not a test plan for the finished site.
- Before detailed design: agree on the main visitor task for each key page and what core content matters most. For example, on a gym’s site that might be booking a trial class, then the timetable, then prices.
- Before approving a visual direction: see how that direction handles both a phone and a desktop layout, and ask the team to point out anything that behaves differently on a tablet.
- Before final approval: check that every layout and interaction deferred earlier has now been designed, such as the phone menu, a long form, or a comparison table.
Online Website Previewer previews live pages from their address, so you can use it on the current site before stage one. Comparing today’s phone and desktop layouts side by side shows where the existing site struggles, which is useful evidence for choosing a lead view. During the three stages you are mostly looking at design files, so ask the team to present the views together.
What “Mobile-First” Means, and What It Doesn’t
The phrase gets used in three ways, and only the first one is about your approval process.
As a design strategy, mobile-first means planning the experience for smaller screens first. Luke Wroblewski, whose Mobile First post set out the idea, argued that the constraints of a phone force a team to focus on what matters most.
As a way of writing the code, it means building the single-column phone layout first and adding layouts for larger screens on top. MDN describes this mobile-first approach, and frameworks such as Bootstrap and Tailwind CSS are built around it. You don’t need to manage this choice, but it explains why developers use the term.
Mobile-first indexing is a Google search term. It describes how Google reads sites, and it says nothing about the order in which your team designs.
Mobile-first design also doesn’t mean phone-only. Nielsen Norman Group found that when sites carried a phone-style hidden menu over to desktop, visitors used the desktop navigation less. Its conclusion was that porting an unchanged design to a different platform hurts the experience. Ask to see the desktop layout as a design in its own right, not as a stretched phone screen.
Does the Builder’s Editing Order Decide Your Approval Order?
There is no single official definition of desktop-first, but website builders document it clearly. Webflow calls it best practice to start designing on the desktop breakpoint, then move down. In Wix Studio, desktop design “trickles down” to smaller layouts. Elementor describes its responsive editing as top-down.
The code frameworks mentioned above work the other way, from phone up. A tool’s default editing direction can shape a team’s habits, but it doesn’t decide which designs they present to you first.
So don’t infer the approval order from the tool. Ask which view the team will design and present first. If the site will be built in Webflow or Elementor, ask how the phone layout will be shown at stage two. If a developer builds with a mobile-first framework, ask when you will see the wide layout designed rather than filled in.
Which View Should Lead This Project?
There is no universal winner, and neither order guarantees better results on its own. Pick the starting view that brings the project’s hardest problem to the surface early.
- Most of the key journey happens on phones, and you have evidence for that: consider leading with the phone. Ask early to see what content comes first, how the menu works, and where the main action sits.
- The main task needs a lot of side-by-side information, such as a plan comparison: consider leading with the wide layout. Ask early for an explicit plan for how that comparison will work on a phone.
- Phone and desktop visitors come for different things: design both key experiences early, and agree what stays consistent between them.
- You don’t know which view should lead: compare rough phone and desktop versions of the main task before approving a polished direction. Ask the team which version exposes the harder layout or content decision.
Whichever view leads, the layout will change at certain widths along the way. The breakpoints guide explains what should decide where.
Keep Design Order Separate From Review Order
The design order is how the team develops the solution. The review order is how someone checks the finished page. They are separate decisions.
Once the new design is running on a staging or live page, use the pre-launch checklist to plan the finished-page review. Keep those checks separate from the design approvals agreed here.
Put the Agreement in Writing
Once you have chosen a lead view and the three stages, write them into the brief or the project plan. A short line saves a late surprise: “Desktop leads. We will review the phone layout of the homepage and the pricing page alongside the desktop visual direction, before approving it.”
When you send feedback at stage two, say which view the note covers. For example: “Before approving this direction, I need to see how the comparison table and the inquiry form work on a phone.”
If the brief also uses words like “responsive” or “mobile-friendly,” the responsive vs mobile-friendly guide helps you check that everyone means the same thing.
