Sketch strategies

Thumbnail by Kobu Agency on Unsplash

❮ View all insights

Design is usually associated with technique - how you achieve a specific style, how to compose great layouts, or how to think in terms of components. Our community will share tips and tricks at length for all of the sexy parts of design, but what about the boring stuff?

I want to talk about setting up a design file (Sketch, specifically) based on a few scenarios - prototyping, development, and exploration. Right away some of you are asking "Why would the scenario matter? Just set the file up the same (amazing) way you always do?". Well read on my friend! You may find that not all design file architecture is created equal...


When you design for a prototype you're designing an experience. The experience needs to be as thorough as possible to reflect the potential real-world application. This means interactions, animations, active, inactive, error, and hover states, forward and backward navigation, keyboard overlays, and much more!

The end goal of prototyping is to create a lifelike, clickable / tap-able, testable concept to get feedback. To account for these constraints, your Sketch file will need a few considerations. Your design will:

Show multiple workflows

Good prototypes have insane attention to detail, showing workflows for log in, password reset, navigation, tasks A, B, and C, modals / dialogs, alerts, badges with various counts, on-screen keyboards, and logging out. Always include a happy and unhappy paths, with validation and errors.

Have lots of art boards

Since a component's state is always shown in the context of the associated workflow, your design file will get huge. Fast. Organize your artboards in clusters based on the related workflow. Add a block of text above (that's 'uge... like 50+pt sizing) so you know where to find your flows. You can put different workflows into different pages of Sketch, but this can be hard to link up as a prototype (and it gets even more bloat when you account for landscape / other resolutions on different pages).

Have clickable elements

Prototyping by its nature is interactive - which means your symbols need to account for bite-sized clicks. For example: A nav bar with several links makes sense as a large, master symbol (properly set up to respond to different screen sizes). However, the entire symbol is clickable - so you can't set up individual links to go to the correct page... the large symbol limits your ability to prototype. Even if you use small components for active / inactive tabs or nav elements and assemble them on your artboard, sweeping changes to your overall nav element will be tedious to change. Additionally, if you're using a tool like InVision Studio that offers some slick animation tools - you may want the component to break apart or transform during page transitions. This means your components will have to be even smaller / de-structured to allow for key-framing individual elements. This is a price you pay for having more robust interactions...

Emphasize speed

There is a LOT of work involved with making a prototype, so it's often a good idea to start with some base components or a design system up front. Leveraging an existing library of UI elements will make whipping up prototypes a breeze. You can download my free design library here to get started. You can still hand-craft everything for your app, just know that there are inefficiencies of working this way (see above) that make designing things a little harder than they need to be.

Be aware of device sizes

One last "gotcha" with prototyping is it's dependency on device specificity. By this I mean, the shear amount of work required to make a solid prototype experience tends to force designers into a hole where they only focus on the experience for the device of choice. If you have a 100+ screen prototype with dozens of elements linked to different screens in the app, you likely won't bother reworking ALL of it into a landscape prototype, a tablet prototype (with portrait and landscape modes), and a mobile (or web / opposite resolution).

An approach in this situation is to design products sequentially (as in, master the mobile app first - then make the web app). A perk of this is using the findings of the first app as influences to the second. The downside is that your apps will often lack continuity (one will be a more advanced experience than the other / more polished / just different). Another approach is to design products in tandem, designing both the mobile, tablet, and web experiences at once. This helps maintain continuity across all platforms - but does slow down the process.

TL;DR; When designing for a prototype be aware that your efforts will likely be hyper focused on a specific device, which may mean neglecting other platforms. You'll also be designing at a disadvantage, making more small parts rather than robust, large components. The upside is you'll have a nice demo app to get feedback on, which can make a huge impact on the project.


By contrast, development focused design emphasizes the hand off from design to code vs the discovery and prototyping approach. Designing for developers means taking their needs into consideration. This may mean putting extra effort into organizing layers and styles, or glazing over some interactions by simply showing the component states on a stickersheet.

Here are some specifics you may run in to when designing for development:

A focus on layouts, components, and style guides

