Q&A from design interviews
In 2015, I was lucky to be part of our European hiring tour. We visited four cities in two weeks, had over 500 applications, interviewed over 30 talented designers, and hired five to move to Sydney. And, each week, I usually attend around 4 hours of interviews. In all of these interviews, I get asked a lot of questions about design, Atlassian, and everything in-between. I’ve collected some of the popular questions here, along with the answers I usually give.
What does a typical day for a designer look like at Atlassian?
A designer’s day is often varied. It all depends on the projects, and the next stage of development. Are we envisioning a future product experience, shipping a new feature, or iterating on an existing experience? Different stages of a project require different modes of work.
Typically, a designer’s day will usually start with a team standup with engineering and product management peers. We might spend time looking at usage data, or speaking with customers to better understand how something is being used. They we’ll spend time sketching and designing, either individually or pair designing with a colleague. Feedback on work comes in a few forms:
- Informally with design, product, and engineering colleagues.
- Formally through “design sparring” sessions. (Usually once per week.)
- Formally through sessions with our founders. (Usually once per quarter.)
- Formally with customers in qualitative testing. (Usually fortnightly.)
- Formally with customers at scale. (Through experimentation prior to something shipping.)
The feedback mechanism is driven by the individual designer, whom we expect to use the appropriate methodology to help them progress their design solution.
Being part of a triad means that designers communicate constantly with their teams, usually via HipChat or at weekly meetings. We try to ensure that meetings do not overwhelm productivity and actual time spent submerged in a design problem.
What is the size and makeup of the design team?
The Atlassian design team numbers around 120 people, spread across four office locations, plus a couple of people who work from home. That number includes people in the following disciplines:
- UX Designers
- UI Designers
- Motion Designers
- Writers (Information Experience)
- Front end engineers
We are a true multi-disciplinary team. Product designers can work on a variety of different types of projects at Atlassian, and on any of our core products. While we encourage internal movement of designers, some of our products are complex systems that require deep product knowledge so designers are likely to be embedded with a product for a minimum of one year. Designers may be involved in bigger picture strategy discussions, or at the other end of the spectrum sweating the details of user interfaces and visual design. We recognise that not every designer will be a good fit for every single project. So we try to balance our teams with designers that will complement one another. For example, pairing a more UI-focussed designer with someone who specialises in systems thinking. Whilst all designers must have an implicit appreciation for a broad spectrum of crafts, they do not have to be a master of all the crafts required to be a great product designer.
How is the design team structured?
However, designers do not sit together centrally as in traditional functional organisations. Design teams are embedded within individual products, or product families along with the product management, engineering, and marketing teams. Within a product design team, you usually have a design manager or team lead who looks after a small group of product designers. That team will also have an embedded researcher(s) and writer(s). That entire design team will report up to a Head of Design for a family of products.
What is the biggest thing that makes people successful here?
Connecting with our values. Atlassian is rare in that it strongly believes in its values, and they are lived out in multiple ways each day by every employee. Those values are listed below, with my own interpretations of them underneath.
- Be the change you seek
If you see something that’s broken, do something about it. (Report it, or fix it.)
- Don’t fuck the customer
Whatever you build, make sure you put the needs of the customer first — not cool technology, not cool design.
- Build with heart and balance
Make balanced calls when building product.
- Play, as a team
Building products is a team sport, not an individual one. Build product as a team, and also socialise as a team. The second bit is very important.
- Open company, no bullshit
Being open with all individuals and teams within Atlassian about what we’re doing and why we’re doing it. If we screw things up, we share the lessons openly. This creates trust throughout the organisation.
These are not whiteboard values, or website values. Every day, individuals and teams use these values to guide their work, and do the best things by each other and our customers. Atlassian is also a high get-shit-done (GSD) environment. You get a lot of autonomy here to understand the company mission and then push and drive initiatives forward that will help us get there. So being a self-starter is also a must.
How do we work with product managers and engineers?
In short, very closely. We don’t build products in silos, we collaborate constantly with other disciplines and follow agile principles. We very rarely hand specs from team to team.
We work as triads (or increasingly quads, including our peers in marketing) between design, engineering, and product management.
Every designer will have a peer in the other discipline. It varies between triads exactly how they work, the triad is free to organise the cadence and rituals that suit them. At a minimum the team connects weekly, and usually daily. But they are all equally accountable for what ships into our products. We expect them to work together to ensure they ship the right balance between functionality (features), engineering (performance), and design to our customers.
Product managers and engineers are brought into the design process from the start and stay there right until an experience is shipped. Designers are connected through to implementation to ensure that we sweat the details in the final experience.
How do we decide what to work on?
It’s up to a triad group to set the direction for the product or feature they’re working on. The direction needs to align to the overarching strategy of the product, but triads get a lot of freedom to determine their own destiny so long as they have strong data (both quantitative and qualitative) to back up what they are doing.
We have access to a lot of data at Atlassian. That data helps inform product teams about what to work on. Typical inputs that a triad team will use are:
- Net Promoter Score feedback
We receive over 1,000 pieces of qualitative feedback every day. We group these pieces of feedback into three categories: Reliability, Usability, and Functionality. Within each category teams will drill down further to get trends and themes. More in-depth qualitative feedback is usually sparked from this drill-down.
- Qualitative feedback
Drilling down from NPS feedback teams may run in-depth contextual inquiries or deeper customer interviews to better understand problems. We also run regular user testing in each product group. Insights from this qualitative feedback will help teams focus in on pain points and help them define their roadmaps.
- Quantitative data
We have access to a ton of data as designers: Feature usage. Time on task. A/B testing analysis. Return usage. Daily active users. Conversion. The list goes on. Whatever we need, one of our analysts can usually get it for us.
- Customer support
We have a large customer support team. They are fielding thousands of support requests every day. These support requests are a gold mine of opportunity for triads. The product management team usually takes the lead in liaising with the support team to help identify themes and trends in customer feedback to help us define what to work on.
JAC is our public JIRA instance. Customers are free to log issues with us: feature requests, bugs, or usability issues. Customers can also up-vote issues if they are experiencing the same problem. Our product management teams manage these issues and will regularly speak with customers to clarify the problems they are experiencing.
Dogfooding is the affectionate term used to trial early versions of our own software. We use our own internal versions of our software, where we have access to early release features. We are actively encouraged to provide feedback on features before they ship.
The reality is that as a designer, sometimes you could be working on early phase strategic planning and visualising of a new product feature, or helping to fix an annoying bug or usability issue. There’s a wealth of opportunity to shape your destiny by working closely with your triad partners to truly understand customer pain points.
How does Atlassian approach career progression?
We encourage individuals to move around the company to get perspectives working on different products, as well as encourage their own career growth in either management or craft, depending on which track they choose to take. See below:
We offer both a management and craft track to our design team members. We value both awesome people leaders, as well as awesome craftspeople. Both tracks are of equal value to us as a company. We encourage individuals to use the role guide and career development plans put in place by managers as a guide to help them progress at Atlassian. We want to ensure that talented individuals do not hit a ceiling where they can no longer progress. This can be true in many organisations who insist that to level up, you have to start managing people. You can read more on this here.
We have a number of diverse products in our portfolio, from those focussing on code review (Bitbucket), team communications (HipChat), content (Confluence), and issue tracking and workflow (JIRA). Our products are large enterprise systems, so it can take a while to truly build up the right level of empathy for our diverse customer base needed to produce great designs. So whilst we do encourage individuals to move around, we do expect them to work on an individual product for at least a year.
What is it like living in Sydney?
We interview a lot of folks from outside of Australia who are looking to move to Sydney, so I get asked this one a lot. I swapped the grey London skies for sunny Sydney back in January 2006. I moved for a previous employer, but had experience travelling through Australia as a young backpacker in 2003. Sydney is now very much home, and my daughter was born here.
Sydney has the advantage of being a modern large(ish) city, located very close to about a dozen truly world-class beaches, with a temperate year round climate. As I write this, the sun is shining, there isn’t a cloud in the sky, and it’s 27 degrees (80 Fahrenheit) — and it’s five days before the start of winter! Don’t get me wrong, we get rain, more than London apparently but that usually comes in short bursts of tropical rainstorms. It also gets cold, but that’s mainly due to the fact that houses don’t have central heating and usually have a lot of “gaps” — lots of cold wind drafts.
I live in Bondi beach, which is about 7 kilometres from the city centre. I usually run or push bike to work, which takes around 30 minutes, or I catch public transport (40 minutes). The downsides to Sydney are well documented. House prices are high and the cost of living is comparable to other major cities, quite high. But the benefits greatly outweigh this. I get to live close to a beautiful beach, in a beautiful city, and bring my daughter up in a temperate year-round climate. She loves the beach, and so do I!
We are hiring. Check out our open design roles.
Did you enjoy this post? Want more of the same? Consider following Designing Atlassian.