Building Alternate Designs Side by Side So the Client Can Choose

Design decisions are where many website projects stall. The client looks at a static mock-up, finds it hard to imagine in use, asks for changes, and the cycle repeats. On a corporate website for a freight forwarding and logistics company, we took a different approach: we built alternate page designs side by side as real, working pages, so the client could compare them in the browser and choose.

The project

The site presents the company's services and its story:

• A service catalog covering ocean freight, project forwarding, export packing and contract management, each with a breakdown by industry.
• Company, history, leadership and facilities pages.
• News, jobs and gallery sections.
• Client showcase pages.

It was built with React, Vite, HeroUI, Tailwind CSS, Framer Motion and Zod, and delivered by a three-person MindForge team across 230 commits.

Why working pages beat mock-ups

A static image shows what a page looks like at one width, with no motion, no scrolling and no real content length. A working page shows everything that matters to the final decision:

• How it behaves on a phone, a tablet and a desktop.
• How real headings and paragraphs fit, not placeholder text.
• How transitions and animation feel in use.
• How navigation works between pages.

When a client compares two working versions, the conversation moves from "I am not sure" to "this one, but with that header". That is a much faster path to a decision.

What makes parallel designs affordable

Building two designs sounds like double the work. It is not, if the content is structured properly.

The service catalog on this site is declarative: each service and its per-industry breakdown is defined as structured data, and the pages render from it. With content separated from presentation, a second design is mostly a second presentation layer over the same data.

Keep the comparison fair

For side-by-side designs to be useful, the variants should differ only in design:

• Same content, so the client is judging layout and style, not copy.
• Same pages, so neither variant hides a difficult page.
• Same quality of build, so one does not win because it was more finished.

After the decision

Once the client has chosen, the losing variant should be removed. Keeping both in the codebase "for later" leaves unused code to maintain and confuses the next developer. The decision and the reasons for it are worth recording, so the choice is not reopened without cause.

When to build alternates

This approach is worth the extra effort when:

• The client finds it hard to decide from static designs.
• The key pages have strong visual identity and the stakes of getting them wrong are high.
• The content is structured enough that a second presentation layer is cheap.

For a small site with a clear brand guide, one well-executed design is usually enough.

A checklist for design decisions with clients

• Structure content as data before designing pages.
• Build alternates as working pages, not images.
• Keep content identical across variants.
• Review on real devices, not just a desktop screen.
• Record the decision, then delete the losing variant.

The anonymised write-up is in our work library. A close cousin of this approach, comparing technical options with working code, is described in testing two architectures in parallel. Helping clients make decisions with working software is how our MVP service runs.