This is a second in a two part series about the Jira 6 re-design with Ross Chaldecott. In our first part we talked about Ross’ design approach. We will continue with Ross about the implementation of the Atlassian Design Guidelines inside of Jira. First, let’s take a closer look at the beginnings of ADG with Ross in Sydney before jumping into how ADG shaped the release of Jira 6.
Jira 6: Implementing the ADG
Q: What part of Jira was the most difficult to update to use ADG? Why?
A: Jira is huge (3.8 million lines of code to be exact). You don’t just roll out a new coat of paint in a few hours. We had a dedicated team focused on implementing ADG for the entire 6.0 release. It was a big job and a big challenge. We didn’t want to just generically roll out ADG. This was a rare excuse for us to tackle some of the core parts of Jira. We really thought hard about everything we were doing to make sure we hadn’t missed central experiences we might have skipped in a smaller release.
One of the trickier parts to update was the setup process. It wasn’t originally slated for the ADG rollout. We were well aware of how much we needed to improve there. We just didn’t have enough bandwidth in the team to handle it. We wanted to ensure the entire experience was awesome. Since setup is the first experience for many users, we need to have that part bulletproof.Luckily we finally did manage to convince the larger team of its importance and got some additional people to help us get it done.
Q: What was the most important part in applying the ADG to Jira?
A: There are a few things that ended up being critical in making the ADG roll out successful, and a few things we learned along the way. When we started we had no idea how big it was going to be. We gave the project our best estimates, but we didn’t realize how extensive this project was. We made some mistakes because of that. In retrospect I imagine that had we spent the time upfront to understand the scope of the project and broken it down accordingly, we would have had a much smoother ride. Either that or we would have chickened out. Hmm – maybe it’s best that we didn’t scope it after all.
Luckily we did have the skills of a dedicated team of incredibly smart and talented front-end engineers working on it. All day, every day. Without this team I am certain that the ADG work would never have made it out the door. For a project of this size, it was important to have a full time team focused in making ADG successful in the product.
I also learned that it’s important to stick to your guns where it matters. Not all battles are worth fighting for. Not every screen was going to get a full overhaul. Where it was important to the product, I pushed that it was crucial that we got it right and sweated those extra details.
Q: How did you test usability during the development phase?
A: We’re looking more to data these days than we ever have before. Jira OnDemand allows us to track anonymous usage of just about anything our users do in the system which really means we have a much better idea than ever before of what people are doing and how they’re doing it.
We’ve recently spun up a growth hacking team to really capitalize on this. In just a few hours we can deploy a new experiment to OnDemand and have results on whether the change will improve the lives of our users. That’s something we’ve never been able to do before. Before now we had to do everything based on talking to customers directly. We still engage with customers one on one but now we have actual hard data to help us understand whether a change will be good or bad. The new project templates dialog in 6.0 is a direct result of the growth hacking team running an experiment.
We absolutley still do masses of traditional usability testing. We engage customers in person and over the phone at all phases of the development cycle. These give us a personal insight into our users and understanding of what they want our products to do that we just can’t get from cold data. Combining the two approaches is probably one of the biggest changes we’ve made in the way we work recently.
Q: How do you prioritize aesthetics versus usability? What do you do when something you think is ugly turns out to be a tested winner?
A: Design is about way more than pretty pictures. Sure we really care about the aesthetics and we really do sweat the details, but there is far more depth to it than that. There’s the old design philosophy of ‘form follows function’ and it’s something we live and breathe here. If design is not firmly grounded in real user goals and requirements it almost always fails. Every time we have cheated ourselves and focused on the visual components of a feature first we have invariably failed. The least design often turns out to be the best design.
ADG has been instrumental in helping us here. The biggest difference between ADG and most of the style guides I’ve seen in the past is that it’s a visual language. It’s way more than color and palette. We methodically broke things down to their simplest states and built up a system of solving problems. Each piece builds on the next so we can easily understand how to build something new into the language by applying the same way of thinking. When teams use the ADG is that they don’t have to think about form anymore. Instead they focus on problem solving and function and let the ADG take care of how it looks for them.
Q: What advice would you give to designers and developers looking to update an existing application?
A: New products are easy. You don’t have people depending on your product so making change is easy. With existing applications you need to play a bit of a longer term game. We’re very aware of appearing schizophrenic in our design. If we make a change it has to be the right change for the right reasons. So we’re not going to change it back. The only way to do this is to make sure you really understand your long term bets and break things down into smaller achievable chunks that add up to the longer vision.
It doesn’t sound very Agile at first I know. To me it’s important that, even Agile teams, still have a strong understanding of where they’re heading. Sure you don’t design it out in minute detail, but you still need to know where you’re going and how you’re going to get there.
Is 6.0 the end then? Of course not. Everything we do is a stepping stone to a longer vision. Every release takes us that little bit closer to the best product Jira can be.
Want to stay up to date on key tips and tricks with Jira? Sign up for the Jira Insiders Email!