Glad You're Ready. Let's Get Started!

Let us know how we can contact you.

Thank you!

We'll respond shortly.

  • Blog Navigation
Best practices for designer/developer collaboration

Successful product development requires effective collaboration between designers and developers. That sounds nice in theory, but what does it mean for your team on a day-to-day basis? Here are some specific practices that you may find valuable:

Check-in about design status every day: Designer reviews the backlog after standup with the team to ensure that the team is not blocked by any design-related issues or questions.

Name your components: Designers create objects and name them. Design these in high fidelity and render them on the style guide.

Sit with the team: Designers overhear design conversations that are happening between the product manager and the developers.

Two designers, two projects: Allocate two designers to work together on two projects. They work half time on each, enabling them to collaborate all the time without charging the client for two designers.

Develop interactive wireframes: Designers create clickable prototypes early in the process before locking in the final design. These are used to perform user testing and to evaluate cost with developers.

Communicate layout mechanics on mobile platforms: Developers communicate platform-specific constraints to designers to ensure that designs are not created that cannot be built.

Create and post personas: Start by posting lightweight personas on the wall that are just sheets of paper with names on them. As pieces of the personas become apparent during discussions, update them. This helps to clarify that each feature is being built with a clear idea of its target audience.

Give design practices names: Naming best practices allows them to be codified and referenced as part of a standard, shared vocabulary.

Spike on designs in code: Developers use SASS, HAML, and Ruby to quickly build out potential designs without tests, to be thrown away afterward.

Use persona names in tests: Instead of creating new names for users in tests and fixtures, use the names of personas.

Designers write HTML and CSS: Instead of leaving all of the coding to developers, designers take ownership over the HTML and CSS associated with their designs.

Pair designers and developers: This enables designers to learn about development and developers to learn about design. It is better suited to web development than mobile development since it is easier to iterate rapidly on HTML and CSS than on native code.

Build low-fidelity prototypes with high-fidelity components: Designers don’t build high fidelity designs across the board, because doing so results in some designs going out of date. Instead, they build low fidelity mockups with high fidelity components.

Externalize everything: Make all design decisions visible to the entire team by posting designs around the team’s workspace.

Show evolution of designs: Post historic designs next to their revised counterparts to show the evolution of the team’s designs.

Create an idea board: Build an epic-level reverse-Kanban board with three columns: “Now”, “Next”, and “Later”. Generally you’ll have 2-3 cards in the Now column, another 2-3 in the Next Column, and the rest (~20-40) in the Later column. The idea board externalizes future epics, gives stakeholders a place to park long-term ideas, and gives a big picture view into what the team is working on.

Design studio: Designers from different projects get together to collaborate on each other’s work and provide actionable feedback.

Represent design needs with labels in Pivotal Tracker: Use two labels “UX design needed” and “Visual design needed” to depict whether stories are blocked on user experience design or visual design.

Involve designers in early stages of feature design: Product managers should collaborate with designers from the beginning stages of new feature design.

  1. Hi George, this is a nice list. I wonder what your thoughts are on design specs?

    We’ve found that creating specs of all the type, color, and spacing info that developers need to implement a design makes the whole process run smoother, which inspired us to build a tool to make this easy to do.

    Originally, I come from the real estate development world where nothing gets built without architectural blueprints. In the digital world there is a higher margin for error so many design-development teams forego design specs, but I think it hurts them in the end.


  2. Thank you George for this great list.

    It can be seen as a quick guide for beginners as well as more advanced collaborators. I’m glad that we already cover some of the provided best practices – the rest helps us to improve our app (design & dev collaboration).

    I’m also interested to know your opinion on specs and how this might facilitate the work between the two roles.

    Rgds Josip

  3. Kim says:

    I agree, design specs or style guide make it possible for all players on the team to be on the same page. You also save a lot of time in the end and a similar guide can be used for other clients. It saves a lot of time, and shows you are a professional.

Post a Comment

Your Information (Name required. Email address will not be displayed with comment.)

* Copy This Password *

* Type Or Paste Password Here *

Share This