What should we check before freezing a web design for launch?

Check whether the design can be implemented across devices and input methods, meets inclusion needs, and accounts for technical constraints before it is frozen. Bring developers into the design process early enough to confirm what is practical and identify alternatives. Keep designers involved during development so the approved experience is executed as intended.

Yellow heart with a black outline and the handwritten words Good design in the center on a beige background.

Review feasibility before design approval

A design freeze should confirm more than visual approval. Designers and developers need to consider the situations people may encounter when using the web, including different devices, connection conditions and ways of interacting with a page. A developer can identify technical limitations in a proposed design, but can also suggest ways to extend or adapt it without losing the intended experience.

The review should test practical details that can otherwise become problems late in delivery: sufficient text contrast, responsive behaviour, and support for mouse, touch and keyboard input. It should also establish whether inclusion has been designed into the experience rather than left as a final-stage check. Early technical participation gives the team a chance to resolve constraints before implementation commitments make changes harder.

Sources: Designing and developing web experiences for everyone

Treat design and development as a shared process

Developer involvement during design helps establish what is possible and practical to implement before a design is approved. In the This is IBM project, the developer was involved from the beginning of the page design, helping confirm implementation feasibility while considering colours, contrast, device views and input methods. The work was therefore shaped with inclusion as a priority rather than adapted later.

The collaboration should continue into development. Designers can help ensure that the implemented result reflects the approved design, while learning from technical constraints that can improve future work. This is not a guarantee that every launch risk disappears. It is a way to surface execution obstacles earlier, when the team has more room to make considered decisions rather than retrofit essential requirements under deadline pressure.

Sources: Designing and developing web experiences for everyone

Stats

A 2026 review of software-rework research states that rework can account for up to 40% of schedule variation and cost in software projects.

Mahato et al.

FAQs

What should a design review cover before development starts?

A design review should cover implementation practicality, responsive views, colour contrast, and interaction through mouse, touch and keyboard input. It should also consider whether the experience works for people with different access needs, devices and connection conditions. Include developers early enough to identify constraints and technical alternatives before the design is frozen.

What makes late design changes costly before launch?

Late changes are costly because they can require inclusion, interaction and implementation decisions to be retrofitted when deadlines leave little time to spare. Addressing these requirements from the beginning gives the team more opportunity to resolve them within the design process rather than under launch pressure.

What causes rework when project requirements change late?

Late rework can result when initial requirements are unclear or when stakeholder involvement and project complexity introduce changes after decisions have been made. A feasibility review can reduce exposure by making technical assumptions, inclusion needs and implementation constraints explicit before design approval.

What slows delivery when designers and developers work together?

Collaboration can slow delivery when it adds meetings or delays decisions without resolving the assumptions that affect implementation. It is most useful when developers contribute concrete feasibility input during design and designers remain engaged to check that the implementation preserves the intended experience.

Where do accessibility problems appear in web designs before launch?

Accessibility problems can appear in low-contrast text, designs that do not work well across devices, and interactions that assume everyone uses a mouse. They can also affect people using keyboards, screen-reading browsers, slow connections or mobile devices in difficult viewing conditions.

How do I run technical discovery before a design freeze?

Use shared design and development review to identify execution constraints before they become implementation changes.

  1. Bring developers into design

    Involve developers while the experience is being designed, not only after visual approval. Ask them to confirm what is practical to implement and identify technical limitations or alternative approaches while there is still room to adjust the design.

  2. Test real use conditions

    Review the design across device views, colour contrast and different input methods, including mouse, touch and keyboard use. Consider the needs of people using slow connections or assistive browsing tools so inclusion is built into the work.

  3. Keep design involved in build

    Keep designers engaged during development to check that the approved experience is being executed properly. Use what the team learns about technical constraints to improve design decisions on future work.

Related

Cookie consent

By clicking “Accept”, you agree to the storing of cookies on your device to enhance site navigation, analyse site usage, and assist in our marketing efforts. View our Privacy policy for more information.

Deny
Accept