Rather than looking at experiences and what it means to use the app, developers want to know margins, padding, line-heights, fonts, and colors. Their job is to build the app, page by page until it's done. As a designer this means you can create and share a few page layouts, and worry less about showing the individual workflows that use them.


Developers still need a roadmap of the experience, so despite not spending time on a clickable demo, you will still need to put some flowcharts together. It may be less sexy / interactive - but a good flowchart is an invaluable tool for illustrating an app idea (and often faster to produce). One flowcharting trick is to include the "meta" for each node in your chart. These would be things like references to page layouts (like "Home template"), text styles, copy / content, action items, special requirements, animation, etc.

Focus on component state

Like prototypes, you will need to design states for your components. But unlike prototypes, you can keep it at the component level. This means you're giving an example of the component, but not all of the content or context. For example: An input may have a label and placeholder. On focus, it may change color, the placeholder goes away, the input type appears, etc. On focusOut there may be a validation error / error text that appears, and the component may have different decorations. All of this can be illustrated semantically for developers by simply using the words "label, placeholder, input, error" rather than putting the component in context with "name, your name, John Smith, please enter a valid name". The context is useful, but most developers just want the style (and context can be conveyed in other ways). This same methodology applies to buttons. Pro tip: create a button element and change the text of the button to reflect its state... "default, hover, active, focused, disabled".

Optimize for exporting, not designing

This refers specifically to some design tricks you may want to use to make life easier - but they end up causing problems for developers. A specific example is icon generation. In Sketch a common practice involves adding a path for your icon glyph, setting it as a mask, then clipping a color symbol in the layer above. The end result is an icon which you can change the color of whenever you want! The bad news is how Sketch exports this as an SVG.

Sketch creates a clip mask within the SVG and only exports the path for the color symbol. If you're working on Web it usually buffs out - but anyone working on an Android or XML project will want to stab you for the extra headache. SVGs should be exported as paths with solid fill. No masking (sorry material icon library). In this instance, what helps me as a designer hurts my friend the developer... so be aware that some shortcuts on our end may need to be avoided for a smoother dev handoff.

big symbols that don't need to click

Another difference between prototyping and development designs is symbol creation. As mentioned above, the prototypes need every element to be interactive. When designing for code, you can combine small bits into more robust / large components. The advantage here is easy iteration of your design because there are fewer symbols to update. The nav element from a previous example could be built so all the elements are nested in the main symbol. Nothing needs to be clickable, so updates in the future are relatively painless!

TL;DR; Designing for development isn't better or worse than prototyping - it's just different. You can make larger symbols that are easier to update across your design because nothing needs to be interactive. However, since dev handoff is key you may find yourself doing mundane tasks like setting up icons with various fills rather than using a color symbol.


When I sit down for a new project I usually spin up a new Sketch doc and hammer out all the little bits I know I'll need. Things like a type scale, color palette, icon selections, button and input styling. Rarely do I just start making stuff... and that's a problem.

I wanted to include "Exploration" in here because I feel it's vital to the design process. It's important to play with design and push / pull things just to see what might come out. Too often, at least for myself, I omit this step in favor of cranking out a demo app or styleguide. I would encourage us all to spend more time exploring design and in doing so remember this one thing:

Nobody else will see this

You might show a client a screenshot you export for initial feedback, but the majority of this effort is for you. Its stretching design muscles and strengthening them in new ways as you explore crazy ideas. Since these ideas are wild and out there, don't bother adding all the arbitrary constraints like type and color. Play with sizes and scales, see what happens, and break your own conventions. Focus on exploring interactions with the HIGHEST engagement opportunity. You're not mapping the whole app, just a few screens to explore new possibilities. The focus is being creative, so this work will likely "not scale" to the bane of all designers out there.

TL;DR; Exploration is important - don't overlook it. And don't be afraid to use a new Sketch file for fun and throw it away later.

Boring enough for you? Turns out there's a lot of thought that can go in to your empty Sketch file, long before you post that next Dribbble shot. These are just a few examples from my experiences... how do you set yourself up for success when starting a new Sketch project? I'd love to know your thoughts! Feel free to message me below, I read every email (and respond to almost all).