This post is part of a blog series on how we approach design at Atlassian. Find the other posts in this series under the Design tag.

 

Redesigning an entire application is a formidable undertaking with many risks and possibilities for failure. Brian Nguyen, one of our developers, already covered the challenges of Bitbucket’s redesign from a technical standpoint. Now, I’d like to share some of the challenges from the design angle, along with how we eventually overcame them.

Fix the header, they said

Bitbucket Redesigned Header

Initially, we were focusing on redesigning the header before we tackled the rest of the site. The previous header was a disaster of information hierarchy with arbitrarily ordered tabs, links and icons competing for space, and multiple levels of unnecessary navigation. The usability problems seemed obvious enough, but we also wanted to address the header’s aesthetic issues along the way.

Coming on to the Bitbucket team as a new designer with a heavy visual design background, I thought I could make quick work of these little UX bugs. They didn’t worry me, because it seemed like absolutely anything would be better than the header we had. I was given the task of designing whatever I felt was best for Bitbucket and, maybe too excited by the opportunity to re-brand Bitbucket with a more friendly look, I got to work on a grand new vision.

Three months later: Solving the wrong problem

Bitbucket Redesign: Round 1

After weeks of mostly visual iterations, we ended up with a drastically different look and feel with only some of the UX problems resolved. I hesitate to show this work, but it’s interesting to see the contrast between our current design and what might-have-almost been. This design showcased a more colorful Bitbucket with an emphasis on personalization and depth all over the place.

You see, as a relatively recent Atlassian acquisition, Bitbucket had been treated as its own entity within the organization. No one on the Bitbucket team felt the need to align visually with JIRA, Confluence or even Stash, Atlassian’s behind the firewall Git hosting. So long as Bitbucket’s design met with the needs of our users, we could do what we wanted. Getting buy-in from the rest of the company was the last step in our process.

Then, five days before committing this design to code, one meeting changed everything.

A 180 degree change in direction

Unbeknownst to the Bitbucket team in San Francisco, a new design initiative had started across the ocean in Sydney. The aim of this project was to unite Atlassian’s various products under a unified design. Though this effort was still in its early stages, Bitbucket was expected to comply as well. In other words, we would have to throw away all of our visual work so far and go back to the drawing board.

The next few weeks were very difficult. It’s always hard to keep a positive attitude after throwing out your work. It’s also hard to go from having free reign over a project to working along stronger guidelines. I tried to stay focused on this as a new opportunity to work closely with the other designers at Atlassian. We hadn’t functioned as a unified team previously, but all of that was about to change.

A week later, I flew to Sydney to meet with the rest of the design team in the hope that we might learn from our mistakes and unite on a direction.

Atlassian’s united design

Atlassian’s new design direction was barely off the ground when I arrived, but everyone was buzzing with excitement over the concept. My peers had already decided on a more minimalistic Bauhaus-inspired approach that was completely foreign to me. My toolkit of varied color pallets, drop-shadows, subtle highlights and depth were stripped away. I thought that the choice to go completely flat was a big mistake, but the direction had already been set.

However, when I started to actually apply the concepts to Bitbucket’s design, I began to see the light. As with most art forms, the restriction of the design guidelines actually fostered more creativity. The content came forward instead of the UI and the value of sharing patterns was an obvious win.

I was convinced of the new approach, but I still had the task of convincing the rest of the Bitbucket team. The redesign deadline had already slipped, so everyone was worried that this new approach would slow us down even more. The fear was that we would need to check every single UI decision against the rest of Atlassian before we implemented it.

A winning formula

Bitbucket Redesign: Prototype

Luckily, the team also eventually saw the benefits of using a shared design language. Our debates about pixels and color transformed to conversations about user experience.

We gained even further proof of success when we tested a quick HTML prototype to see whether users could effectively use the site header. Through short, one-hour sessions, we learned that:

  • Everything was clear and accessible with no distractions.
  • People liked the information shown in the header and don’t miss the things put elsewhere.
  • Everyone liked the new visual direction!

Any reservations about the new design were gone after the incredibly positive feedback. Once we had designed our key screens, the 70 or so remaining pages were cranked out quickly. As exceptions came up, we resolved them by falling back on the core principles found in the guidelines.

I eventually did focus strongly on Bitbucket’s visual design again, but it only came after the UX concerns were sorted out. It also came with the satisfaction of knowing any design work I did would push the whole of Atlassian’s products forward, and not just Bitbucket.

A few key outcomes

Bitbucket Redesign: Final

No matter how we got here, Bitbucket is closer than ever to the rest of Atlassian. With a solid design foundation, we can build better features, faster.

I could write a novel about the various challenges and growth in designing for Bitbucket, but I hope that everyone can at least take away the following:

  • Account for all stakeholders at the beginning of a project.
  • It is always easier to communicate information in person. If you work remotely, it comes at a cost that everyone should be aware of.
  • Restrictions are great! Working in a smaller problem space allows more to get done quicker.

Thanks for the continued love! Expect great things from Atlassian in 2013.

Bitbucket Redesign: Tweets