I need a cake that tastes exactly like the one in this picture. Designers often work in tandem with developers when starting new projects. There is a lot of back and forth bantering on whether or not your button should be 20px tall, or if the menu animation should be a slide in or a complete overlay that fades over the top of the site. You can spend a lot of time bickering over a developer’s interpretation over what your design is supposed to look like and how they “mucked it all up.” “That header wasn’t brown, that header was #6a1a1f” Why don’t you give them the list of ingredients too? Seriously, who can bake a cake from scratch without looking at a list of ingredients? Usually I am the person who is following the instructions to a “T” with an image representation of how it’s supposed to turn out at the end. Of course, I understand that things may be slightly different, or the size of my containing pan could change how the frosting and toppings are distributed. Design is the same way. You can’t give a developer a static picture and expect everything to be hunky-dory when they come back with the first prototype. To create this list of ingredients, during the design process, you should be documenting as you go. Start documenting when you start a new project. Last week I had written about how to write more effective case studies and that for an effective case study you need to automate your writing process. Writing needs to be part of your workflow. It doesn’t have to start as large articles every morning, but what would make writing easier is to start with small snippets. Grab yourself a cheap notebook to write in that when you start your work for the day, it will be nearby. When a decision comes along, jot down specifically why you are changing, creating, or keeping a part of the project
An un-bulleted list of choices made throughout the early stages of design. It’s easy to start writing and it’s easy to stop writing. You have to make a conscious effort to keep the process of documenting your decisions through to the conception and iteration stages of the design process. When it comes to iterations, explain what you’re trying to achieve If you have access to the developers working on your project you both should know what problems you are trying to solve in the project. You should be iterating ideas with them and coming to these conclusions together, because what you design could delay the process with the developer if there isn’t an effective way to execute that decision. Having a bit of information on your wireframes could help you and the developers know what you were trying to achieve through the iteration. You can anticipate what problems you might run into when executing, and leave some considerations for edge cases and empty states. Especially if your brain is in an empty state and you can’t remember why you designed something the way you did This documentation doesn’t have to be long form paragraphs of content, just write the small details of what you want to do with the design and when you pass off the work, it’s there for you to talk about.
Creating a design system vs a style tile Style tiles are a great and effective way to get your design ideas across. You can have them set the base stiles for a lot of different elements across a single design. When you’re handing that of to the developer though, it becomes a large issue if you don’t tell them what you’re trying to do with the design. See below: a design system with captions, help text, and reference tags, versus it becoming a style tile when all of that was removed.
images are condensed for illustrative purposes. There are many reasons to use a stile tile in the process of visual design, but during development it becomes very busy noise to add to their workload. Creating a design system elevates that tile into a guide that deconstructs the elements into clear cut examples and explanations on what each piece actually is. They enhance the ability to dissect a high-fidelity mockup, decreasing the amount of “what the heck is this size supposed to be” from developers. Do not write off the most effective part Writing case studies shouldn’t be as difficult as people make it out to be. You start with documenting small things first. If you have a quick change, here and there, put that into a short note in your notebook or sketchbook. Then when moving to wireframes and element design, you start to explain some of the decisions you are making and why you’re choosing that part of the design. Then when you move into design systems and static mockups you write out what your intentions are with the design, what colors and fonts you are using, what size your header should be. . . etc. The best part is, you can put these notes into a final written document alongside your deliverables and assets. It’s easy nowadays to create a snapshot of something you’re working on. You can take pictures of it on your phone and put it in a document. You can take a screenshot of your computer screen and upload it. You have many tools to capture what you are working on and edit notes (on, around, above) the images to show what it is you are intending to solve and what the measurements are. So if you want your developer to bake you a cake, make sure you give him the list of ingredients, an image of the result, and your best instructions on how you made it.
Darian Rosebrook is the Lead Designer of KeySpark. He works a lot with the crazy developers and has since been working on collaborative projects with many different developers. We recommend checking out Invision’s “Designing with your developer in mind” course they put out. If what you just read was helpful, consider sharing and liking this to help others out too!