Unpacking cross-discipline collaboration
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.
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).
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
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.
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.
