10 commandments for better designer-developer collaboration

The whole product experience is a cumulative effort of diverse project roles and talents, not a ’rockstar soloist.’ Even though some of them might represent two opposite ends of a spectrum – like designers and developers – they have more in common than one might expect.

Furthermore, they can benefit from both opening up to each other’s perspectives even more and following the same common principles for better teamwork. With that in mind, here are some insights to help improve designer-developer relationships, and hence better product design.

Table of contents

1. Designers and developers are stakeholders too
2. Hook up as early as possible 
3. Keep the creative juices flowing
4. Panta rhei 
5. Embrace the collaborative mindset
6. Use the tools to your advantage
7. Think in systems
8. Well Done is better than Future Perfect 
9. Walk a mile in their shoes
10. Have some respect

Designers and developers are stakeholders too

We always acknowledge the end-users’ exigencies and preferences when envisioning the experience. But on the way to the final product, there are other stakeholders whose demands should be considered: the team members who have to work with the mockups, designs and codebase of the growing system. 

With this approach blended into your practice, every workflow or documentation decision should start with the team in mind. Similarly to validating our design or architectural decisions, we can reflect on the quality of our collaboration and develop a working model that delivers on their needs. In the same way we adapt our design solutions to what users require, we should adjust our project workflow and the knowledge base to accommodate the needs of our teammates.

Hook up as early as possible 

It’s still a common misconception that coders have no interest in the business domain or bring no valuable contribution to the design process. Just like designers are not only pushing pixels, most developers care about delivering actual value to the world. 

Set up multidisciplinary workshops early in the project to energize the team, generate creative excitement and provoke unconstrained flows of ideas. Including various stakeholders from the start will spread the domain knowledge and language across the whole team, establish rapport and allow everyone to look at the problem from different perspectives, which is often an eye-opening experience. 

Assign roles and responsibilities so you won’t get in each other’s ways or double someone’s job. Agree on communication protocol to streamline your thoughts at the speed of light and create a glossary so everyone is always on the same page. The whole team must speak the same language to make the project succeed. Literally and figuratively. Otherwise, the team might confuse UI components and interactions or even mess up the whole architecture, creating a multifarious evil that doesn’t solve the problem and cannot be overcome by a single commit. 

Keep the creative juices flowing

Don’t limit your interactions and group activities to kick-off meetings – eventually, you are two sides of the same coin. Keep everyone involved throughout the action to nurture an interdisciplinary project environment. Align judgment  and knowledge to rule out uncertainties and ensure the final experience is being implemented above and beyond the designed artboards. There are more constraints and rules than color codes or keylines, and you have to work hard around them to maintain the clarity of the experience. 

When designers and developers are interfacing throughout the project, they render more effective results with fewer bugs, cleaner code and less refactoring. As digital projects grow and become more complex, teams are valued for their creative collaboration and providing business value rather than specific deliverables. That’s where most teams can draw the line between good and great products.

Panta rhei

A successful product launch is just a milestone on a long and, hopefully, rewarding journey. The baptism of fire starts when real users start confronting your product with devices of all shapes, processing powers, displays and internet connections, real-life situations, distractions and interruptions. It’s tempting to shift accountability to the support or marketing team after the release, but that’s never an equitable or even viable solution since you all have a common goal of constantly improving users’ lives. 

You won’t find two identical problems or team compositions to work with – the puzzles you know from the past have already changed their context and need a fresh approach. With very few exceptions, you’ll have to refine your habits and workflows each time you start a project (or even sprint) to accommodate new circumstances. There’s no one way of creating and collaborating that works across every case. 

Each day, your skills, tools, and outlook evolve along with your personal and professional experience. The same inexorable process applies to your team, state of technology, users or stakeholders. In fact, there’s not much you can control. Fresh team members, scope changes, new frameworks, enactments, world crises and successes – you’d all better fall in love with the idea of changes for no single thing in this universe is fixed or certain. Learn how to identify the new rules of the game and adapt the play to the favor of your whole team. Otherwise, you’ll have to deal with a two-speed organization. 

Embrace the collaborative mindset

The way designers and developers collaborate has changed many times throughout those years. Tools, frameworks and methodologies are constantly evolving, adjusting to the ever-changing state of technology. They are all meaningful explorations inspiring further growth of our industry – we would keep cutting HTML templates based on a locally stored mockup without them. At the same time, keeping up with this bandwagon might give anyone a headspin. And mindful use of all of the new blessings of technology on a proficient level is nearly impossible. 

