The Mockup Ends. The Website Doesn't.

The design is what people see. The rest is what makes it work.

A website mockup can tell you exactly where a button belongs. It doesn't necessarily tell you what happens when someone clicks it.

Or what happens when they open the menu on a phone. Submit a form with a missing field. Navigate with a keyboard. Follow an old link after a redesign. Try to update a service description six months later.

Those aren't the glamorous parts of a website. They're still part of the website.

A mockup captures a moment. A website has to handle what happens next.

Good designs establish direction: hierarchy, layout, typography, color, imagery, content and how the experience should feel.

Sometimes they also specify mobile layouts, prototypes and interaction states in detail. Sometimes they don't.

Either way, turning a design into a functioning website involves decisions that may never appear in a static presentation. Those decisions need to be made somewhere, by someone, and tested against what the business actually needs.

Here are a few places where the work continues after the mockup ends.

The navigation has to work, not just look right.

A beautifully designed desktop header is one state of a navigation system.

On smaller screens, links need somewhere to go. Submenus need to open and close. The menu needs to work with touch and keyboard input. Focus needs to remain visible. A customer shouldn't have to hunt for the Contact link because the mobile version was an afterthought.

The design sets the direction. Development has to deliver the behavior.

A form isn't finished when it looks finished.

A contact form can look perfect and still fail the business.

What happens if someone leaves a field blank? Does the form explain the problem? Does it show a useful confirmation? Are spam submissions handled appropriately? More importantly: does the message actually arrive where someone will see it?

A button labeled "Send" is not proof that a lead made it through.

The meaningful test isn't just whether the interface submits. It's whether the intended journey works from visitor to recipient, with the relevant privacy and error-handling decisions in place.

Someone has to maintain this thing.

A website doesn't stay frozen on launch day.

Headlines change. Team members come and go. New services appear. Navigation grows. Someone other than the original developer eventually needs to update a page.

That makes CMS structure, reusable components, editing permissions and documentation real design considerations, not just technical housekeeping.

A site that looks great today but is painful to update next month hasn't solved the whole problem.

The parts you can't see still matter.

A mockup doesn't show a page's search title, meta description or redirect rules.

It won't tell you whether images load efficiently, whether the experience works at different zoom levels, or whether a visitor can use important controls without a mouse. It also won't confirm that analytics are collecting the intended events or that consent choices are being respected when relevant.

Not all of those requirements apply in the same way to every project. But they should be considered deliberately, not discovered by accident after launch.

Launch is a handoff, not an ending.

When a redesigned website goes live, the old URLs still matter. So do the domain, hosting, integrations, backups, access permissions and ownership of future updates.

Who can make changes? What happens if a form breaks? How is the site recovered if something goes wrong? Which parts need a human to sign off before they go live?

Those questions may not make it into the visual presentation. They make a considerable difference once real people start using the site.

The website launch checklist people tend to forget

The obvious things usually get checked before a website goes live. The homepage looks right, the copy is approved, and the buttons appear to work.

It's the smaller details that are easy to miss, especially when everyone's focused on getting the site out the door.

Here are ten things worth checking before launch:

• Forms and email delivery. Submit a real test inquiry. Make sure it reaches the right inbox, handles errors clearly, and doesn't disappear into spam.
• Mobile navigation. Check menus, dropdowns, buttons and layouts on actual phones, not just a resized desktop browser.
• Old URLs and redirects. Make sure important existing links still work or redirect to the right pages instead of sending visitors to unnecessary 404 errors.
• Search engine settings. Review page titles, descriptions, canonical URLs, XML sitemaps and any staging noindex settings that shouldn't go live.
• Accessibility. Test keyboard navigation, visible focus states, form labels, image descriptions and readable contrast.
• Analytics and conversions. Confirm tracking is working, important actions are recorded correctly, and any required consent settings are respected.
• Social sharing previews. Check the image, title and description that appear when someone shares a page on LinkedIn or in a message.
• Performance. Check image sizes, fonts and loading behavior on slower mobile connections, not just a fast office network.
• Backups and recovery. Know how to restore the website if a deployment, update or hosting issue causes problems.
• Ownership and handoff. Make sure the business has access to its domain, hosting, analytics and website, and knows how to make basic content updates.

Not every website needs the same launch process. But these are the kinds of details that are much easier to handle before launch than after a customer discovers something is broken.

How DOT ROSI thinks about the gap

At DOT ROSI, the goal is to connect the visual work with the practical work behind it.

That means taking an approved design seriously while also identifying the decisions it doesn't make for us: how a component behaves, how content gets managed, how the site responds on mobile, what needs testing, and what requires an explicit client decision.

It also means respecting scope. Not every project needs every feature. A simple brochure site and a complex lead-generation platform shouldn't have identical checklists or budgets.

The useful distinction is knowing what is needed, what is included, who owns it, and how we'll know it works.

Because a good website isn't just something worth looking at. It's something people can use, a business can rely on, and a team can maintain.

Have a design ready to build or a website that doesn't quite work the way it should? Start a conversation with DOT ROSI.