Design in the open

As the Juju design team grew it was important to review our working process and to see if we could improve it to create a more agile working environment. The majority of employees at Canonical work distributed around the globe, for instance the Juju UI engineering team has employees from Tasmania to San Francisco. We also work on a product which is extremely technical and feedback is crucial to our velocity.

We identified the following aspects of our process which we wanted to improve:

• We used different digital locations for storing their design outcomes and assets (Google Drive, Google Sites and Dropbox).
• The entire company used Google Drive so it was ideal for access, but its lacklustre performance, complex sharing options and poor image viewer meant it wasn’t good for designs.
• We used Dropbox to store iterations and final designs but it was hard to maintain developer access for sharing and reference.
• Conversations and feedback on designs in the design team and with developers happened in email or over IRC, which often didn’t include all interested parties.
• We would often get feedback from teams after sign-off, which would cause delays.
• Decisions weren’t documented so it was difficult to remember why a change had been made.

Finding the right tool

I’ve always been interested in the concept of designing in the open. Benefits of the practice include being more transparent, faster and more efficient. They also give the design team more presence and visibility across the organisation. Kasia (Juju’s project manager) and I went back and forth on which products to use and eventually settled on GitHub (GH).

The Juju design team works in two week iterations and at the beginning of a new iteration we decided to set up a GH repo and trial the new process. We outlined the following rules to help us start:

• Issues should be created for each project.
• All designs/ideas/wireframes should be added inline to the issues.
• All conversations should be held within GH, no more email or IRC conversations, and notes from any meetings should be added to relevant issues to create a paper trail.

Reaction

As the iteration went on, feedback started rolling in from the engineering team without us requesting it. A few developers mentioned how cool it was to see how the design process unfolded. We also saw a lot of improvement in the Juju design team: it allowed us to collaborate more easily and it was much easier to keep track of what was happening.

At the end of the trial iteration, during our clinic day, we closed completed issues and uploaded the final assets to the “code” section of the repo, creating a single place for our files.

After the first successful iteration we decided to carry this on as a permanent part of our process. The full range of benefits of moving to GH are:

• Most employees of Canonical have a GH account and can see our work and provide feedback without needing to adopt a new tool.
• Project management and key stakeholders are able to see what we’re doing, how we collaborate, why a decision has been made and the history of a project.
• Provides us with a single source for all conversations which can happen around the latest iteration of a project.
• One place where anyone can view and download the latest designs.
• A single place for people to request work.

Conclusion

As a result of this change our designs are more accessible which allows developers and stakeholders to comment and collaborate with the design team aiding in our agile process. Below is an example thread where you can see how GH is used in the process. I shows how we designed the new contextual service block actions.