A mockup is a static, high-fidelity picture of the final screen: real color, real typography, real imagery, but no interactivity.
If a wireframe answers "what goes where and why," a mockup answers "what will this actually look like." Nothing moves yet: buttons don't respond, screens don't connect. That's the point: a mockup lets you make every visual decision while changes are still cheap.
Think of a checkout screen for an e-commerce app. The wireframe said the order summary sits above the payment form and the pay button anchors the bottom. The mockup decides that the button is a solid dark pill, the total is the largest number on screen, and the product thumbnail is a real photo instead of a gray box.
The most common misunderstanding at this stage is treating the mockup as a fresh start. It isn't. Your wireframe already went through review; its structure reflects real decisions about what users need first, second, and last. Visual design should strengthen the hierarchy the wireframe established, not renegotiate it.
A practical test: squint at your wireframe and note what stands out, in order. Then squint at your mockup. The same elements should stand out in the same order, just more clearly. If the mockup makes a decorative banner louder than the primary action, the visual layer has broken the contract.
That doesn't make the wireframe sacred. Sometimes real content exposes a genuine structural problem, like a headline far longer than its placeholder. When that happens, revise the wireframe deliberately rather than quietly patching the mockup. Keep structure decisions and styling decisions separate.
Beginners often style everything at once: a font here, a brand color there, a photo in the corner. The result is a screen where nothing was decided, only decorated. It's more reliable to layer decisions in a fixed order, checking hierarchy after each pass.
Keep the entire screen in shades of gray and design the hierarchy with size, weight, and spacing alone. If a screen works in grayscale, color can only make it better; if it doesn't, color will only hide the problem.
Choose a small set of text sizes and weights, one for page titles, one for section headings, one for body text, one for captions, and apply them everywhere. A limited scale forces you to decide what actually matters instead of nudging font sizes ad hoc.
Introduce color with a job to do: one accent for primary actions, one for errors or warnings, neutrals for everything else. Color applied last stays purposeful. Color applied first becomes wallpaper.
Replace placeholder boxes with real photos, illustrations, or icons. Use content that's realistic for the product: an actual dish photo in a food delivery app reveals cropping and text-over-image issues that a gray rectangle never will.
A mockup is not the place to invent a visual language from scratch. Most of your choices should already have a source:
Brand. The product's brand guidelines usually define the color palette, typefaces, and overall tone. Your job is to translate that identity into a usable interface, not to compete with it.
Design system. If the team maintains a library of components, buttons, form fields, cards, use them. Consistency across screens is worth more than a slightly prettier one-off button.
Platform conventions. Mobile operating systems and the web each have established patterns for navigation, controls, and gestures. Users bring expectations from every other product they use, and meeting those expectations is a design decision, not a lack of creativity.
What's left for you to decide is how these ingredients combine on this particular screen, and that's plenty of design work on its own.
Many accessibility problems are not coded into a product; they are painted into the mockup.
Contrast between text and its background, the size of touch targets, the minimum size of body text, whether color is the only thing distinguishing an error from a success: these are all mockup-level decisions. If a light gray label fails against a white card here, no amount of careful engineering fixes it later.
So check as you go: can the text be read comfortably at its actual size? Can a thumb hit that button without hitting its neighbor? Does every state communicate through more than color alone? Accessibility handled in the mockup costs minutes; accessibility retrofitted after launch costs releases.
Decorating instead of communicating. Gradients, shadows, and ornaments that don't guide the eye anywhere are noise. Before adding any visual effect, ask what it helps the user notice, understand, or do. If the answer is "it looks nice," remove it; the screen usually works better without it.
Ten shades of gray. When every text element gets its own slightly different gray, hierarchy dissolves into mush. Pick two or three text tones at most and commit to them.
Novelty fonts. An expressive display typeface might suit a logo or a hero headline, but interface text has one job: being read quickly, at small sizes, by tired people. Choose typefaces that disappear into the reading.
Because mockups finally look real, feedback changes character. People who stayed quiet through wireframes suddenly have opinions about colors and photos. That's useful, but it needs steering.
Ask specific questions instead of "what do you think?" Try "what would you tap first?" or "what does this screen ask you to do?" If reviewers can't answer quickly, the hierarchy needs work, however polished the surface. The most valuable mockup feedback is about what people notice and understand, not about which color they personally prefer.
Show the mockup in context too: on an actual phone at arm's length, not only enlarged on a laptop. Screens that look elegant zoomed in often turn out cramped at real size. When the visual layer holds up under these questions, you're ready to wire screens together into an interactive prototype.