Unpacking cross-discipline collaboration

Lacey Kobriger
Designing Atlassian
6 min readApr 7, 2022


People illustrations by Storyset

Cross-discipline collaboration can be challenging. Especially if your team is remote or taking a hybrid approach to time in the office, it can be easy to fall into a rhythm of validation. Collaboration, in its truest form, happens when the whole team — including designers, developers, and product managers — all come to the table to understand the problems we are trying to solve and find potential solutions. Building more collaborative teams is a journey, but one way to start is by understanding what collaboration means and where your team is starting from.

Are we really working together as much as we think we are?

A few years back, I sent a survey to designers and developers who were working together on native mobile projects. I wanted to collect some feedback on how teams were working together to find opportunities to improve our project processes. As the results rolled in, I became increasingly surprised.

Infographic with two circles representing percentages. The circle on the left shows 79% full and says “Designers who reported collaborating with developers”. The right circle shows 23% full and says “Developers who reported design collaborating with them.”
Despite being on the same projects, 79% of the designers said they had collaborated with developers, while only 23% of developers reported a designer involving them in collaboration.

A majority of designers felt they were collaborating with their developer teammates when they were actually just reporting decisions or validating designs. This reality made both sides more reactive and defensive in light of new information or during discussions.

Designers cited frustration or fear in starting conversations with their teammates as a blocker to getting developers involved earlier in the process. Many said they were afraid of being told “no” and not understanding “why”. Other designers said they did not always see how developers could participate in design beyond commenting on wireframes. Others were worried that if they were not making design artifacts and owning UI decisions, they wouldn’t be providing value to the team.

Developers, on the other hand, cited frustration with designs that did not leverage system components or behavior and, instead, opted for custom functionality for unclear reasons. Some also felt that they were not always the best at communicating constraints and technical considerations to designers. They acknowledged that they were not always as empathetic to their design teammates as they’d like to be.

Does this sound familiar? I know I experienced this in my career. I have crisp memories of parading developers past a wall covered in UI comps I had carefully and lovingly hand-crafted to perfection. I would ask some flowery version of “so…can you build this?” For all the hard work we put into our solutions as designers, and how hard the developers tried to fill in the inevitable gaps and ideas that blew the scope out of the water, I always found that the whole team was pretty disappointed in what we wound up shipping.

It took me a long time to realize that the way I saw my value as a designer – an artisan of screens and weaver of solutions – only made our product worse and my team frustrated. I needed to look at things in a different way.

Shifting our thinking

Everyone on the team, whether they have the title of “designer” or not, has valuable perspectives that can elevate our work. As designers, it’s easy to feel like we need to make all the decisions, especially at the start of a project. However, if we set ourselves up for the team to co-own the work -- from kick-off to shipping a feature -- we can find better solutions and reduce or eliminate hand-off friction (because ideally, there is no hand-off).

A text diagram with two columns. The left column says Design Lead equals Managing Ideas not deciding what to build. The right column says Design Lead equals Managing Ideas equals Identify who knows best.
This is a slide from Barb Spanton’s 2016 MWUX Talk: Everybody’s a Designer! How to Work in Cross-Disciplinary Teams So Everyone is Happy. Barb suggests that collaboration happens when designers release sole ownership of deciding what to build and, instead, focus on managing ideas and uplifting the voices of folks who may have more expertise or insight.

When designers start to see themselves primarily as facilitators and curators, we can give others a clear role in the design process. But what does that really look like? How do we break the cycle of making wireframes before getting feedback? How can we align as a team and avoid “design by committee”?

How to create a collaborative digital team space

A gif from Captain Planet showing the “Planeteers” using their magic rings

By your powers combined!

Collaboration is frequently confused with “design by committee”. Collaboration is about co-ownership, elevating expertise, honoring critique, and working towards a shared goal. On the other hand, design by committee is usually focused on compromise or consensus, not finding the best solution for the problem. Exploring and establishing the desired outcomes of work is the first step and will allow everyone to assess ideas against our shared goals. We need everyone’s voices to find the best answers in every phase of work.

Collaboration helps us arrive at the best solutions within our constraints, not compromises.

Facilitator — not decision maker

Although certain roles may ‘own’ a phase of work, at no point should anyone own all decisions. Intent should be applied at every level of our process. As a team, be conscious about working transparently, encouraging everyone to participate, and relinquish the floor to the people who may be best equipped to make a decision. The facilitator should take the lead on documenting what the team decides but is not making decisions in isolation.

Jared Spool’s broken comb concept, introduced in this talk, can apply to teams, not just design.

Design is more than the sum of its artifacts, embrace the value of facilitation.

A gif of David from Schitt’s Creek saying “umm” in a sassy and pensive way.

Shift from “is this possible” to “should we”?

Instead of asking if something is feasible (most things are given enough time and investment), dig into if the solution makes sense for your product and stated problem/objective. Explore ideas or potential solutions through the lens of your design system, platform standards, usability, and maintainability. It’s ok to say “no” if suggestions do not fit your outlined objectives. It’s also important to prioritize - use your goals, timeline, and team size to help you draw a line between what is necessary, what is nice to have, and what is an idea worth cutting.

Validation only explores feasibility. Collaboration amplifies quality. Build systems, not screens.

Take the time to brainstorm as a team

Throughout the process, it can be helpful to put a digital marker in someone’s hand. Ask folks to draw, code, or share ideas in a format that allows the team to go on the journey together. Keep the floor open to spar ideas and use your project goals to identify what should be pursued more deeply. Don’t be afraid to have takeaways and follow up instead of making decisions without necessary insight. By having a shared understanding of how we arrived at our decisions, we can deliver better outcomes faster than if we worked separately.

Read more about collaborative tactics you can use on your team.

Amplify exploration and discussion, not always having the right answer.

Create a digital home base

Having a digital whiteboard as your “home base” can be a really valuable rally point for teams and keeps work transparent. You may find yourselves using a variety of tools to facilitate this — Trello, Confluence, Slack, FigJam — but what is important is you have open spaces for folks to interact with the current state of work and contribute beyond just leaving comments. You may also want to consider if you need one tool for ideation and a different tool for final documentation. Find what works best for your team!

Use tools that create open spaces for everyone, not just windows to the work of some.

Collaboration is a journey

Building teams that solve problems together is a process that naturally evolves over time. It takes time to feel comfortable working together, develop a shared vocabulary, and find tactics that work for the folks in the room. It can be hard to change your habits, but taking small steps can make a huge difference. In some ways, getting started can be the hardest part, but committing to learning how to grow in this area makes our work, our teams, and ourselves better.



Lacey Kobriger
Designing Atlassian

With over a decade of experience in product design, over half of that has been spent growing and elevating the craft of native mobile design.