1. @atlassian
#atlascamp

2. Atlassian
Design
Guidelines
Good afternoon.
I'm Jurgen and I head up the design and AUI team at Atlassian.
I'm excited to be here today. It's awesome to have design as part of a
developer conference, and that so many of you showed up. So obviously
you care about design.
How many of you have used the Atlassian Design Guidelines? Hands
up.
Ok, roughly x. I hope after this talk all of you will use them. I'd like to share
what the Atlassian Design Guidelines, ADG in short, are and how you can
make the best use of them.
About 1.5-2 years ago we started our design journey in honest. Let's time
travel. That's how our products looked like 1 years ago.

3. Bitbucket

4. Confluence

5. JIRA
Our products always had great features and were powerful, but their visual appearance was
dated.
They were inconsistent. That's the feedback we got from our users.
Our users had to re-learn things from one app to the other, and even within our apps.
Just one example: 52 different drop downs. This had to change.
Over the last year we redesigned and shipped our 4 major products, or let me re-phrase this:
We launched one and redesigned 3.

6. We rolled them out over the last year. One by one.
Stash was first. Started with the the beta version of ADG and since them is always on the
latest.

7. Then the first big test for ADG. I was pretty nervous the night before Bitbucket went live.

8. Next to new features Bitbucket's UI was completely refreshed and built with the AUI flatpack.
The team expected about 50% positive feedback — we got 90+%. This set the bar high for the
other products.

10. Confluence followed in February with a completely new interface and many awesome new
features, eg the sidebar and blueprints. Our users love it.

11. And JIRA shipped this week.

12. JIRA was massive to bring over to the ADG. There are hundreds of screens. The team did an
amazing job with their attention to detail and staying on top of things.

13. I'm proud to be part of a team who is able to pull this together. I'm proud of being part of a
developer ecosystem who is willing to go on this journey with us.
And that's just the beginning of our design journey. We're in there for the long run.

14. You can trust me on long runs. That's me 4 days ago running a 100k ultra-marathon.

15. And I finished :) Here is the proof.
Comparing this to Atlassian I would say we are somewhere around km 10. We just started.
But we won't stop here. This is just the beginning.
So how did we do this?

16. Firstly, as mentioned before with an awesome team of designers, engineers, product
managers, QA, tech writers, support, marketing, and many more. And you guys were part of
this. We couldn't revamp our products without your efforts to ADG-ify your add-ons.
Secondly, following a Lean user centred design process. Going out talking to our
customers and users. Listening to their needs. Collaborating closely as a team. Involving
users constantly throughout.
And thirdly, we built tools which helped us to deliver a harmonious experience across
Atlassian and also to automate a lot of the hard work. We don't need to reinvent a button
every time. We needed a tool which scales. A tool which lets us focus on the flows and end to
end experience. We will never have enough designers, many of our ecosystem developers
don't have any designers on their teams at all. How can we empower everyone to design
better software? The Atlassian Design Guidelines play a key part in it.
In January we launched the Atlassian Design Guidelines. It's a bunch of tools to help you
make our apps and add-ons beautifully designed. It's a library of controls, patterns and
solutions that you don't have to think about. You don't have to design everything from
scratch. You don't need to figure out what font size to use, what colours.
The ADG is build and driven by strong principles. Let me start wit the 3 core ones what the
ADG is driven by.

17. Our users are in the centre of everything we do. We visit them, check out how they work,
understand them better, so that we can design the best products for them. So that they can
be badass in what they do.
Everyone wants to shine. We help them to. If they shine, we shine.

18. We want
our users
to kick ass
So, We want our users to kick ass

19. Just
enough
is more
- It's so easy to overdo design. Add clutter just for the good looks and sexyness, or to be
trendy.
- We aim to just add enough so that our users can get their work done efficiently, but never
get in their way.
- A simple way to check on this principle: When in doubt leave it out.

20. The next one is about you.

21. We want
our devs
to kick ass
We aim to rationalize all our decisions so that others can quickly build on it. We share openly
our design approach, we follow a lean user centred design process.
The ADG is built 100% with AUI. The ADG is our source of truth as live guidelines, you can see
it as an app itself. It's built following the ADG itself. You get all the styles for free by using
AUI.

