The most important guideline of designing like a developer is to think of your design in terms of Views. Think of a View as an independent group of elements which has defined borders and is sorted in hierarchical order.

As an example, the Search Results screen of our Nimber app on Android is divided into two main views; the Top View which contains the Action Bar as well as a Card with the user-entered locations and filters, and a List View with the returned search results.

In the Blueprint or Skeleton above, you can see how the view bounds are clearly defined in the design. These are layers that are invisible in the Sketch file (0% opacity), but they’re extremely useful when handing over the design to your developers.

See below how the Action Bar is broken down into smaller Views.

Top Level of View Hierarchy

ActionBar View

Action Items with View Bounds at 100% opacity

Make sure to not just group your layers randomly. Define their sizes and spacing in a clear way (avoid odd numbers) and sort everything in hierarchical order.

The same applies for layer styles, for cases where you need to use consistent strokes, rounded corners, drop shadows, you name it.

This app called Zeplin helps a lot here. Long story short: you import your design in there, and the app extracts all view sizes, text sizes, colors, etc. in a developer oriented way. It’s a great tool that bridges the gap between designers and developers, and I can’t wait to see what it holds for the future.

When you hand over your design, the developer can look at Zeplin and extract the sizes, margins, paddings from one single item, and create the view in their IDE accordingly.

Design in 1x

Why is this even up here…

By designing in 1x, first you help yourself by not having to calculate sizes in other screen densities, but most importantly, both you and the developer end up using the same numbers. This way you prevent any miscalculations when handing over your design, and keep a consistent set of values.

This applies to view sizes, text sizes, line heights, most numbers really…

Consistent Color Palette

Create once, always reuse. Try to have as few colors as possible.

You’ll see developers mostly use names such as Primary, Secondary, Accent, Enabled, Disabled etc. You can do the same thing. Primary and Secondary can be your text colors, Accent can be your brand’s color, you get the point.

In Sketch, you can save these colors in the Color Picker, but as far as I know, there’s no way to share them outside of the Sketch file. What you can do instead is create an artboard with the colors from your palette, along with their names and hex codes. This way, developers can quickly extract them when they access your design through Zeplin, and insert them in the app’s code.

These are the colors we use on the Nimber apps

Design for all cases

Keep in mind that developers don’t build the ideal UI, but rather something that adapts into the ideal UI. They have to take care of cases where there’s no connectivity, or there’s a server error, or when there’s no content to display and much more.

So make sure to design for every scenario. Specifically, make sure to design every screen in its Empty state, Loading state, Error state, and the Ideal state. 99% of the time, these will be enough. This article by Scott Hurff goes into more depth about states, recommended read.

Screen sizes

We live in an era of multiple screen sizes, so we have to design accordingly. This is a big deal when designing for Android because of its plethora of devices which come in multiple screen sizes.

The “lazy” way to deal with this is to use a plugin such as Sketch Constraints when creating your design in Sketch. When you use something like that, you can duplicate your artboards, resize them, and refresh the artboard. Magically, the UI will adapt accordingly to fit that screen size.

The “correct” way to do this is to design your UI for phone screens (under 7 inches), 7 inch tablets, and 10 inch tablets. It’s especially awesome when you use Master-Detail Flows, which is a fancy term for combining List and Detail panels into one layout, such as the one below.