Designers and developers need to be able to collaborate, helping them do that is a bit of a theme on our blog. One of the best ways to do that is sending over a design file and having a look at it. Seeing a mockup is still an incredibly useful way of communicating a design even in our world of breakpoints and responsive grids. But we have a problem. Photoshop, Sketch and other software programs used by designers are really complicated and not every developer is skilled at using them. They don’t have to be masters in Photoshop but they do need to reverse engineer what you’ve done. Often for more than one file.
Design projects require a lot of communication. A lot of it can be necessary and wasteful, if we plan ahead and have a good, solid, defined structure to our projects then we save ourselves suffering a lot of “hey, where is…” and “Can you send me that..” type scenarios.
Preparing design files for delivery is an art form as well. Often time, it’s the first time the project will have been opened on a computer that isn’t the designers own. A few tips and tricks can speed this up massively.
Preparing Your Design Project Files
Your files and how they are collected reflects on you and how organised your project is. Depending on which visual design tool you’re using your files layout may change slightly but the general rules are the same.
Photoshop & Illustrator
Using Photoshop or Illustrator? Have a separate file for each screen or template? Within that screen have a separate art-board for each breakpoint. It is super useful to be able to look at the flow of a template at various screen sizes and breakpoints.
Sketch
If you are using Sketch you can have a single file with multiple pages and art boards. It is super useful to have all of your assets in one place, as long as it makes sense organisationally.
Misc
Keep your project assets handy as well. Keep a folder along side your templates with your assets. Fonts, Photography, Illustrations, Logos, Icons and any other assets that the developer may or may not need to get the build right. Particularly, make sure your type faces are there. The web is a Typography based medium so if those are wrong the whole thing is going to be off and no one likes dealing with missing font dialogues.
Have your Documentation around as well
It is incredibly handy having access to your user journey documentation, site maps and any other documentation that you may have.
Show your prototype
If you have a Prototype you made using inVisionApp, FramerJS or Craft when you were testing the design’s user experience then add that to your project as part of your documentation so the developers can see it and ask any question they need to.
Preparing Your Design Files
You’ve got your overall project sorted, now it’s time to get your individual files sorted.
Only have whats needed in there.
Chances are your files are loaded with little experiments and ideas you tried but were unsuccessful in taking forward. Get rid of them. They are littering up the file. Design files with hundreds or maybe even thousands of layers can be confusing for the people who made them, never mind someone who is trying to work with them. Be kind and take out anything that doesn’t need to be there.
Label & Name Things Properly
Help people out when they are working with your design files. Name and label everything, use groups to bring related layers together and make it clear what is for where.
Be Consistent
Got 5 or 6 different versions of that same red? Should they all be the same as the logo? All the major design platforms now have tools to help you be consistent with your text and other elements. Use your character styles and paragraph styles to make sure that there is a level of consistency to your design. You can make a consistency in the style of your logo by using a logo maker just like the ones from GraphicSprings.
Consider the space between elements
The spacing between items in your design is just as important as any other consideration. Make sure you document the spacing between elements as well as the actual elements themselves. Markley/ and Specctr are both great tools for carrying out this process.
Don’t destroy things
When editing graphics be careful not to edit in such a way that you destroy pixel data. Always favour masks and clips over crops and cuts. Your developers may need to use the extra image data should the image have to stretch for different screen sizes.
Use SVGs and scalable graphics where possible.
We want your design to look great at every screen size and pixel density. Use SVG assets where you can and if you can’t then remember to export any assets at 2x and 3x resolutions to make sure they can be used okay. It’ll save your logo being pixelated.
For more great tips on Preparing design files checkout Photoshop Etiquette
Other Approaches to Consider when thinking about designer developer collaboration.
There’s more than one way to skin a cat when it comes to helping designers and developers to collaborate.
Consider a Style Guide
Using tools like Zeplin you can upload a design file and it will give you back a style guide of colours, type and components. These can be further documented by the designer to help the developer understand what is going on in the design and the project as a whole. They help with consistency as well, they make designers justify tiny variation and defend the complexity they may have added.
Build Fluid Wireframes
One for the “Should Designers Code” set but CSS frameworks like Twitter Bootstrap and Zurb Foundation make it very easy to get started building a prototype responsive layout to show developers. They probably won’t reuse your code but it’s a great way to show them how you want a responsive design to work.
It’s Going To be Okay.
Getting your designers and developers to collaborate and collaborate well, can be hard but it can be done. A little forethought and treating the design files like a shared resource everyone has to use and understand (like a kitchen) goes a long way. The same thing applies to developers. They will often share a code base and you should expect them to treat the code base as if it were a shared space.
