Many software teams struggle to effectively integrate design into their agile process. Designers who don't work closely with the rest of their team tend to generate extra work for everyone (including themselves), and can create harmful silos of knowledge within the product team.
At Atlassian we work in a collaborative manner to incorporate the entire agile team in the design process. By ensuring that everyone is engaged in the design process we gain multiple perspectives on a problem and don’t rely on documentation to share ideas. This presentation explores how to:
- Involve the entire team in the design process
- Integrate design into the agile process
- Gain customer insights for faster testing and ideation
Q & A
These Q&As range from what design tools Atlassian uses to how Atlassian handles customer feedback.
Q1: Are designers and developers always different people? With HTML5 and modern UI techniques, is it hard for designers to not have basic coding skills?
A1: The line between designers and developers is becoming blurry. We have designers at Atlassian that come from an engineering background and others that couldn’t write a line of code. We have strong visual designers, information architects, and facilitators. Everyone has different strengths and it’s important to recognize and utilize these in your team.
Q2: Are people outside the product team taking part in design workshops for example marketing?
A2: Our workshops include people from different disciplines, but everyone is there for a reason. Usually, there will be representatives from PM, engineering, and design, but we may pull in someone from support or marketing if they can add another perspective.
Workshops can run for several days, which is a long time to commit to. I like to share the agenda in advance so people know where they can add value and where they can step out for a few hours. You should have a core group attend for the whole time, though.
Q3: How did you get your people working on sketching, participating in drawing, and coming up with ideas? I have a feeling that POs and devs are reluctant to get into that work, out of fear or other reasons.
A3: It’s already intimidating having to share ideas with a group, but drawing in public can be even scarier! That’s why I like to split the large group into pairs for this stage of the workshop. It removes the pressure of a blank sheet of paper staring back at you. It also lets people bounce ideas off of each other and keeps momentum going.
I’ve found that after participating in one of these sessions, everyone gets comfortable with the process and really enjoys participating. There’s always a buzz in the room with lots of great conversations going on.
It’s also important to let everyone know you’re not looking for masterpieces. All you’re after is a visualization of their idea—this could be a sketch of an interface, a diagram, or just a bulleted list—anything that helps the rest of the group reach a common understanding. If it’s captured on paper you can also keep it for reference after the workshop has finished.
Q4: How do you get new members in the design team up-to-date?
A4: We have an on-boarding process for all new members of the design team. This starts with an introduction to design at Atlassian, our process, and how we work with the rest of the product team. We dive into the design principles we’ve developed and show examples of how these are put into practice. There are boot camp classes to learn more about our design resources: using personas, the Atlassian Design Guidelines, and the Playbook.
We also pair up new designers with a buddy for their first few weeks to show them the ropes and ease them into more responsibility.
Another way to get a new designer up to speed is by bringing them into a workshop during their first week. It’s a great way for them to meet the product team and experience first hand how we work together. There’s a lot to learn during the first few months, but a workshop is a great place to dive in and tackle a bite-sized problem.
Q5: What methods of customer research do you find most useful? Field research, observation, usability, others?
A5: I think all types of customer research are useful, but different types of research come into play at different stages of a project.
For example, at the beginning of a project you want to get a full understanding of the problem and the context people are working in. Contextual inquiries are really useful for this—you visit a team at their place of work and talk about their process, how the problem is affecting them, and what they need to be more effective. It’s great to see first hand how they try to accomplish tasks and the frustrations they encounter.
User testing and customer interviews are great for when you’ve developed your ideas a bit further. You can gain valuable insights by watching people go through a flow using a simple prototype or just by having a conversation about a proposed solution.
A/B testing, on the other hand, is an awesome way to gauge how effective your solution is.
Q6: What tools do designers at Atlassian use?
A6: Designers at Atlassian use the right tool for the job. Sometimes that’s old-fashioned pen and paper, other times it’s HTML & CSS.
For creating high fidelity designs, most of the team uses Sketch, but we also use the Adobe suite. All of the UI elements from the Atlassian pattern library have been created as vector objects so it’s pretty simple to assemble a basic layout to build upon. For simple prototyping, we use InVision or Marvel. For more complex interactions we’ll use Framer Studio, Origami, Axure, or hand-written code.
We also go through a ton of post-it notes and whiteboard markers. :)
Q7: What are some of the challenges you face working within an agile framework?
A7: Learning to let go of perfection and instead produce fast, iterative work is the biggest challenge. As a designer, you always want to create high-quality work, but you need to be okay with shipping something that’s 90% there and then improving it.
Q8: You mentioned several ways to reduce documentation. What form of documentation do you maintain? Have you eliminated all documentation?
A8: We use Confluence to share work in progress and gather feedback from the wider team. A typical page will include some context about the problem we’re trying to solve and the value that the proposed solution offers. There will be photos of sketches, high fidelity mockups, or links to prototypes embedded in the page to illustrate a solution. People will add comments and questions, and the designer will post updated designs as the project progresses. It’s not really ‘maintaining documentation’ though, it’s an evolving page that collects design assets and feedback.
Q9: How do you approach distributed design when a team is not co-located?
A9: Atlassian is a global company so working with distributed teams is something we encounter every day. On Jira, we have teams in Sydney, Gdansk, and Saigon and we are always looking for ways to bridge the gap. Technology helps a lot—we use Hipchat for video calls and messaging, Confluence to post, share, and comment on work, and Jira to organize all of the work. It’s not perfect though, and nothing can replace face-to-face communication. When possible, we try to get people in the same room for crucial parts of a project. Otherwise, a good rule is to over communicate with remote teammates and do your best to keep them in the loop.
Q10: How do you control and filter ‘noise’ that masquerades as ‘customer feedback?’
A10: We receive a lot of customer feedback, which is a great thing! We have a feedback tool that collects user comments and saves them as issues in a Jira project. I spend the first part of my day reading through the latest issues with a coffee. As I’m going through the comments I make note of any common themes or patterns that are emerging and add labels to group them. I can filter all of the feedback using these labels to find out how many people have raised a similar problem. Then, once a pattern has been established, I can take this problem to the product team with specific use cases that we can address.
