Menu
Menu Sheet Overlay
Search
Search Sheet

Mockups

How we approach mocks

Mockups, or just “mocks”, are fully-realised, often high-fidelity designs that represent exactly how the mobile experience should look. It’s normal practice for Mobify designers to provide two mocked-up templates to show clients in order to get general sign-off on styling and adherence to brand standards. We typically recommend creating a Homepage mockup and a Product Detail Page (PDP) mockup, since they typically cover most of the design language that can be found throughout the app. From these two mocks, information and styles can be re-used for other parts of the app.

FUT Product Details Page
We typically recommend providing mockups of the Homepage and the Product Detail Page (PDP) since they typically cover most of the design language.

In certain cases, the customer may request a mockup for a specific interaction or component style. For example, they may wish to see a mockup of the checkout instead of the homepage, since the checkout directly affects conversion. Decide which mockups to create by seeking input from the project manager and the customer.

Design for the smallest screen rather than the largest — it’s easier to expand than to shrink (designing with the greatest number of constraints is generally a good approach in order to be sure that your solution scales gracefully). Often that means designing @1x for the iPhone SE, working at 320px. (If you work in Sketch, it’s easy to export @2x.)

While it’s important to understand how much content fits on a screen at one time, your mockups should not end at the bottom of the viewport. While the client may not need to see every state (though it’s a nice touch, indicating that you’ve really considered every aspect)-- your developers do. Check that you are including designs for:

  • content inside accordions and modals?
  • selected, disabled, or sold-out options and states?
  • promotions, free gifts, add-ons, and shipping notices?

View an Example: https://invis.io/TY7MK0DQD

In the above example, you can see that the designer included all the content on the page, including the very large technical specifications table. They also tested a worst-case scenario by choosing a product with a long name, a free gift, and add-ons and included additional states and options. Always design for these ‘worst-case’ scenarios versus an idealized state, as this will allow your development team to foresee any challenges and obstacles.

Documentation

Because your development team will be implementing your designs, we suggest creating a prototype as well as a design handoff document to communicate design intention.

When creating your prototype, use InVision, as it provides a higher-level explanation of your design by linking up the templates so that developers can better understand how each template relates to each other.

Invision App
Invision App allows you to create hotspots directly on your design that link to other pages

It's a good idea to begin each sprint with a sprint planning meeting, where you present the designs and allow the developers and and engineers to raise any issues they may have.

Alternatively, you may wish to create design handoff notes within individual JIRA story tickets. (JIRA is our project management tool of choice.) Previously, at Mobify, we used Google Docs to communicate all design notes because it supports a comprehensive method of communicating your designs such as the ability to add links, screenshots, and comments. However, we learned soon that valuable information was being missed as developers moved on and off the project. By consolidating the design notes to specific tickets, any developer working on a specific ticket will have all the information they require to complete the design as per the specifications.

Global design notes that relate to the overall project and touch all features such as styleguides and icons should continue to live in a shared Google Doc. This doc must be referenced within each design note ticket so that all developers have access to it at all times.

Overall Project Design Documentation (Google Doc)

The Overall Project Design Doc is intended to provide the developers and engineers with a hub to all high-level, project-wide design information and resources for the given project. The document should aim to include the following information:

  • Design System
    • Layout grid and unit value
    • Typographic grid
    • Keylines
  • Global Resources
    • Design mockups
    • InVision prototype
    • Living styleguide
    • Icon assets

Component / Feature Specific Design Documentation (with JIRA Tickets)

After story or feature tickets are created, the designer is then responsible for adding all related design notes including links to the InVision Prototype, .psd files, and any animation samples. Additional notes should be added with supporting screen shots when necessary. In addition each ticket should reference the overall design documentation Google Doc so that any new developer has easy access to everything they need.

You can find out more about writing design documentation later on.