Multiplayer mode unlocked: Better team collaboration for designers, developers, and researchers
Many games are more fun to play in multiplayer mode than in single player. Can you imagine playing a game of basketball by yourself? Boring.
While designing digital services is not a game, similar principles can apply: in multiplayer mode we’re more effective when people with different roles can work together towards one goal, in real time, in one place. This became clear to me while designing government services.
When I joined the Canadian Digital Service (CDS) back in September 2019, I was onboarded to a team working with the Royal Canadian Mounted Police (RCMP) to build an online cybercrime reporting tool. At the time, the team had recently tested two different prototypes, hoping to learn which of them collected better data.
The blockers
As a designer, I was eager to learn how and why these prototypes were built the way they were. To do that, I’d usually look at design documents that had user flows (a diagram of where a person can click and navigate around a service), wireframes (rough visual representation of screens) and mockups (polished and clickable renderings of screens).
However, I learned that our designs were done on paper then coded immediately, so there was little I could reference to help me understand past design decisions. I went through the documentation that was on hand: written reports, photos of post-it notes, diagrams, and presentations. These were helpful to try and imagine the design, but none of them illustrated how the product should look on actual screens.
Not having design documents or visual representations of the screens meant it was more challenging for designers to have a creative environment to work in. Before going into the next phase of our work, I wanted to change how designers and researchers could collaborate with developers, while using their own voice. To put it another way: I wanted to make sure that, as designers, we were able to use our specialized skills and abilities to push our work forward as a multidisciplinary team.
While I wanted to give each specialization the specific tools it needed to get the job done, one thing that was important to the team was that, in doing this, we weren’t creating a division between design work and developer work, otherwise called “handoff”. Up to this point, we avoided handoff by having everyone, even designers, doing their work directly in code. But this limited our designers ability to test out designs in a more nimble way.
Given these challenges, my main goals were to:
- Create better documentation and a visual reference for developers, researchers, and all team members;
- Unlock designers creative potential by giving them the right tools to do their best work; and,
- Not create a handoff situation.
The game plan
To try and achieve those goals, we piloted the use of a design tool called Figma. We chose Figma because it allows “multiplayer” editing of design files. That means, in theory, designers, researchers, and developers could work together creating wireframes, mockups, and flow maps in one place at the same time. With that, there would be a creative environment for designers to make visualizations of what each screen would actually look like when coded, but no handoff of a design document to developers.
We approached this new idea with both enthusiasm and skepticism. Testing was needed to see if it would meet our goals!
Once we set up our Figma account, we were able to easily view all of our page designs. Having everything laid out visually, we could spot repeating typography, colors, buttons, or text fields, and make sure we were consistent across all page designs for a simpler user experience. Our new design document also enabled us to review the user flow as people went from any point in our app to another. We were able to use the flow to keep track of all the different pages that were needed as we continued building out the app.
Now that we could see every piece of the puzzle, we could identify, iterate, and test issues that came up.
Working iteratively through Figma meant that we could leave a paper trail of our creative process which has been great for documentation purposes and understanding design decisions. We opened up the design document to researchers, developers, and the rest of the team during meetings and presentations. It became a single source of truth as everyone was able to come take a peek, leave a comment, or ask a question.
Having a design document brought quicker changes to the codebase. Steve, a developer on our team said, “The app is being reborn every week!” Until eventually we began to iterate smaller and smaller pieces at a time. We saw a radical improvement in our app because of a new focus on design that all team members could be part of.
Practice makes perfect
As CDS continues to work on new services, this collaborative tool became a larger part of our ways of working together. We were able to consolidate multiple workflows into one place, minimizing the need for file versioning and sharing. While we had to implement documentation best practices specifically adapted to Figma, it made decision tracking more transparent and efficient.
We grew our Figma community of collaborators from 3 designers and researchers on the RCMP team to just under 30 designers, researchers, developers and more across multiple teams, including COVID Alert, Notify, and the COVID-19 benefits finder.
Trying a new play
If you work in a multidisciplinary team, finding the right tool to get different specialized ideas across is ultimately a good way to make work more efficient, as well as more enjoyable. You wouldn’t want to dribble across a basketball court just to score a point against no one. It’s not creative, it’s not productive, and it’s just not as fun.
Finding the right multiplayer tool for your team can be a fun and rewarding experiment. Don’t be afraid of learning a new tool, it might be easier than you expect!