How I use Sketch with Zeplin to design and specify apps

I recently came across the Nielsen Lab article about wireflows — a document that merges a wireframe and a task flow. Those documents are essentials to communicate clearly the design to the rest of the team. I used them all the time and they are part of my workflow.

I took that opportunity to document my design workflow (during the production phase) using Sketch. I am talking just during the production stage — when I already know what to build, why we are building it and how it should “work”. I am somewhere between the prototype (invision) and the build (code).

I try to design everything in Sketch. That way I have one central place to keep everything design-related to the project. It’s all in one sketch file. It’s light and fast. I keep a manual versioning system and create copies just for major changes.

Sketch + Zeplin = ♥︎

Sketch is an amazing tool in combination with Zeplin. It becomes the ultimate designer/pm/dev combo to go from design screens to a working product.
In this article, I will describe how I organise my sketch document and how I use it in conjunction with Zeplin to share the design with others.

Document Organisation

I use pages for the different “user scenarios”. Let’s take the example of a shopping app, it would look something like:

Each page could match an epic if you work in Agile.

App/Site Map

The app map shows a bird’s eye view of the whole app. I like to use a “tile view” to communicate the main function of the page at a glance. Every client, dev and whatever stakeholders will love that detail as it save them time to process the information.

I use a specific key to highlight what the content type of pages elements ARE (eg. a link, an action, a module, a private area etc.).
I try to keep it simple as much as possible and don’t shove too much info in it. It’s easy to add more and more stuff but beware people who will read the document who be as familiar as you in the system you are building and therefore will likely to be more confused by that information galore.

Sections

A typical section (ie. a sketch page) contain the screen design for a particular user flow/scenario.

I like to have sections named with a verb. That way it highlights what the user wants/have to perform. It reinforces the action user wants to achieve.

Let’s take the example of Browse, or how the user navigates through products to find his desired item.

The screenshot below describes how I name and organise the different canvas within the page for the browse flow. I maintain a proper numbering system to be able to refer to those screens easily in other communication tools (jira, confluence, slack, Zeplin, etc.).

Screenflows

Every section starts with a flow. It‘s a one big (A3 Ratio, so it’s easy to print) artboards which contains bitmap exports of my multiple UI Artboards.

I use the plugin aptly named Place Linked Bitmap to embed those Artboards exports so they can always stay up to date by using the plugin action “Update All Bitmaps…” 🤘

Flows are very useful to communicate how user navigate through the screens. I sometimes add annotations there. Most of the time I would print them on A3 and add annotations on the paper. Leave the sheet to the dev. Works a treat. I also have created an A3 artboard template and most of the time use it for that purpose.

Screen design

I based all the screen design on a grid (layout in Sketch). I tweaked the grid settings to not be more subtle when designing/positioning elements. You can change the opacity and colour of the grid layout.
I use 6 or 12 col grid as it is the most flexible one. You can divide evenly the 12 col. by 2/3/4 and therefore space your modules more easily.

Each canvas is easily exportable. It can be printed or shared via Zeplin (cmd+e) or just exported as PNG for a prototyping tool.

I can change the export size settings to match the desired output (print or web and match the screen density where it will be prototyped).

Zeplin

Zeplin is the unique centre of truth for other parties (dev, stakeholders) where they can access and review the design.

For the designer, Sketch is the one place to edit the design but for all the other people it’s all in Zeplin in an always up to date and accessible URL.

Comments to specify

I often add comments to some screens and diagrams to create contextual annotations. Zeplin becomes that living functional specification document. Always up to date with the latest design.
Using Zeplin for specifications let the product owner write specs and communicate with others. It is not a designer specific tool (like indesign) and therefore is much more accessible.
Also because all the images will be automatically up to date there, it’s easier to maintain the spec in Zeplin.

Of course, it has its limits. No versioning, no printing…but for many projects and teams who want to minimise their time on documentation it works.

Use annotations to describe some behaviours

Tags to filter

I export everything in Zeplin not just the screen design. Sitemaps, screen flows etc will end up there. I use tags so people find their ways through the multiple screens. The tags are related to the sections mentioned above, eg. browse, search, buy etc. They are not perfect and this feature can be improved but it does the job of filtering the information in Zeplin.