22. So let’s look at the guidelines in more detail.
Principles
Approach
Buttons -- talk through format: short what it is, interactive, when to use, when not
- open doc
- open sanbox
Mentions
- build with AUI components

23. read 1 or 2

24. quickly go through them, you can read the other by yourself

32. Let’s use it
How can you best use the ADG. Let me share how we used it for
redesigning the JIRA Importer plug-in.

34. We skinned it with ADG and build in some improvements, eg we moved from the vertical tabs
to the new progress bar to show the users where they are in the process.
Let's briefly look how it looked before.

36. It's a big step in the right direction. Interaction patterns and visuals are algined with the rest
of JIRA.

41. But we still have many flaws in it, such as confusing value mapping of fields, no good exit
point at the end, and more.
We took AtlasCamp as an opportunity to quickly redesign it and show off how we used a Lean
UX process and the ADG for it.

42. Ross and I got together and quickly sketched the flow and screens. We iterated a few times on
the flow and some details. Probably took as an hour or so.

45. Then we mocked it up with the Sandbox and photoshop. Whatever is faster in any given
moment. You could mock it up completly with the sandbox and have a running prototype.
The key is to validate your designs as quickly and cheaply as possible. Get feedback from
users. Sometimes we just use sketches or paper prototyples to run them past users.
You can download the latest AUI flatpack on the ADG site.

46. Once unpacked you see this directory structure and just can start prototyping with the
yourHtml file.

47. That’s how it looks like.

48. So what we want first is a focused task page. we look it up in the ADG. and open up the dev
docs to find out the implementation details.

49. We find the paramaters here and apply them to the code.

50. And the code

53. Let’s add the progress tracker. Again find it in the ADG.

54. We open it up in the Sandbox and adapt to our needs. So we need the inverted one and
change the number of steps and labels.

56. And copy it over to the file.

57. And here itis. Ok. You got he point. I fast forward to the new solution and share the design
rationale why we picked these design solutions.

58. So what did we change and why?
I’ll walk through the new flow and provide rationale for our design decisions.

59. GIVE CLARITY
GIVE CLARITY
GIVE CLARITY
GIVE CLARITY
GRACEFULLY REVEAL DEPTH
- Give clarity: combine steps and show source and target in one screen to make it clearer for
our users what they are importing to where. And also to keep it simple. It’s as simple as 3
steps and you’re done.
- Give clarity: moved the existing import setup out of the way in the header, it’s changing
most things of the screen so that’s why we brought it up, but reduced its importance.
- Give clarity: moved password info to the side; before it was in your face like an error
message. This is actually closer to help content and once you have imported things you know
the spiel, so it should not get in your way.
- Gracefully reveal depth: hide all additional info in advanced, eg date format, email suffix

61. GRACEFULLY REVEAL DEPTH
HUMAN TOUCH
HUMAN TOUCH
GIVE CLARITY
GRACEFULLY REVEAL DEPTH
SPEEDY
GIVE CLARITY
- human touch: well worded messages summarizing what happened and call out what needs
to be set.
- gracefully reveal depth: offer help where needed, map fields in context (combined 2
screens)
- speedy: we load possible mapping via ajax and provide good defaults if possible
- give clarity: show info in context; if no summary field is selected then this button is
disabled and we show a tooltip why.

63. GIVE CLARITY
GIVE CLARITY
SPEEDY
- Give clarity: Show summary of all actions
- Show what users can do as next action
- Speedy: Set the most likely next action as primary
So I hope this gave you a quick overview how you make best use of the ADG.

64. ADG 2 / AUI 6
★
Retina support
★
More patterns: tables, type-ahead, error handling,
notifications, emails, keyboard shortcuts, ...
★
Mobile patterns
★
More guidance on design approach and design 101
★
Versioned documentation
So what’s next?
As mentioned at the beginning of the talk, we’re just at the beginning of our
design journey. There is more to come. We will apply ADG to the rest of our
products. We plan to release new versions of the ADG roughly every 6
weeks. And we are already working on ADG 2/ AUI 6. Just a quick outlook
what we have planned for it.

65. Use it: developer.atlassian.com/design/
You always find the latest version on developer.atlassian.com/design
Head their and start using it. We’d love to hear your feedback, let us know what controls and
patterns you’d like to see.
And of course we’d like your contributions to AUI.
Thanks all.
I think we have time for a few questions.

66. Thank you!