Unit 1: Intro to Design
Unit 2: Figma Fundamentals
Unit 3: The Creative Process
Unit 4: Color Theory
Unit 5: Introduction to Illustrator
Unit 6: Typography
Unit 7: Layout
Unit 8: Typesetting
Unit 9: User Interface Design
Unit 10: Design Systems
1 of 2

Design Documentation

Now that we learned good practices of design to development handoff, let’s take a look at design documentations to solidify this process.

Without proper documentation, none of the best practices we talked about will work when the development team needs reference but can’t find them.

First of all, let’s talk about prototypes. We just learned about it in the previous unit.

Provide a prototype


Interactive prototypes are very useful for several different reasons. Providing a prototype can help everybody on the team better understand the common goal and where the product is headed.

They can help illustrate the navigational structure intended for the website, as well as the primary user flow, animations and interactions, and the internal linking of the site or app.

Next, we need to make sure that the entire design team establishes a design system from Day 1. We have a complete course in Design System, if you want to learn the process from beginning to end.

Design system


Consistency is the key element in every successful collaboration. Consider building a style guide for developers and turning it into a design system.

Not only will this improve the designer-developer collaboration, but it could also make your product more consistent, especially as you scale.

Naming conventions

It is important to note that the design system does not only deal with design elements, but it is also responsible for handling naming conventions in all phases of the process, in both design and coding.

Have clear expectations around how designers and developers should name and label each component, asset, and file. Be consistent with revision naming, and your method for organizing it all. It’s tedious, but it’ll save a ton of time and effort if and when you have to go back later.

The layers

When a design is handed over to the developer*,* multiple layers of information need to be conveyed*.*


Naming your files: The file/screen name should not possess any form of versioning, it should merely describe its function.

Plus, make sure you use consistent casing when naming your screens.

Keep only what’s necessary: During handoff time, you should have a clear idea of the product you are going to create. To reinforce this, weed out all previous iterations and explorations. This will also result in simpler filenames.



Make a flow: Once the mockups are out, stitch the screens together. This helps the developers plan their approach to code.

Figure out the fidelity: Not every screen has to be fleshed out with high fidelity prototypes. Some screens could simply be static with explanatory comments. There is no reason why you should spend much time prototyping a simple interaction pattern that already exists.


List all the copy in a 3-column table using any cloud tool of your team’s choice. There’s always a lot of copy that can’t be shoehorned into the UI prototypes, so you will have to record them somewhere else.

Copy table

First, specify the type of copy. This helps developers quickly parse through the list. Second, specify the situation and the context of the copy.

Mentioning the context helps the developer understand when the message should appear/disappear.

Last, add the actual message.

Specs & assets

Automate: Save yourself a lot of time with automation. There is no need for you as a designer to waste a vast amount of time redlining the designs with specs, measurements, and style guides.

All you have to do is appropriately organize the layers and groups in your design file and let the automation tools take care of the rest.

Accountability: Automating the handoff process gives designers the authority to question the developer in case there’s deviation from the prescribed designs.


One of the most nerve-wracking parts of any design execution exercise is the phenomenon of missing designs.’ There’s always an edge case or two missing from shared designs.

You can avoid these last-moment issues by:

  • Maintaining a checklist **of all the cases and features that need to be designed;
  • The checklist will flag the status **of the feature being picked up or not, and whether it is completed or in progress. All the completed rows should have a link to the corresponding design.
  • If a specific feature is moved to the next version because of a particular dependency*,* then the corresponding team is marked along with a description*.*

Finally, let’s talk about animations.


Animations are usually considered the cherry on top of the design, but that does not mean that this phase should be underestimated. Micro-interactions and animations are an essential part of adding a touch of personality to the final product, and they also improve the overall user experience.

The animation handover can, however, be problematic because the most frequently used tools only provide visuals. For the developer to understand all the parts of the animation they need to have either:

  • a well-written specification and a long conversation with the front-end developer;
  • a great front-end developer who figures out every detail of your well-designed interaction.
Scroll to Top