Questions to ask developers before you start designing

This is an excerpt from Designing with your developer in mind, an InVision e-course by Kevin Tomasso.

In the responsive web design world, constraints can come from a multitude of avenues: from the technologies being used to the browsing habits of your user base, to the skills and strengths of your development team.

In this post, we’ll go over 4 specific questions you can ask your development team before you fire up your layout software to ensure you’re all on the same page.

Question 1: How do you prefer the deliverables to be handed over?

I always like to get a feel right away for whether the developers are accustomed to a particular handoff procedure, as this may very well determine which layout program you use to create your mockups.

Far too many times have I seen a designer (including myself) make assumptions about how the final deliverables should be prepared, only to have to go back and prepare them another way. The last thing your team morale needs when you’re done with the design and about to begin development is to go back and re-save or redesign files in a different format.

Below are a few questions and scenarios to consider and discuss with your development team before you start designing.

How should assets be prepared?

Do they prefer you slice, prepare and save all assets into an organized folder?

Would they rather receive a layered source file that they extract the images from themselves?

If this is the case, which type of source file is it? PSD? AI, EPS or layered PDF? Sketch?

Do they have the same version of the software (i.e. will they be able to open it)?

How can you group and name the layers to help them find and isolate the assets they need?

Do they want you to output HTML from Dreamweaver or another WYSIWYG editor?

If this is your normal workflow, ask them if this is optimal for them to work from. 9 times out of 10 they probably do not prefer this method.

Code generated from graphic interface programs is usually ugly, unorganized, and unusable. In my experience, this method usually slows both the designer and developer down, so avoid code generated from graphic interface programs. It should always be discussed with developers first if you consider it an option.

Should the assets be accompanied by a handoff document?

How do you plan to document the elements of design that aren’t apparent from the mockup? Things like color codes, height/width dimensions, fonts, font sizes, spacing, alpha values, hover effects, animations, and other data points must be defined and recorded so that it’s not up to the developer to guess and/or make assumptions.

Some useful applications to aid in this front:

Omnigraffle. Makes it easy to draw arrows, add symbols, and other keys to explain the particulars of a design.

Avocode. I’ve never personally used this, but it allows you to export colors, image assets, fonts, text, CSS, sizes, and dimensions from Photoshop or Sketch. Can eliminate a lot of the headaches discussed earlier.

Inspect from InVision. Inspect promises to be another awesome handoff tool with a combination of features available in the products above, particularly useful if you use InVision for prototyping. I personally can’t wait to add this to my workflow.

Question 2: Will the site be built using a front-end framework?

There are many popular frameworks available that take a lot of the tedious work out of the design and development process. Knowing which, if any, are being used is paramount to correctly setting up your design document.

Many popular frameworks such as Bootstrap and the 960 Grid employ a 12-column system. Why 12 columns? 12 is the most easily divisible among reasonably small numbers. You can have 12, 6, 4, 3, 2, or one evenly spaced columns, which makes your design decisions a lot easier when you work with these restrictions in mind.

With the structure of these frameworks comes pre-set dimensions. Know the values of your framework’s dimensions from the start—global padding, column width, gutter width, and media query breakpoints.

I’ve had designs break in production because the margins I set on my artboard in Sketch were 5px larger than the margins set in Bootstrap. This is no fun for anyone, as the design has to be reconfigured and then recoded to fix an issue that should have never existed. Learn which framework the site will be built on, and figure out how it translates into an artboard or canvas for your graphic layout software.

In addition to grids, many frameworks come with built-in design elements like buttons, forms tooltips, etc. If you want to modify or overwrite these predefined styles (and I encourage you to customize them to fit your brand), make sure your developers are aware of this.

Almost every time I design a form input with a specific border color, radius, and width, the developers just end up using the framework default because I didn’t specify it in my instructions.

Don’t expect a dev to notice the 2px border radius difference you meticulously chose for your buttons to convey a more friendly feel. They aren’t trained to notice such things, but they can follow directions like a machine.

Some of the most popular frameworks:

• Bootstrap
• Foundation by Zurb
• Pure by Yahoo
• Skeleton
• Semantic UI
• …and dozens more

Know which framework your dev prefers before you start designing.

Most frameworks have template resources you can easily find and use to set up your Photoshop or Sketch document to match them exactly. This makes everyone’s life easier, so use ‘em!

Question 3: What languages and libraries make up the development environment, and what limitations does that create?

Even if you don’t know how to write code yourself, you can find a good widget or plugin. Code snippets are readily available—they make adding functionality to your site a lot more accessible than in decades past. The catch: Plugins aren’t one size fits all.

If you’re going to try and find pre-built widgets for the site, that’s perfectly fine and often pretty helpful. What you need to do prior, though, is find out what language to search within.

Every plugin or widget is written in the specific coding language that the author chose. Many times the language a widget or plugin is written in doesn’t match the language or environment your site is being built in. As you can imagine, this causes problems—the least of which is a grumpy developer.

A weather app built in Ruby won’t work if your site runs on PHP. A WordPress slideshow plugin isn’t going to do much good on a site built in .NET. An Angular loading bar module will do nothing on a site that uses Backbone.js, despite both having roots in Javascript.

You get the picture.

Even if you find a widget that matches your development environment, use it as an example to explain the desired behavior you’re looking for to your team. Your devs may choose to implement it exactly as-is, but handing them a ZIP file full of code and asking them to “pop it in” is like having a client email you a series of 100px wide thumbnails and asking you to “create one of those big slideshows.” It’s presumptuous and can come off a little condescending.

Question 4: What browsers do we need to support?

Newsflash: All browsers aren’t created equal!

Okay, you probably knew that, and if you’ve ever met a developer, you probably know that Internet Explorer is the bane of their existence.

Luckily for the entire design and development community, the browser disparities that haunted online creators in the past are quickly narrowing to a small list of offenders. Even Microsoft has abandoned Internet Explorer and is now shipping their new, standards-friendly Edge on all new computers.

Knowing the legacy browsers you need to support can significantly alter your design decisions. Here’s a list of CSS properties that some legacy browsers cannot support. See if you notice a trend.

• Border-radius: IE8
• text-shadow: IE8, 9, Firefox 2, 3
• box-shadow: IE8, Firefox 2, 3
• RGBA (color transparency): ie8
• Flexbox (more on this later): IE8, 9. Needs adjustments for older versions of Safari and Firefox
• Multiple backgrounds: IE8, Firefox 2-3.5
• SVG: IE8 (many others for specific things)
• CSS Animation: IE8, 9, Firefox 2-4, Safari 3.1 – 3.2
• CSS 2D transforms (rotation, scale): IE8, Firefox 2, 3
• Media Queries: IE8, Firefox 2, 3

You can examine all browser functionality here.

If you find yourself in a position where you have to support IE8 or extremely old versions of Firefox and Safari, think about how elements will look without the added effects. All your rounded corners will be square, animations will be still, shadows won’t be visible, etc.

Designing using the newest features but keeping your design usable and attractive in legacy browsers is called progressive enhancement. Just another layer you should be thinking about as you’re crafting your masterpieces.

Hopefully these questions will help form a clear path of communication with your developers at the outset of a design process. Knowing your constraints ahead of time helps give you a set of “rules” to design with, and setting up correctly will alleviate many, if not most, of the issues that happen between the design and development phase. Measure twice, cut once.

Read the next chapter

Learn to work with developers, not against them, in this free e-course by Kevin Tomasso and InVision. Sign up here to get the other chapters of this e-course delivered straight to your inbox, completely free.