High-fidelity mockups represent the definitive version of an interface, as it should be at launch. During this phase, also called UI design or high-fidelity mockup design, the user experience is enriched by applying the brand or product's visual identity to the wireframes produced in UX design. This is the step where you settle how the style guide designed during the art-direction phase is used, where you make sure the accessibility rules are respected and where you check technical feasibility, without forgetting all the graphic animations that guide the user dynamically. This step sits at the final stage of the process and can only start once the site map, the features and the wireframes are validated. High-fidelity mockups are the result of the work done during the UI sprint, the last design step before handover to the developers for integration.
01
Before designing the mockups
Before moving on to design, it's important that all the UX work is validated by the stakeholders. It's also worth preparing the high-fidelity mockups by first producing a benchmark, a moodboard and some art-direction work. All of that lets you design your mockups efficiently. As for the software to use, don't hesitate to talk with the developers about the deliverable format they expect. Several options are open: Sketch, Figma, Adobe XD. Each tool has its pros and cons. It's up to you to figure out which ones fit the project's needs. For collaborative, real-time design, Figma is still the right tool, for example.
02
The structure
Once your art direction is approved, you can start the UI design itself. To avoid mistakes, take the time to create your page templates. Start with the main page, the highest-priority screen, and focus on the details. Is the chosen grid the right fit? Are your spacings and whitespace consistent everywhere? Does the design adapt properly to mobile? Have you respected the structure and the elements set by the UX designer? If many screens need to be designed, setting up a design system is preferable. Start with the smallest components and check their structure thoroughly before deriving variations. For instance, it's better to start with the CTAs, the navigation elements, the cards, and so on.
03
Your visual elements
When you're designing and shaping your pages, think about the visual elements too. Make sure not to overload your screens with too many colours, too many icons or decorative elements (which don't carry any information). When you finish a page, take the time to look at it and step back. Are the main pieces of information properly highlighted? Does this illustration serve a clear purpose for the user (information, catching attention, and so on)? Also remember to check your colour palette closely. Are all the colours on the page within the style guide? Is the colour used sparingly?
The wireframe sets out the structure, without visual detail, to validate the organisation and the navigation logic. The graphic mockup sets the definitive appearance, without interaction. The prototype adds navigation and behaviours, which makes it possible to test journeys. The three often coexist in the same file, the mockup arising from the wireframe by accumulating detail, and the prototype from the mockup by adding interactivity.
No. On an established product with a mature design system, adding a feature can go straight from wireframes to coded components. The mockup remains necessary when the visual identity must be validated by non-technical people, when the product is new and its design system still being built, or when external providers develop from the specifications alone.
Yes, when there is one. Screens are then assembled from components that have already been settled, and the work is about the arrangement rather than the drawing of each element. A mockup that departs from the system signals either a need that is not covered, which will become a new component, or a divergence to correct. Without a design system, the mockup produces the opposite: it is the components created for the project that will feed a design kit or the foundations of a future system.
The file is organised in named layers, with components from the library rather than elements drawn by hand, and styles linked to variables rather than defined locally. The behaviours a static mockup does not show (hover, error, loading) are documented in additional screens or notes. A prototyping link usefully completes the handover.
Contrasts are checked up front, between each text colour and the solid colour areas it sits on. Text sizes and clickable areas must respect the expected minimums. An audit on a mockup takes far less time than a correction after development, which justifies building these checks into the design process rather than putting them off.
A mockup with no graphic elements, describing the zones and essential components an interface should contain.
Read more about WireframeDrawing on collective intelligence, these workshops align stakeholders and surface solutions with the team and/or the end users.
Read more about Co-design workshopEveryone talks about user experience, service design, ergonomics...
It's not always clear, and you'd like to find out, or sharpen what you already know.
