Designing a website mockup: from research to prototype
Updated on
A website project can begin with a beautiful image and still be difficult to use. A visitor admires the animation, then searches for somewhere to click. A client likes the colours but discovers too late that an essential step is missing from the quotation request.
Early in my career, I made many choices by instinct. I had a visual idea, wanted to create it and moved quickly to the next stage. I learned to put three steps before development: research, design and prototyping. They give creativity a direction and make the website easier to discuss while changes are still relatively straightforward.
Contents
1. Find out what the page needs to help people do
Before choosing colours, consider the person arriving with a question. They may need to check your service area, understand an offer, compare an option or book a meeting. The mockup should help them make progress instead of merely presenting an attractive composition.
Start with three questions: who comes to this page, what do they already know and what should they be able to accomplish? The answers guide both the content and the interface. They also provide criteria for discussing alternative layouts without relying entirely on personal taste.
Imagine a service company receiving inquiries too vague to estimate. A useful mockup does more than include an attractive contact button. It lets the team examine which information to request, in what order and with how much effort for the visitor. This is a design scenario, not a measured result from a client project.
Visual research then supports that work. A moodboard brings together references for typography, photography, composition and atmosphere. The aim is to identify what works and why: readable hierarchy, a welcoming tone or distinctive contrast. Copying a competitor’s sections cannot replace thinking about your own offer and audience.
2. Give the content a coherent visual structure
Design turns intentions into screens. Colours and typefaces matter, alongside spacing, text width and the relative importance of elements. Every decision affects how someone reads the page and understands what deserves attention first.
A prominent heading creates an expectation that the following paragraph should answer. A photograph occupies valuable space and should help explain the offer or support trust in it. A button represents an action, so its label should describe what happens after the click rather than simply sound inviting.
These choices make sense together. A page can contain the right elements in an unhelpful order. Asking for a detailed estimate immediately, before someone understands the service, may demand effort too early in the conversation. Look at the sequence as well as the appearance of individual blocks.
Design the mobile journey explicitly. Content order, menus and forms change when space becomes limited. Simply shrinking a desktop composition may preserve the overall appearance while making reading or interaction uncomfortable. Use representative content to see where those constraints arise.
At Umbeli, design and user experience bring the message, identity and intended uses together. The purpose is a coherent experience rather than a visual direction that only works in a presentation.
3. Test the journey with a prototype
A mockup shows a page. A prototype simulates selected movements between screens. It does not replace the finished software, but it makes discussions more concrete because people can try a sequence instead of imagining it from isolated images.
Instead of asking whether someone likes the design, give them a task: find a service, start an inquiry or return to earlier information. Watch where they hesitate. Something obvious to the design team may be unclear to a first-time visitor who does not share its assumptions.
Before development, check the pages and content needed for the journey, the expected behaviour of menus and forms, and messages after an action or an error. Review meaningful differences between mobile and desktop. Identify photographs, wording and other elements that are still provisional, so everyone understands what has actually been approved.
A prototype cannot prove that a website will convert. It can expose some ambiguities before they become part of the code. Results still need to be observed when the finished site is used in real conditions, with its actual content and visitors.
Comparison: wireframe, visual mockup and prototype
These deliverables answer different questions. Compare what each helps you decide and what still needs checking. Their value comes from resolving uncertainty, not from presenting the largest possible number of screens.
A wireframe decides where information belongs
It shows: block order, navigation and content placement in a deliberately simple form. You validate: the journey and hierarchy. Its limitation: it does not fully express the brand’s personality. It is useful when a team is considering several structures, because moving a section does not immediately become an argument about colour. The content still needs to be credible enough to guide the layout.
A visual mockup establishes the graphic language
It shows: text, imagery, colours and components in a particular composition. You validate: readability, identity and balance. Its limitation: a static image says little about what follows an action. It is useful for reviewing art direction, provided approval of one screen is not treated as approval of every behaviour. Ask which important states remain to be shown.
A prototype lets you try a route
It shows: selected movements or interactions as a simulation. You validate: understanding of the route and the information needed at each step. Its limitation: real data, errors and performance are not necessarily reproduced. It is particularly useful for guided inquiries, bookings or customer portals where several screens depend on each other. Specify which parts are simulated before interpreting the feedback.
You can start with a simple structure, develop the visual direction and make the uncertain parts interactive. There is little benefit in simulating every footer link if the real question concerns the quotation form. Match the effort to the decisions you need to make.
Run a review session that leads to decisions
Send the mockup with a specific objective. Checking whether the offer is understood is clearer than asking for general feedback. Present a scenario and let the participant explore independently at first. Explaining every button as they go risks testing your explanation instead of the interface.
Record observations, interpretations and decisions separately. Someone returning to the menu three times is an observation. Assuming they do not understand the categories is an interpretation to investigate. You might decide to rename a category and try the task again. This distinction stops every preference from becoming a mandatory design requirement.
Bring feedback into one shared document. Identify what blocks the task, what improves comfort and what is an aesthetic alternative. Assign someone to resolve conflicting opinions for the business. Development then receives explicit decisions and visible open questions, rather than a collection of incompatible comments scattered across conversations.
What makes a mockup ready for development?
The team should understand what it is building, the client should understand what they are approving and unresolved questions should be visible. A spectacular screen filled with placeholder copy does not necessarily meet those conditions, even if its visual direction is strong.
Research sets the direction, design organises information and prototyping checks the route. When preparing a custom website, this work lets you discuss important choices before they become expensive to change in the implementation.
FAQ: designing and approving a website mockup
Does a small website need mockups?
A small project may only need a few representative screens. The essential point is to validate structure, visual direction and important behaviours before repeating them across the site. Match the level of detail to the uncertainty: a straightforward information page and a multistep form do not require the same preparation or testing.
Is placeholder text acceptable during design?
Temporary copy can help explore a composition, but it should soon be replaced by representative content. A real service list or longer heading can change alignment and block height. Clearly mark provisional material so that approval of the visual treatment is not mistaken for approval of the content or the final wording.
Do we need a separate mockup for every screen size?
The important task is explaining how the page adapts. Representative mobile and desktop screens, with rules for block order and navigation, can guide implementation. The developed site must still be checked at intermediate widths. Two convincing screenshots do not demonstrate that all sizes, longer labels and real content will behave correctly.
Can a prototype be published as the finished website?
A design prototype generally simulates chosen journeys. The published version also needs to handle the data, errors, access and maintenance in the agreed scope. Ask what actually works and what is simulated. This distinction belongs in the planning of a custom website, even when the prototype already looks very close to the expected result.