{"id":16271,"date":"2018-02-21T09:55:25","date_gmt":"2018-02-21T17:55:25","guid":{"rendered":"https:\/\/www.uxpin.com\/studio\/?p=16271"},"modified":"2026-05-08T02:51:24","modified_gmt":"2026-05-08T09:51:24","slug":"virtual-summit-recap-atlassian-shares-4-pointers-design-systems","status":"publish","type":"post","link":"https:\/\/www.uxpin.com\/studio\/blog\/virtual-summit-recap-atlassian-shares-4-pointers-design-systems\/","title":{"rendered":"Virtual Summit Recap: Atlassian Shares 4 Pointers on Design Systems"},"content":{"rendered":"

Allard van Helbergen, Senior UX Designer at Atlassian, speaks from Sydney about what he and his team learned from 16 years of design system evolution.  <\/span><\/i><\/p>\n

Why do you build a design system? The popular answer is to maintain consistency across different products and different teams, but a well-made design system also reduces cognitive load and increases the speed of development overall. There is one reason, though, that stands over the others, the ultimate reason. Design systems help users. <\/span><\/p>\n

Atlassian has known the value of design systems for quite some time, but it took years of practice before they realized just how powerful design systems are \u2014 and how to best utilize them. <\/span><\/p>\n

\"Atlassian<\/p>\n

Jira UI 2002<\/em><\/p>\n

\"Atlassian<\/p>\n

Jira UI 2002<\/em><\/p>\n

Through gradually refining and improving their designs over ten years, Atlassian created its first official design system in 2012. Back then, the goal was primarily to ensure consistency across all of Atlassian’s products, and their first “design system” was actually closer to a traditional style guide. <\/span><\/p>\n

\"Jira<\/p>\n

Jira UI 2017<\/em><\/p>\n

For the next 5 years, Atlassian developed and fine-tuned their design system, learning some valuable lessons along the way \u2014 namely that it could be do more than just maintain consistency. By 2017, their latest version placed more emphasis on reducing friction in product interfaces, and to this end they added the complementary Atlaskit, a move that defined the capabilities of design systems. <\/span><\/p>\n

The Atlaskit comes equipped with standard UI components that not only help designers maintain consistency by using the similar parts, but also offer the best ready-made UI options for better performance. The kit’s components are built around actual user preferences, so standardizing them saved time for each product. <\/span><\/p>\n

But, as our speaker explains, “there’s a lot more to it than just delivering UI components.” <\/span><\/p>\n

Over the years, the process of refining the design system taught Atlassian a lot. Senior UX Designer Allard van Helbergen was kind enough to share some of these Learnings during UXPin’s Design Systems Virtual Summit 2018, which presented case studies from companies like Salesforce, IBM, Airbnb, GE, Linkedin, Fjord, Zendesk, and more. <\/span><\/p>\n

Focusing on two specific UI components, inline and modal dialog windows, Allard takes us through the four most important pieces of advice for design systems, and how to apply them. Take a look at the recap of his presentation below. <\/span><\/p>\n

Learning 1: Tension between product and design systems is healthy.<\/span><\/h2>\n

\"Tension<\/p>\n

One of the hardest parts to grasp about design systems is that their components never quite fit perfectly out-of-the-box. The design system and the product work together, but do different things. “At some point your product will be leading [the design]. At another point, your design system will be leading.”<\/span><\/p>\n

Rather than fight this tension, Atlassian learned the smarter solution was to use it to their advantage. There is no “one size fits all” component that would work perfectly with every product, so they needed to add a degree of customization. They found that, by leaving some room for growth in their design system, the components could be slightly modified to suit whatever the product’s needs are. <\/span><\/p>\n

“What happened was,” Allard explains, “the component that was taken from the design system had a shortcoming and didn’t allow the product to do what they needed to do. So products reached out further and made their own decisions.”<\/span><\/p>\n

To illustrate his point, Allard shared a real-life example. Compare the design systems entry for inline and modal dialogs\u2026<\/span><\/p>\n

\"Atlassian<\/a><\/em><\/p>\n

\u2026 to some of the final variations that ended up in the products\u2026<\/span><\/p>\n

\"Atlassian.<\/p>\n

The modifications are minor, not nearly drastic enough to threaten consistency across products. At the same time, the small changes add some new life to the design. Tweaks like color changes, illustrations, or adding a pulsing dot can be just what the product calls for, so it’s crucial to leave that possibility open. <\/span><\/p>\n

Atlassian gives product design enough freedom to build and change components based on their own individual use cases. This gives designers room to experiment and create variations, which opens up the possibility of improving on the original designs, especially considering individual product needs. <\/span><\/p>\n

Design systems simply can’t account for every need for every product. You wouldn’t want them to, either; that kind of cross-product uniformity would limit all your products, not to mention appear repetitive for multi-product users. So to get the best of both worlds, Atlassian provided the foundation for UI components in their design system, but gave enough flexibility that individual products could modify them as needed. This philosophy extends to how enterprises organize their data and systems as well\u2014platforms like Adalo<\/a> embrace similar principles by allowing teams to build custom database-driven apps with flexible components rather than forcing a one-size-fits-all approach.<\/span><\/p>\n

Learning 2: Look at what’s in product, synthesise, and build forward. <\/span><\/h2>\n

\"Look<\/span><\/h2>\n

To perfect each component, Atlassian relies on feedback, whether user research, usability testing, or comments straight from the users themselves. Normally, each individual product would iterate the feedback into progressive prototypes and move forward on its own. Atlassian, though, encourages synthesising the feedback from all products first. <\/span><\/p>\n

For one thing, accounting for feedback from all products adds enough diversity to balance everything out. As Allard explains, “Some products might have made some bad decisions or some products might have taken shortcuts along the way. So this is a moment when you can fill those stop-gaps and help them get that extra kick.” <\/span><\/p>\n

The other major advantage of synthesising feedback is that the individual components are stress-tested in multiple scenarios, providing a more accurate understanding of how they should be treated. This provides extensive data and opens up improvements that a single product’s feedback wouldn’t reach on its own. <\/span><\/p>\n

\"Illustration<\/p>\n

This is the method that helped Atlassian develop two new components, both born from the feedback of previous iterations. The Spotlight is “essentially a type of chaperon that will show you around the interface,” while the User Benefit Modal can “help you kick-start your new experience, telling you some highlights and why this experience is good for you.” <\/span><\/p>\n

By looking at the entire forest instead of the individual trees, Atlassian was able to identity some UI elements that were missing across the board, and subsequently add them. <\/span><\/p>\n

Learnings 3 & 4<\/span><\/h2>\n

We don’t want to give too much away in the recap. To learn more about how Atlassian handles design systems \u2014 straight from the mouth of a senior designer \u2014 watch the video below. <\/span><\/p>\n

The hour-long video covers all 4 learning points, plus an informative Q&A after the presentation with questions from designers all around the world. You’ll discover a lot of professional insights straight from the mouth of an expert, such as: <\/span><\/p>\n

    \n
  • How to incorporate user experience into component design. <\/span><\/li>\n
  • How to build a cohesive user flow by combining chains of components. <\/span><\/li>\n
  • How to synthesise experiences the same way as components, including a case study of Atlassian’s process.<\/span><\/li>\n
  • Why you should build your design system as if it were a product<\/span><\/li>\n
  • A personal account of how Atlassian evaluated their product line for a “roadmap alignment” to see which design system components to prioritize.<\/span><\/li>\n
  • More trade details about how Atlassian devised their “First Impression” framework for onboarding. <\/span><\/li>\n
  • Realistic time frames for building and implementing design systems.<\/span><\/li>\n
  • The best ways to introduce design systems to other departments internally, and how to get them on board.  <\/span><\/li>\n
  • Recommendations for follow-up resources on how to start building a design system. <\/span><\/li>\n<\/ul>\n

    To see Allard’s presentation in its entirety, click the video below now.<\/span><\/p>\n