Some methods work better than others and, in many instances, a process that worked well with one project ended up being a disaster with the following one. Any definite guidelines would have to be updated every few weeks taking your focus and attention from real life. That shouldn’t be a problem if you aim for teamwork instead of a fixed game plan. A collaborative mindset has a longer life span and stimulates a smoother process for product teams of all shapes and sizes.

Use the tools to your advantage 

One of the most important revolutions in the product development process came with the handoff tools that replaced manual translation of the mockup with handy code snippets, assets, and specs for different screen sizes in one easily accessible place. 

Each team member can now find dozens of apps dedicated to designing, prototyping, whiteboarding, creating user flows, managing version control, creating animations, recording and analyzing sessions, no-code app builders, time-trackers, code editors, automated code review tools, tools for monitoring app performance and crashes, etc. 

Many of them easily automate the hard and mundane work, make your process more error-proof and smoothen the edges of the collaboration between different project roles. 

Be careful! While it’s tempting to use all the possible enhancements in the project, keeping up with the new features and juggling apps could lead to multiple sources of truth and diminishing productivity. 

Think in systems

Regardless of your role, try thinking about your entire project as a hierarchy of layers bonded together in the form of components, templates and systems – not as a bunch of pixels. Creating a collection of mutually dependent, reusable elements that can quickly reflect different brand identities with only little adaptations gives a jumpstart on the project and aids product teams in focusing on the high-level vision instead of going into bits and pieces of styling, components or even templates. With a single source of truth, such a well-defined design system built around those components, both designers and developers are more likely to avoid inconsistencies; and these can happen even within smaller projects. 

To make a common ground even more structured from day 1, utilize existing design system methodology – ex. Atomic Design created by Brad Frost. You can learn what it is and how it can benefit product development in Olek’s previous post: The good, the bad, the system – Atomic Design

Or go into detail in  Brad’s book: Atomic Design by Brad Frost

Any addition of design principles and rules on using typography, colors, and patterns will make the design more effective for the whole team and add some educational value. 

Well Done is better than Future Perfect

Not to be confused with “Done is better than perfect”. 

Both done and perfect are virtually unachievable as products are never entirely done, and excellence is a matter of individual measures, social agreement and cultural conditioning. The problem is that this saying often justifies launching a bare-bone, sloppy MVP as a validation of the business model that will be refined over time should the product receive positive reviews. But poorly designed and executed products won’t attract attention, provide relevant conditions for testing or build trust as they might look like wireframes or spam sites. They might also make it difficult and expensive to maintain, adjust or add new features. 

All the above is true for any stage of product development and project deliverables. Stakeholders might grow impatient waiting for the final docs, urge for unfinished designs and build up wrong assumptions that might affect future development. On the other hand, the team might suffer from imposter syndrome and spend eternity polishing each pixel and each line of code or searching for new functions to add instead of launching the MVP with a solid Unique Selling Point. 

Cultivate agility to keep the releases flowing and let a healthy dose of perfectionism protect you from inconsistency, bugs or vulnerability. 

Walk a mile in their shoes

It wouldn’t hurt a designer or a developer if they learned the specifics of each other’s fields, and they don’t need to be expert full-stacks. Still, a bit of domain knowledge would help everyone understand how things are built and foster better collaboration and appreciation of their respective work. 

A smattering of technical know-how might help designers feel more comfortable when discussing software architecture, estimating the complexity of interaction, creating a quick prototype in the browser or modifying the properties of the SVG file all by themselves. No coder has to be a visual artist, not even a front-end developer, and their primary focus lies on servers, databases and frameworks. But at the most basic level, a healthy dose of design knowledge gives the developers some dexterity and autonomy in smaller projects that don’t benefit significantly from the designer’s insight. 

Have some respect 

It should be evident by now that we are all in the same user-driven boat, and we should steer in the same direction. That might be demanding with interdisciplinary crews, but nourishing diverse culture attracts the brightest minds and thought-provoking challenges. However, recognising each team member’s significance and contribution to the superior goal is the prerequisite for engaging and gratifying cooperation. 

Besides respecting meeting schedules and agendas or letting people stay in the deep work, you can give consideration to your team members by being more transparent, empathetic, and mindful of other people’s efforts and expertise. Assume your colleagues have the best intentions and work to the best of their strengths with the resources available. Stay curious about the reasoning behind their decisions – usually there’s more in each action than meets the eye!

Use these commandments to nourish the team spirit

Whatever role you’re playing in the project, following those ten commandments will help you understand the creative dynamics of your team and approach the collaboration process with more courage and consistency. Even if some of those ideas might seem to be knotty and time-consuming, in the long run, the gains in innovation, efficiency, and satisfaction of all stakeholders will be well worth the investment.