Atlassian creates software that helps teams unlock their potential. Millions across the world use their flagship product, JIRA, to plan, track, and release killer software.
The company’s principles and values drive everything, including design, and that’s by design, according to Head of Design Jurgen Spangl. We sat down with Jurgen and Senior Designer James Bryant at Atlassian’s Sydney office to discuss their use of InVision throughout—and beyond—the design process, the evolving needs of Atlassian’s users, and why, “Open company, no bullsh*t” is a phrase all 1,700+ team members know.
Tell us about what your design team looks like.
Jurgen: We have designers embedded into each of the product teams. We’ve also reverse embedded developers into the design team, to build a better shared understanding between designers and developers.
James: The developers embedded in the design team focus on the front-end platform and prototyping. Our front end is where our customers interface with our services, so making sure that the developers are a part of the design thinking behind their work means that they are well equipped to help make decisions on the nuances and compromises involved in shipping great user experiences.
“Designers rely on InVision to quickly get something usable in front of customers.”
Likewise for our prototypers, they’re at the forefront of bringing our designs to life and making sure they work. The prototyper’s input towards solving a problem is invaluable because they’re involved in understanding the problem and testing the proposed outcome, not just building the solution.
I’m proud to say that our developers on the design team advocate just as much for empathy, accessibility, and delight as our designers do. Being part of the design team workshops and events certainly helps to foster and grow that awareness.
Jurgen: We’re a pretty agile company, overall. We don’t follow a particular process, and we all our teams work differently. The majority of our design team is embedded in product, but we also have a centralized design team called the Design Studio, which is tasked with driving the Atlassian Design Guidelines. These guidelines set a standard across all our products.
The Design Studio sets a direction, but also serves all the other product teams with assets, guidelines, and more. The Studio also follows an open-source model. It relies on strong and consistent contributions from product, which is how we get much better adoption of the guidelines company-wide.
How do you support autonomy among designers while also balancing the guidelines created by the Design Studio?
Jurgen: It’s a constant balance. Our intention is to have as autonomous teams as possible. As we get larger, we must deliberately invest in sharing information. Growing rapidly has helped us learn so much—it showed us what design means at different scales, and what it takes to enable and empower designers as much as possible. In general, though, we try to avoid procedural gates and overhead.
James: Specific teams own the outcomes of what they’re doing, and things get escalated within the company as needed rather than by default or a prescriptive process. What’s required for that is extremely open communication—making sure anyone who has an interest has full access. “Open company, no bullsh*t” is one of our values and we live it every day.
“InVision’s integrations enable a much faster feedback loop for our designers.”
How does this structure benefit the design process?
James: For me, the biggest thing is the speed of the feedback loop. The faster you get to development, the more actionable feedback you get. There are countless tools to get to a solution, whether it’s an InVision prototype or just a pencil and paper, but at the end of the day it comes down to how quickly you can make that feedback loop move.
Jurgen: We encourage all the designers here to contribute to the Atlassian Design Guidelines. They are never done. Designers should use design guidelines as building blocks that help them focus on the larger questions.
On the other hand, sometimes you need more specialized building blocks. If they could be valuable for someone else, they get added to the guidelines.
“Use design guidelines as building blocks to help you focus on larger questions.”
James: There are definitely times when a round peg won’t fit into a square hole. Our monthly hack days are great for that because they let all the designers team up to solve a problem, and you learn from other teams’ approach.
Using the guidelines as a tool is incredibly helpful for non-designers too. It’s not just a design rubber stamp—the Studio accepts contributions on a technical level too.
What tools do you use, both within your own suite of tools and beyond it?
James: In term of digital tools, we give our designers plenty of freedom to choose the right tool to tackle the problem they are trying to solve.
Our UI kit for the Atlassian Design Guidelines is distributed solely via Sketch, since almost all visual designers have shifted in preference away from other tools over the last few years.
There’s a variety of prototyping tools being used internally, but when it comes to creating user journeys, InVision organically became the tool that most designers rely on when to get something usable in front of customers fast.
InVision’s integrations enable a much faster feedback loop for our designers. The design team recently adopted the UserTesting integration to perform early signal testing on our prototypes. Pairing the ability to quickly build prototypes with InVision and then recruit and test with UserTesting has greatly improved our ability to make design decisions quickly and with more confidence.
A simpler integration that’s been invaluable is the live embed feature. Having the ability to embed InVision screens and prototypes into our Confluence pages opens up collaboration with the wider team of engineers and product managers.
“InVision + UserTesting allows us to make more confident design decisions.”
For more sophisticated micro interactions and systems that require logic, we leverage code and other specific prototyping tools. We have a number of designers with front-end skills and dedicated prototypers to build out interactions in code.
Just like architects or automotive designers, we need to understand the systems and materials that make up the end user experience. Knowing how to code not only means that you understand the limitations of the medium, but also where to push the boundaries. Designers who understand code are the ones who are usually pushing and evolving our interactions.
Communicating designs with code removes room for interpretation by developers. The less time they spend having to understand the logic behind the design, the more time they can spend crafting a delightful experience for our customers.
What I also find is that when you’re designing something that has considerable logic behind it, the only way to truly understand if your design solves the problem is to validate it with code. Even with all these amazing design tools available today, the different states that are possible in a system can easily increase exponentially as you build on it. Sooner or later, designing logic always leads to code.
All of these outcomes are meaningless if you can’t communicate the learnings with the rest of the team, so we openly share all of our designs, prototypes, and test results on Confluence where anyone on the team can access and discuss. We have a lot of people working remote so the asynchronous feedback that this encourages is vital.
You make tools to improve team collaboration. How do you make collaboration a priority at Atlassian?
James: Almost every space in our office has a wall that you can draw on, much like how every object that people work on in our tools can be commented on. By doing this we give everyone a voice and we encourage them to use it.
Having this kind of collaboration in the open not only benefits those in the conversation, but also anyone else who’s interested and wants to contribute.
What role does design have in the business strategy at Atlassian?
Jurgen: I report directly to one of the co-founders—that’s by design. We put a lot of value in the user’s experience and the design of it. I’ve worked over time and have seen the company go through different phases of design understanding.
At first it was a lot of talk about the visuals. Then the design guidelines started stabilizing and that elevated the conversation to the next level: user journeys. Once we got a better hand on personas and scenarios, the conversation became one about design as strategy—about what it means strategically when you bring user and business objectives together.
Now, our HR team uses design thinking principles to shape our interview process, for example.
How have your users changed over time?
Jurgen: Atlassian has always been very receptive to its customers. Our company is based on that dialogue, which lets us deliver toward their need. Over time, we’ve developed a closer relationship with the actual end user of our products.
“The only way to know if your design solves the problem: validate it with code.”
In the past it was admins bringing on the tools, but now it’s the actual doers using the products directly.
James: When you meet and engage with customers, you meet the team around them as well, and build an understanding of the other parts of the team that you should also be thinking about. Taking the time to do that—talking with teams and not just individuals—has brought us a lot closer to our user’s needs.
How do you stay true to your values while also incorporating the evolving trends in the design space?
Jurgen: We constantly monitor what’s happening and are always engaging with the design community. That said, we are an extremely values-driven company. We hold each other in check.
You feel our company values; they aren’t just letters on the wall. They are the driving force behind everything we do, and those things are slower moving. In general, we want to set something that is true to us and to our customer’s needs. That means being thoughtful and reassessing as we move forward, not just hunting for the next big thing.