Design freeze (design finalization)

Design freeze is the moment we lock the approved UI so development can build from a stable blueprint and we can produce an accurate production quote. After freeze, you can still update a few “safe” items (like copy, images, and links) as long as they don’t change layout or functionality. Anything that changes layout, components, or site structure requires a Change Request (CR).

 

What “UI” means in this context

UI (user interface) is everything someone sees and interacts with on a page—layout, typography, buttons, menus, forms, cards, spacing, and how content behaves across screen sizes.

What we lock at design freeze

At freeze, the following are considered approved and locked:

• Page layouts (desktop + mobile behavior)

• Component designs (buttons, cards, forms, navigation, etc.)

• Spacing rules and typography hierarchy

• Responsive rules (what stacks, collapses, or reorders on smaller screens)

• Approved sitemap and page list (what pages exist, and how users get to them)

This is what engineering uses to scope, estimate, and build.

Why design freeze exists

Design freeze protects four things:

• A reliable quote — production estimates assume the design will not shift mid-build.

• Schedule integrity — layout changes late in the process usually trigger rework.

• Quality — fewer moving targets means better testing and fewer regressions.

• Scope control — it’s the main guardrail against “small changes” that quietly become large changes.

Changes that are usually still allowed after freeze

These are typically fine if they don’t change the design’s footprint (no new lines, no resizing, no reflow, no new interactions).

Copy updates (text)

Allowed

• Fixing typos

• Tightening wording

• Updating dates, names, product details, and pricing text

• Swapping button labels when the label still fits cleanly

Rule of thumb: if the new text wraps, pushes other elements, noticeably changes button width, or changes spacing, it’s no longer a “copy-only” change.

Examples

• Heading: “Welcome to Our Store” → “Shop With Us Today” (similar length)

• Button: “Get Started” → “Join Now” (similar footprint)

• Paragraph text: rewrites are fine if the section still fits without layout changes

Image swaps

Allowed

• Replacing an image when the dimensions and orientation stay the same

• Updating a photo while keeping the same crop behavior (portrait vs. landscape)

Examples

• Product image swap with the same aspect ratio and size

• Home hero/banner image swap that still crops cleanly within the same container

Link updates

Allowed

• Updating destination URLs

• Changing link text if it still fits without shifting layout

Examples

• “Learn more” → “Discover” (shorter, still fits)

• Updating a URL from an old page to a new page

 

Changes that are not allowed after freeze without a Change Request

If a change affects layout, components, behavior, or site structure, it is out of scope for a frozen design.

 

Layout and page composition

Not allowed without a CR:

• Moving elements (e.g., button shifts from top to bottom)

• Adding or removing sections (e.g., inserting a new testimonial band)

• Changing sizing in a way that alters spacing or reflow (e.g., taller header, wider sidebar)

• Reordering modules (e.g., swapping an image/text split to the opposite side)

 

Functional components and interactions

Not allowed without a CR:

• Adding fields to forms

• Changing a flow (e.g., one-step checkout → multi-step)

• Adding new features (live chat, filters, account logic, new search behavior)

• Changing navigation patterns (simple nav → mega-menu)

 

Site structure and navigation

Not allowed without a CR:

• Adding or removing pages

• Changing the sitemap hierarchy (top-level vs. subpage decisions)

• Changing URL structure (pathing that impacts routing, redirects, analytics, SEO)

 

Why these “core” changes trigger a Change Request

These changes tend to create real downstream work:

• Rebuild time — layout changes can force partial re-implementation of templates/components.

• Retesting — new behaviors and page types require QA across devices and browsers.

• Knock-on effects — changes often ripple into navigation, spacing systems, and content rules.

• Budget impact — additional scope usually means additional time and cost.

If you need a change after freeze

Submit a Change Request (CR). A CR is a written request that lets the team assess impact and keep the project predictable.

 

A CR typically includes:

• The exact change you want (screenshots or annotated mockups help)

• Why it matters (business reason, user impact, compliance need, etc.)

• Where it applies (page(s), breakpoint(s), templates, components)

Then we:

• Review impact on timeline, build effort, and QA

• Approve or decline

• If approved, update schedule and cost before starting the change

 

Quick examples

Usually okay after freeze

• Copy tweak that doesn’t wrap or resize elements

• Image swap with the same aspect ratio and crop behavior

• Updating a link destination URL

Needs a Change Request

• Adding a new homepage section

• Changing the navigation structure

• Adding fields to a form

• Converting a layout (three-column → one-column)

• Adding a new page to the sitemap