How we learnt to give better design feedback at Atlassian

MC Dean
Designing Atlassian
5 min readFeb 25, 2015
Ross & Becc at the Design Wall — Atlassian

Sparring is not that common in many software companies, and isn’t born out of that industry either which is maybe why. The idea comes from the formal “Art Critique” (or “Crit”) which artists and art students are fortunate enough to experience. Simply put, an art critique is a discussion strategy used to analyze, describe, and interpret works of art.

These critiques help artists hone their persuasive oral and writing, information-gathering, and justification skills. Basically, you need to have method and rationale to back your work, and be able to explain it. One does not simply paint the Mona Lisa. Many hours are spent studying colour and light, painting the scene from different angles, studying similar work,…and doing many many sketches.

The power of sparring: “pain is temporary — suck is forever”

The art critique is very much alive in the art world, and is used by companies like Pixar to produce great animated movies and we read about their creative process at length in Creativity inc. This format has also been used a lot in creative agencies for years, along the lines of a ‘pitch-and-critique’ model, to refine ideas and keep them close to the client brief. There’s also a lot of talks like this one about how their artists work:

We searched hard for examples of the critique in software and heard a lot about how Facebook, Google and other companies do great design, but not a whole lot about critique (or sparring). At Atlassian, sparring is a really important part of our design process. It’s where we can stress test our work, ensure we have strong rationale for our decisions, that we’ve done the right thing according to product vision and customer needs, and explored all the edges.

Why we spar

  • An opportunity to get a reality check, reveal any blind spots in our thinking, and/or to find out how the work we’ve done can be improved
  • Allows us to bring in work at many different stages from sketches all the way through to finished code
  • Bring a whole bunch of extra information that helps us support the decisions we made, such as metrics, user research, competitive analysis and more
  • To set context
  • To benefit from an outside opinion who can bring fresh eyes to the problem and our proposed solution
  • A chance to practice articulating the problem and communicating effectively
  • To grow as designers

The end result is that by pushing hard to get it as right as we can with the constraints that we have, users get a better experience and designers gain greater design maturity

It’s not easy to spar, though

And this is true for a number of reasons that are different for different teams. For us the main problems were:

  • As a company we’re still learning about how to give feedback on design in a meaningful, constructive way
  • Sparring remotely at the design wall is too difficult (bad communication, bad visual, bad everything)
  • We waste a lot of time on small issues & details (i.e. font size, warmth,…)
  • We don’t spend enough time on the gnarly things that need to be addressed
  • Spinning wheels: we don’t move forward with conviction
  • The feedback loop is too long and confusing: we timebox the spar, some of the feedback is received and not completed until a few spars later
  • A lot of the feedback could be absorbed and quickly reacted to by the feature team if they had it in advance

Additionally, we were excited that our PMs, Devs, QA’s and many other individuals from different disciplines wanted to come along. After all, they had worked with the designers on the problems and the solutions and wanted to also hear the feedback so they could absorb it as a team and react together.

Traditionally, sparring is only for designers. The reason for this is that other designers are experts in this discipline so the feedback is more informed from a design perspective. While that makes sense, we don’t build products like that and I’ve never seen an ivory tower at Atlassian. In light of this we decided to bring in the rest of the team, but still ensure the designerly feedback was of the highest quality.

The old format

  • All the work was exclusively on the design wall
  • …Or it was also available online and we struggled to keep both in sync
  • We met for one hour and tried to go through everyone’s work
  • We had a pre-sparring meeting (30mins) — to create an agenda
  • Feedback was posted on the wall and rarely collated
  • Feedback varied in quality, focus and quantity

We needed a new format

It needed to address all the problems we had (or at least the biggest ones), be super easy to be included when you’re remote, and squeeze out everything we could in that 1hr a week. We had previously extended sparring to 2hrs, believing that it was the amount of time that was too short, but instead we just had 2 hrs of the same problems. It was time to act, so we did: we decided on a new format after a design team workshop and rolled with it. It required some fine-tuning initially but we got there in the end.

Atlassian sparring format
  1. Work which we are planning to spar is logged to the agenda complete with details
  2. Items to be sparred are ready COB Thursday
  3. Sparring participants (designers, PM’s & devs) have Friday (US time) and Monday (AU time) to comment and digest the work (on invitation only to keep it small and efficient)
  4. The designer then has time to collate feedback and make any quick additions or adjustments
  5. Sparring time together is spent working through the open questions & gnarly controversial things that came up
  6. Decisions, questions for other teams and further feedback can then be collected

What we gained

  • Faster feedback loops
  • Better communication between teams
  • Improved awareness of the work cross-product
  • More time to receive meaningful feedback and digest it
  • More time spent as a team on the things that matter most and move us forwards
  • Remote sparring is as effective as being in the room

Integrating the art of the critique into a product development process isn’t easy. It means a lot of changes for the whole team in how we give and receive feedback and how we challenge each other more constructively. In my next post I’ll talk a bit more about how we leant to give constructive feedback on design during these sparring sessions. They’re such an integral part of our process, we’re constantly looking to refine them and get more from them.

--

--

MC Dean
Designing Atlassian

Head of Product @The Mintable | Designer | Maker | Meditator