If you’re a designer or a developer you know this story all too well: designers create a beautiful prototype or set of wireframes and ‘throw them over the fence’ to the developers. As the developers find that bits and pieces of the designs are either too labor-intensive or simply impossible to implement, the original designs slowly evolve during each sprint. 

What starts out as the Tesla of designs gets turned into a practical Subaru, with all the safety features and no-frills… or it ends up looking like a beat-up junkyard scooter with no wheels. 

Designers start muttering something about pixels and padding, devs send passive-aggressive Slack messages, and coffee break encounters become frosty. 

Why can’t we all just get along?

Including developers in the design process and designers in the development process can help you develop a much better workflow and outcome by combining their different expertise and perspectives. Does it really make sense to have this division between two teams building the same product?

In the end, if you look deeper, the real source of conflict comes from two factors:

• The system (or lack thereof) in which the two teams work together
• Team dynamics and environment

The problem is, when you search the internet for best practices on how to help these teams work better together, you often run into extremely vague and very “self-help” sounding principles: communicate, collaborate and co-create. 

During TNW’s Sprint Couch Series, Rangle.io’s Lead Visual Designer, Trish Lamanna, and Solution Architect, Omer Wazir, shared how they created their own integrated approach to ‘Dev-ignOps,’ enabling them to become more cross-functional, self-organized, and increase their velocity. 

Here we’ll share how they turned the three C’s into practical steps which they could operationalize at Rangle, plus advice on how to create the right environment for successful cross-functional ops.

1. Develop a common communication model

According to the Rangle team, communication isn’t about the tools you choose, it’s about the model you use to approach problems, make decisions, and share information. It’s important to consciously choose and develop a communication model that works well with the size of your team and the outcomes you want to achieve. 

Lamanna explained that if teams don’t have a set operational model in place, they’ll automatically default to a waterfall system in which designers come up with the design concept, hand it over to developers, and move on to the next project. At the same time, it leaves no room for cross-functional feedback loops and iterations. In large teams with 20+ people focused on work-intensive and complex projects, a tiered approach is much more practical. 

Meanwhile, smaller teams of under five people tend to use a swarm approach to problem-solving, in which everyone gets together to brainstorm, share feedback, and make decisions. There are no hierarchies and everyone’s opinion is heard, leading to cross-functional solutions. You’ll typically see this in smaller marketing teams working on content improvements to an existing CMS.  

But what if you want the best of both worlds?

At Rangle, Lamanna and Wazir were tasked with building an app that would connect to a medical device with a medium-sized team of 14 people. They realized that a purely swarmed or tiered approach wouldn’t work for them.

Instead, they decided to create a semi-swarmed problem-solving approach. This meant that in between their artifact flows they’d swarm together to identify potential problems and create a plan of attack. Then they’d separate to solve those problems in a tier-based structure. 

2. Establish collaboration rituals

To operationalize your communication model you need to set specific ‘rituals,’ or touchpoints, during which your teams or key players get together to collaborate. This could be in the form of:

• Weekly internal team meeting reviews
• Product Owner gut checks
• Ceremonies and demos
• Design to development ticket flows on Jira

By establishing rituals, the Rangle team was able to include designers, developers, and product owners in the solutioning process, identify potential problems and opportunities for additional functionality early on, and discuss how they would tackle other dependencies down the line. 

For example, when developing a medical app for an EU-based client, they realized they would need to consider how privacy and GDPR regulations could already be integrated into both the design and coding. This allowed them to come to a common and coordinated plan in advance without having to make last-minute, time-consuming changes on either side. 

3. Create a plan to facilitate co-creation

Finally, co-creation is all about taking your communication model and collaboration rituals and putting them together into a common workflow plan. 

To create an effective plan, you need to consider the practical questions that could hinder or facilitate co-creation between the two teams. 

Some of the questions Rangle considered were:

• What information does design need to share with development in order to allow them to anticipate what’s coming tomorrow?
• What can be done in parallel?
• How does continuous improvement happen over time?

In the end, Rangle’s co-creation plan consisted of weekly tiered sprints. The design process was always one week ahead, giving developers time to share feedback and concerns before design handed over the next set of components to them. In this way, developers could already anticipate the work that would be coming their way during the next sprint and improvements could be made continuously throughout both the design and development process. 

Creating an inclusive and integrated system is great but, as Lamanna mentioned, you also need to focus on creating the right conditions and behaviors for it to actually work. 

4. Build psychological safety

Creating a psychologically safe environment is key.

Psychological safety is the belief that you can share your ideas, concerns, opinions, and mistakes without the fear of being humiliated or punished. In a study, Google found it was the most important factor needed when creating highly effective teams. 

Even if you set up a number of feedback loops and design/code review cycles, they won’t be effective if people don’t feel they can actually speak up freely. 

In a TedTalk, Harvard Professor Amy Edmonson (who coined the term) shared three ways to develop a psychologically safe work environment:

• Frame the work as a learning problem
• Acknowledge your own fallibility
• Model curiosity

5. Make your work transparent

Make sure both teams share a common space where they can see what others are working on in between collaboration rituals. 

This doesn’t necessarily have to come from a collaboration tool. Simply printing out designs and storyboards and putting them on a wall in your office where developers (or anyone in the company) can casually walk by and see the latest designs during a coffee break can actually make a huge difference. 

At Rangle, Lamanna and Wazir shared that all project discussions, whether on Slack, Jira, or GitHub happened on public channels so people weren’t left out of the loop. This is especially important now with most teams working remotely. 

6. Develop a common language

In an episode of Google’s Designer vs Developer Youtube series, Senior Interaction designer, Brendan Kearns, explained that redlining usually happens when designers and developers are speaking a different language. 

More and more companies are now creating design systems, or libraries of designs and codes, which can be easily reused for different projects. Airbnb calls their version a visual language that allows them to build products faster and ensure consistency across the organization. Interestingly, a few years ago, the company also started working on an AI tool that automatically generates sketches into product source code. 

Although time-intensive, starting your own shared design/dev library ecosystem which can be continuously developed over time will save you tons of time in the future. 

Check out this interesting talk by web designer Brad Frost for more on the technical side of design systems. 

7. Encourage knowledge sharing 

Understanding and respecting where each side is coming from is key. It’s surprisingly rare to find those designer-developer unicorns who know how to create a wireframe and code it themselves but it is clear that, if you’re lucky enough to have them on your team, they often bridge the gap by identifying potential issues ahead of time and mediating conflicts.

Offering learning and knowledge sharing opportunities can go a long way in bridging the gap between these teams. The more designers understand the coding that needs to happen behind the scenes to create their designs, and the more developers understand the importance of creating seamless user journeys, the better. 

Getting started

Every team, company, and problem is different so you’ll need to test, review, and optimize until you find the system that works best for you. 

As a starting point, Lamanna and Wazir suggest first considering the outcomes you want to achieve and working back from there. Do you want to make delivery timelines more predictable? Close tickets faster? Create self-organizing teams? Then create a system that will help your teams to get there.

This article was brought to you by Rangle.io.