How to facilitate collaboration — 5 methods, ranked.
The core of my job is to facilitate mass collaboration.
I work on an internal design system that serves over 40 distinct teams, all of which build the products and services that make up IBM’s cloud offering. With so many separate teams, how can we ensure the cloud feels like a single product, and not like a mash-up of 200 different products?
My team owns and develops a toolkit with design and development resources that provide guidance to all the separate teams. So essentially my team is the glue that makes the UI cohesive. The magic of my team however, is not the toolkit itself, but rather the collaboration we've facilitated in order to build the resources in the toolkit.
Although our team is equally dedicated to supporting both the designers and developers on our teams, for the sake of this article I am going to focus on collaboration among designers.
Let’s just say it, collaboration is hard. It’s hard between people who have similar goals and priorities, but it’s extremely hard between teams with competing priorities. Naturally, people focus on the work they are assigned to; the work they are accountable for and measured against. If collaborating with someone on a different team slows them down (which it will) or takes a little more effort (which it does), then most people will opt not to collaborate at all and simply focus on their own project which they have more control over. But(!) this is a narrow-minded way of working because it’s actually the sum of all the individual projects that create the end-user experience.
This is exactly the problem I was trying to solve for.
How might I inspire collaboration in a way that offers more benefit than the cost of the time it takes?
I have employed multiple methods to foster collaboration, some of which worked better than others. Here is a run down of some of those methods and a ranking of how well they worked.
Ranking the methods
Each method gets ranked for collaboration and for its overall success, or fruitfulness. All points are purely subjective.
Collaborative = On a scale from1–10, 1 meaning no collaboration at all, how much productive collaboration took place? And furthermore, is the collaboration sustainable?
Fruitful = On a scale from 1–10, 1 meaning not at all fruitful, did the method move the platform towards consistency? Did it address or solve existing problems?
1. The “Jam”
I ran a jam to kickstart a redesign of our UI and bring attention to the fact that this work had to be done, and it had to be done together. Unlike a traditional design system that focuses on the atomic parts of a UI, for Cloud, we were focused on experiences. How does one provision an offering, manager users, or edit tables? No single person or team could design all the artifacts for everyone else to use. It would be impossible to account for the nuances within the different product areas. What we needed was the expertise from different designers to be represented when aligning on solutions.
The design jam brought 60 designers together for 8 hours. We thought that by clearing our calendars and focusing on only this for a short period of time we would get the most bang for our buck.
The results:
Collaboration: 5/10
Fruitfulness: 8/10
Pros. We laid the groundwork for 19 distinct patterns. It gave us tons of material to work with moving forward, and sparked awareness across product teams. So the fruitfulness was high! We were no longer at ground zero and could subsequently move forward from that point very quickly. Overall, it was a good “kick-off” method.
Cons. This method lost some collaboration points because teams were a bit disgruntled to have to clear their calendar for the event (this was primarily due to a scheduling faux pax and not giving enough notice ahead of time). Additionally, a Jam is not a sustainable, everyday method.
2. Office hours
How could we continue to gauge the needs for specific patterns and tap into the expertise from designers on different teams? How about “office hours”?! Office hours was probably an inappropriately named, but the idea was a reoccurring meeting to have personal face-time with designers on different teams to hear what they were working, catalog it for potential future patterns, and also receive feedback on the patterns my centralized team was working on.
The results:
Collaboration: 2/10
Fruitfulness: 2/10
Pros. It was great to have a personal touchpoint with teams and give space to the solutions they are working on that might not otherwise come up. Additionally, having a dedicated point of contact for each team began to create a sense of shared responsibility.
Cons. Oftentimes people would show up to the office hours without anything to share. But more than that we were unable to do anything productive during that time without being able to incorporate the feedback of others. As an intermediary between teams, I could help teams align on existing patterns, but I could only get us so far in terms of creating new ones.
3. Pattern spotlight
Why go to teams when they could come to me? Maybe we needed a better way for teams to connect and give feedback on patterns I was working on, and maybe we needed an eye-catching, obnoxious, visual reminder to connect and collaborate. The “Pattern Spotlight” was just that. I posted up a banner, some foam boards, and some old school yellow boarder ribbon right in the middle of the floor where everyone would have to walk past it. People could take a peek at the board and leave comments asynchronously. They could also attend the meetings scheduled at the same hour every week. Having people huddled around the board had the added benefit of drawing even more attention to itself.
The results:
Collaboration: 6/10
Fruitfulness: 3/10
Pros. People did leave comments, and people did attend the meetings, and a diverse group of people participated.
Cons. The board did not lend itself well to collaboration with people that were not located in the Austin office. Facilitating meetings between remote folks and people that posted on the board was awkward and would have required more of my time to organize and coordinate than I was capable of doing at the time. Additionally the notes and comments left asynchronously were not as impactful without further discussion, and those that left notes were not always those that were in the weekly meeting.
*Note: now that we are no longer in the office, the board is completely inoperative.
4. Reviews
Another way my team and I tried to give more personalized attention to teams and provide consistency control was through reviews.
These were scheduled times when we would review all of a teams’ UI and give them feedback on their implementation of the patterns. We would also learn about gaps that the existing patterns weren’t addressing.
The results:
Collaboration: 1/10
Fruitfulness: 7/10
Pros. We were able to tighten up consistency across the platform, provide teams with specific, timely feedback, and see exactly where patterns worked well and where they started to break.
Cons. It was very one-sided. Hardly any collaboration actually took place since it was a “review” and not focused on creating something new in most cases.
5. Design Guild
The design guild is a group of representatives from each larger product area that get together every other week to share what they, or people on their team, are working on and get feedback from the group. It’s also a chance to give feedback on patterns and make connections when similar UX problems arise.
The results:
Collaboration: 8/10
Fruitfulness: 7/10
Pros. More than anything connections are made across teams that spark further conversations and designs can be iterated on between meetings.
Cons. Firstly, we only meet 1 hour at a time, and we always struggle to not run over. Secondly, it can be hard for the team representatives to really know all the usecases on their product area, especially since it can become very technical. While the smaller size is essential, it’s still not fully representative.
Still, the Guild is a work in progress and probably the most successful of my collaboration experiments so far.
None of these collaboration methods achieved everything I needed them to (which again, was 1. consistency across the products, and 2. the creation of new, better pattern for UX problems), but they all served a purpose.
I believe that for anyone looking to foster collaboration your best bet is to employ a mix of collaboration methods that support and complement each other. For example, we will keep the Guild to support those connections between members of different teams, but we will also keep the reviews to provide a more personal touchpoint and consistency control.
Have you experimented with other collaboration methods? Please reach out and share your experiences!
Kaley is a designer at IBM based in Austin, TX. The above article is personal and does not necessarily represent IBM’s positions, strategies or opinions.
