Note that this is an unedited transcript of a live event and therefore may contain errors. This transcript is the joint property of CaptionsLIVE and the authorised party responsible for payment and may not be copied or used by any other party without authorisation. www.captionslive.au | captionslive@outlook.com | 0447 904 255 UX Australia UX Australia 2023 Friday, 25 August 2023 Captioned by: Kasey Allen & Bernadette McGoldrick

CaptionsLIVE Raw Transcript _____________________________________________________________________________________________________ Note that this is an unedited transcript of a live event and therefore may contain errors. This transcript is the joint property of CaptionsLIVE and the authorised party responsible for payment and may not be copied or used by any other party without authorisation. Page 35 STEVE BATY: Let's get started for our mid-morning session. Slight change of pace for our next talk, we have Eva, Klaus and Maria from Atlassian talking about their ongoing journey with their design system. Please join me in welcoming them to the stage. (APPLAUSE) MARIA CHRISTLEY: Hi, everyone, great to be here. I am Maria Christley and I am the head of design for Atlassian. One of our flagship products is the Atlassian Design System and today I am here speaking with Eva Plaisted, a senior product designer, and Klaus Paiva, a senior engineer, and for the next 45 minutes, we will share how we are approaching how we are going smaller to go bigger. We will cover it from lots of different perspectives, so whether you are here as a design manager, or as a designer of any discipline, or even as a developer or a business owner of a design system, there will be something here for you. For me personally, I have always found it really important to have a deep sense of purpose and meaning in everything that I have done throughout my design career. So when I joined this role two years ago, that was no different. We started on the path to reimagine the Atlassian Design System and enable it to be the cornerstone of crafting quality user interfaces at scale. Where every single designer and developer reaches their potential in not only what they ship but how they ship it to our

CaptionsLIVE Raw Transcript _____________________________________________________________________________________________________ Note that this is an unedited transcript of a live event and therefore may contain errors. This transcript is the joint property of CaptionsLIVE and the authorised party responsible for payment and may not be copied or used by any other party without authorisation. Page 36 customers. It is important to us cornerstone is important to us because it is the first masonry stone that is laid in a foundation in which all other stones are set in reference to. Back in 2021, Atlassian as a company experienced tremendous hyper-growth and we found ourselves needing to support over 18 products, we had over 4,000 designers and front-end developers and over 30,000 vendors all delivering customer value to our millions of customers worldwide. So regardless of your size, all of us here have experienced varying degrees of hyper-growth and the demands that this would place on your design system. With this sudden scale, we were caught in the middle of a wicked intersection. We had to support the past, which had an incredibly high maintenance burden, we had to support the present, where this hyper-growth was driving high demand and we suddenly found ourselves not being modern by our customer standards, we didn't have table stake solutions like universal dark mode, we weren't world class by industry standards because we were missing key foundations infra and tooling and we weren't useful to our makers and they are those designers and developers who were creating their own custom components or making their own best guesses. This friction was creating a loss of trust with our stakeholders. When you are in this much pain on the inside, it is really difficult to stay strong on the outside, there is absolutely no opportunities to focus on your future. So our strategy around going smaller to go bigger is about unleashing the potential for high quality design decisions to be made with confidence and speed and this is an enabler for designer and developer productivity and it is about unlocking the dependency on the Atlassian design system to have an answer for every single type of design composition imaginable which is not sustainable at our scale. We want to

CaptionsLIVE Raw Transcript _____________________________________________________________________________________________________ Note that this is an unedited transcript of a live event and therefore may contain errors. This transcript is the joint property of CaptionsLIVE and the authorised party responsible for payment and may not be copied or used by any other party without authorisation. Page 37 share with you today three key areas in which we have gone smaller to go bigger. So the first one starts with you as a team and how you're setting yourself up for success. The second one focuses on your ability to deliver composability, to be effective to your maker, who I mentioned with the designers and developers. Thirdly, how the first two then gives you the capacity and the space to work on your design systems future so that you can empower for the long term. Let's talk about team. When a design system tries to please everyone, it actually pleases no-one. Our secret team mascot during this really pressing time became Psyduck who looks exactly how we were all feeling. So we learned pretty quickly that we needed to be intentional about our experience strategy and then what would unlock the biggest value first? Design systems needs to be treated like evergreen products and then that product is delivering a service in order to create value. We weren't in a position to do this effectively as we were suffering under the weight of expectations, a lock of clarity in our boundaries and there were far too many cooks in the kitchen for us to make effective decisions. Our team, health and morale was suffering, as design systems are for people, the people you should invest in first is that of your own team. You need to create the right environment for your team to harness this equation and realise that value. I know how incredibly obvious that sounds, but without naming any names, how many times in the physical or digital world have we seen these types of examples? The carpeting department is clearly not speaking to the building department and this has created a major usability fail here. Or even in the year 2023, we still continue to see the latest parking ticket machines look like this. I don't have any words to describe why that is the case. So all of this is referred to Conway's Law, where an organisation's

CaptionsLIVE Raw Transcript _____________________________________________________________________________________________________ Note that this is an unedited transcript of a live event and therefore may contain errors. This transcript is the joint property of CaptionsLIVE and the authorised party responsible for payment and may not be copied or used by any other party without authorisation. Page 38 output is directly related to how it communicates internally and we heard some of that yesterday. In other words, how we organise our teams effects how we perform our work and we actually use this to our advantage in our design system. We actually codesigned our AUGstructure with our team to bring them on a journey and make them feel part of this transformation. You can see here how Jack is highlighting how empowering this made him feel, so not only did this serve as a way to further embed our understanding of our direction but it enabled team members to think about how they saw themselves in it. Here, Ali is asking a great question about product partnerships. A sense of belonging, purpose and clarity on our team's goals is something that we track at Atlassian through team health surveys and it was incredibly important to me and other leaders that we not only applied human-centred design to our work but that we applied it to ourselves. How did we go smaller? Having started out as one team, we shifted to a missions-based model of four smaller sub-teams. Two of those teams focused on our UI foundations like colour, spacing and grid, and then there was another team dedicated to accessibility and another to the maker experience. So remember that I said that design systems are actually a product that delivers a service? Well this service design and end to end journey approach is how this final team looks at the world. We also identified the capabilities that needed to be shared across all of these smaller teams and we tightened our leadership structure with a balance of managers and craft leads. Conway's Law positions that smaller teams are actually more cohesive and produce better results more quickly. By having each of our four smaller sub-teams focus on these meaningful missions, they were empowered, they had higher autonomy and our delivery cadence significantly increased, therefore making our team more productive.

CaptionsLIVE Raw Transcript _____________________________________________________________________________________________________ Note that this is an unedited transcript of a live event and therefore may contain errors. This transcript is the joint property of CaptionsLIVE and the authorised party responsible for payment and may not be copied or used by any other party without authorisation. Page 39 As a take away from this, you should acknowledge that you are actually guaranteed to ship your AUGstructure and you should embrace that and identify the design systems strategy that you want to support and then match that to a missions-based team structure. I will now had to Eva. EVA PLAISTED: Now that we have looked at our team structure and how it allows us to work faster and more productively, let's take a step closer and talk about what we are doing in our day to day, to enable us to scale our system quickly with the demands of our products through the lens of composability. As Maria showed, our team is comprised of four sub-teams, two of which were dedicated to building out our UI foundations. Klaus and I sit about here. We have spent one and a half years building out a new spacing system, a good example of how we are going smaller to go bigger. I will start with the work our UI teams is doing holistically and Klaus and I will talk about how we are approaching it through the work we are doing in spacing. As a design system team, when we build anything for such a large group of products, be it a foundational element like spacing or a component like a card, it needs to be flexible, scaleable and maintainable. In terms of flexibility, it needs to work for a variety of different experiences from Confluence to Jira to Trello and beyond. Confluence is used for knowledge sharing and needs to be friendly, open, easily legible, it requires a different experience to Jira which is used for data tracking and needs to pack a lot of information densely into a small space. We need to be able to design for a wide variety of different situations. Our solutions need to be scaleable, if and when we add more products or experiences, the system needs to be set up so it can accommodate these as seamlessly as possible. Finally, our design system team needs to be

CaptionsLIVE Raw Transcript _____________________________________________________________________________________________________ Note that this is an unedited transcript of a live event and therefore may contain errors. This transcript is the joint property of CaptionsLIVE and the authorised party responsible for payment and may not be copied or used by any other party without authorisation. Page 40 able to support our makers in a timely and efficient way. We need to ensure that the systems we set up help us help our makers move quickly and just to clarify, when I say "makers", I am talking about the designers and engineers who are using our design system to build Atlassian products every day. Let's take that card component I mentioned earlier as an example. This is actually one of our more frequently requested components that we don't have in our library yet. So with over 18-plus products we have a lot of different cards to support. These are just a few. There is a great variety between these cards which represents both the needs of different products but also the needs within products within different experiences. How do we create a card component that fits all of our various product needs and allows our makers to stay within the system? After all, if they don't stay connected to the system, it is not really a system. We have a few options. We can create a super card component that does absolutely everything and anything. I am not sure this would even be possible but anyone who has built components in a design tool knows this breaks down eventually and it is not really scaleable. It would become bloated and continuous additions and amendments wouldn't be maintainable by our team. We could create and maintain all of the card components. If you only have a few cards this should work fine but when you are supporting so many products with so many variations, this option falls apart quickly because our team is left to maintain all the different versions, updates, edits, new variations, new cards. What we gain, maybe in scaleability, we lose in maintainability and almost surely in speed. What do we do? Our third option, and this is where composability comes in, is to break our card component down into a smaller system of UI elements

CaptionsLIVE Raw Transcript _____________________________________________________________________________________________________ Note that this is an unedited transcript of a live event and therefore may contain errors. This transcript is the joint property of CaptionsLIVE and the authorised party responsible for payment and may not be copied or used by any other party without authorisation. Page 41 that allows for diverse composition. This option allows not only for flexibility, scaleability and maintainability, but it puts the power back into the hands of our makers. We democratise the system and our makers are empowered to build quickly and efficiently and we are no longer the bottleneck. It allows the makers to reach their diverse needs without straying from our system. If we look at this card in terms of its foundational items now and you can see them here on the right, we have elevation, image, spacing, so we can change the values and swap some options like our heading, for instance, to a smaller one here, like this. Now we can create a different card, so this card. As you can see, it gives our makers more flexibility in composition but it keeps them within our system and using a consistent design language. How are we doing that? We have built out a system of UI elements with design tokens and what we are calling primitives. Many of you may be familiar with design tokens as they are becoming more industry standard but to recap, tokens are how we store the smallest repeatable design decisions, like space, colour and corner radius to allow for a consistent looking field. The second piece of the system is primitives, our newest addition. They are the scaffolding around the token, if the tokens are the colour, spacing and corner radius, primitives are the how and when to use them. They simplify decision-making and they improve ergonomics and design consistency. These are early days on the journey but we have just released our first layout primitives. Putting it altogether we have the menu foundations that we are building out through tokens and primitives in order to scale and modernise our system. Some of you may have heard previous talks about our work on colour and our journey to dark mode which is where it all began and now we are working on building out the rest of our foundations including spacing, typography etc. Some of the foundations will only be

CaptionsLIVE Raw Transcript _____________________________________________________________________________________________________ Note that this is an unedited transcript of a live event and therefore may contain errors. This transcript is the joint property of CaptionsLIVE and the authorised party responsible for payment and may not be copied or used by any other party without authorisation. Page 42 tokenised and some will have accompanying primitives if applicable. Just to recap while all of this is necessary, we have come to a size where a classic engagement model with our products was starting to break down, as seen by the example with the card. We needed a new way to be able to flex, scale and support our many products, as well as to easily modernise the look and feel. This model empowers both our makers and our team to move forward in harmony. I want to take a stop for a moment here and talk about how guidance is really key. When you are working with a system, you want the system to work for you, as you grow bigger, this becomes more and more imperative. Guidance is a main factor to make that happen, the easier and more effortless a system is, the easier it is to adopt. You want to have answers available such that your makers don't even get to point of asking questions. Tokens and primitives, due to their nature, embed a level of guidance into your system from the get go. Don't allow guidance to be an afterthought, put it front and centre. Now that we have talked about how we are approaching our mission of going smaller to go bigger more holistically, Klaus and I will take you through our approach for spacing. I need to give you context to do that. I will start from the beginning. When Klaus, the team and I started our spacing journey, there was nothing but this little guy, a concept of a multiple of eight pixels and an equivalent grid size variable in code. The problems we faced were many. We had loose, inconsistent guidelines that told makers to use multiples of eight, or sometimes four and it caused a lot of confusion. We had a grid size variable in code that was used unbelievably creatively to get any value that anyone desired that was not necessarily a multiple of eight or four. Our grids were outdated and hard to find, the grids that were available were based off a navigation that was no longer used by our products. Layouts were inconsistent within our

CaptionsLIVE Raw Transcript _____________________________________________________________________________________________________ Note that this is an unedited transcript of a live event and therefore may contain errors. This transcript is the joint property of CaptionsLIVE and the authorised party responsible for payment and may not be copied or used by any other party without authorisation. Page 43 suite of products. It could be jarring for a user because the layouts could shift drastically between pages and products. One leader called it a "Layout crisis". Finally, we weren't set up for responsive design, as in we had none, we didn't have a system for our makers to be able to easily create responsive experiences within their products. We started at the very beginning. We built out a scale which was informed by research across our suite of products and we spent a lot of time on this piece to make sure that we were solidifying the foundation on which everything else was going to be built. From there, we built a set of base spacing tokens to represent our scale and code. On top of that, we built a set of layout primitives, and I will go into that in more detail in a second. This is where composability comes into play. Finally, we built a grid for a larger page composition and with all these irons, we were able to control layout from the smallest elements to the largest page experience now. We also created a set of tools that our makers could use to compose their various UIs and create more consistent and coherent layouts. On top of this, we unlocked the ability to start creating responsive experiences and density theming for our customers, which was really crucial. Let's look at some of our first primitives to date. Here we have layout primitives, they are Box, Stack and Inline, which are spacing layout primitives. You can think of them as spacing components. A Box is a container with a defined padding. Stack and Inline are containers that define the spacing between items in them. Stack is determining them vertically and Inline is determining them horizontally. If this sounds familiar, it might be because this is how auto layout works in Figma. I will now show you how to use primitives by building a layout and using yet another card. You will be able to see how they work and better understand the power behind them. Let's build this card. We have three

CaptionsLIVE Raw Transcript _____________________________________________________________________________________________________ Note that this is an unedited transcript of a live event and therefore may contain errors. This transcript is the joint property of CaptionsLIVE and the authorised party responsible for payment and may not be copied or used by any other party without authorisation. Page 44 elements here, an avatar, a heading and a description. We want to put them in a container. We will put them into a Box primitive which will give it the padding. You can see here that our Box primitive is utilising our space token of 300, which is the equivalent of 24 pixels. Now we will add space between our avatar and the text elements, so we will do that using an Inline primitive that controls the space between objects horizontally. Finally, we adjust a little space between the heading and descriptive text. Here we use a Stack primitive to add the vertical space between the items and container. Like that. Our card is now complete. We have created a card for larger experiences, such as desktop screens. Now we can look at how we use the primitives to manipulate our card for different layout requirements. Our original card has a Box value of 300 and Inline of 200. We can shift these to smaller values as shown on the right to allow for a more compact size card, better for smaller screens like mobile devices. Now we can take it a step further, placing the card into a layout and use primitives to control the larger page experience. We use a Stack between the sections of the page, as well as all the primitives that we put into the card too. With all these elements in place, we now have the ability to control our spacing vertically. You can see the Stack primitives and layout have been reduced and we have shifted to the smaller cards we created that are more well suited to smaller devices and experiences. This allows us to start unlocking density theming now. We also have the ability to start controlling our spacing horizontally too, which unlocks responsive layouts. Primitives have enabled us to control the spacing of our page in both directions, horizontally and vertically. That is conceptually how primitives work in a nutshell. I want to talk about parity, finally. We strive for parity in the design system team between design and code which is key for a healthy system.

CaptionsLIVE Raw Transcript _____________________________________________________________________________________________________ Note that this is an unedited transcript of a live event and therefore may contain errors. This transcript is the joint property of CaptionsLIVE and the authorised party responsible for payment and may not be copied or used by any other party without authorisation. Page 45 Sometimes parity is not one for one. A good example is a layout primitives. When we first started creating Box, Stack and Inline we experimented with creating layout components in Figma that would mirror them as they were in code. We discovered our designers didn't want an extra level of implication if they didn't need it. If auto layout could do it, that was good enough. As we strive to meet our maker and our designer in this case, where they are, we surfaced our layout primitives only in code. To talk more about that I will pass to Klaus to give you a more in depth look. KLAUS PAIVA: Hi, everyone, my name is Klaus and I am your senior engineer on the Atlassian Design System. As Eva mentioned, I am here to talk about code. I will make it interesting and rewarding by the end of it, I promise. Let's start by thinking about UX in the context of the web. UX is what the users really experience when they are interfacing with your product and your platform. In this case, it is the vision set by design and then materialise it by code. With that said, let's increase our focus on what happens in code so we can see how everything is put together. You saw this card component in Eva's slides before and you saw how it is viewed from a design perspective. Now, let's look at how it actually is viewed in code, so we can have the full appreciation. This is the fully coded version of what that card component looks like in real life. It doesn't look too complex, does it? If you can get past the brackets, it is plain English. To better understand the parts, let me break it down so I can highlight the important bits for you. First, we have the surrounding container which is the Box element that I have represented there. It works as the wrapper for that card component. In this example, it is handling the internal spacing, the

CaptionsLIVE Raw Transcript _____________________________________________________________________________________________________ Note that this is an unedited transcript of a live event and therefore may contain errors. This transcript is the joint property of CaptionsLIVE and the authorised party responsible for payment and may not be copied or used by any other party without authorisation. Page 46 padding value for that particular card. Box as a concept could handle all the things like background, border, elevation, all those very boxy concerns but I have only shown padding for simplicity. Next, we dive deeper into a more layout-specific concern which we want to put the avatar to the left and the other to the right. That is an Inline component and then we just have to specify how much spacing we want between the two parts to achieve this layout. Finally, we have that Stack which is to handle the small vertical layout between the two pieces of text. Stack is the vertical alignment, as we expect, we just need to specify how much space we want between the elements. That sets up the full layout structure for this card component. Easy like that. If you look at the full code again, can you clearly see how everything that we have coded here is for a purpose, is explicitly declared and intentionally coded this way. There is a clear separation between what is context, what is content and what dictates how the UI should look like. That is great to know. But if you think about layout primitives, there could be more things, so why do we stop there in the first place? Let's go one step further and look into all the UI foundations. You see the two pieces of texts represents on the card there, in code they are represented by the title and description components highlighted here. I have written a title and description to abstract away the complexity that they have to absorb internally, for example, should there be links in certain situations and just plain texts in others? Should there be line editors for certain users or not? All those type of things. What really matters for this particular topic is, in the simplest forms for presentation purposes, they are just another type of primitive which are, what we call in our system, typographic primitives and they compliment layout primitives. Typographic primitives have specific concerns as to how

CaptionsLIVE Raw Transcript _____________________________________________________________________________________________________ Note that this is an unedited transcript of a live event and therefore may contain errors. This transcript is the joint property of CaptionsLIVE and the authorised party responsible for payment and may not be copied or used by any other party without authorisation. Page 47 text should appear on a given screen, what combinations are possible for best user experience, contrast validation for accessibility against a neighbouring box, etc. They really compliment and work well with each other. Maybe up to this point you would say code is not my cup of tea, so all you said sounds Greek but you really want to know why these primitives are so helpful, so here are the key benefits for everyone's benefit. Firstly, better designer and developer experience translates into better user experience overall. The increasing the productivity happens because designers and engineers compose their UIs in the same way. Next, we have a pervasive information architecture being used. It is a shared language between designer and engineer that is better handover which I will cover more shortly. And last but not least, less time spent handling boiler plate, or scaffolding means more time shipping features which is incredibly powerful. I also understand you guys probably like to see numbers based on our observations so far. What we have discovered at this stage is that this increases inefficiency, it can help save six plus hours of design time per week, per designer when there is a lot of conversation happening during handover, which leads me to my next topic. As you probably know, handover, just to be clear, is that step between what a designer has created and what the engineer is going to codify for the end user. How do we do it? That is a great question, I am glad you ask it. (LAUGHTER) In a single sentence, what we do is we bring the tools closer together, to create a lovely synergy between the cracks. That is theoretical, I know. I will make it more concrete. That is an expansion of Eva's slide from before, what you see here is where most of the magic

CaptionsLIVE Raw Transcript _____________________________________________________________________________________________________ Note that this is an unedited transcript of a live event and therefore may contain errors. This transcript is the joint property of CaptionsLIVE and the authorised party responsible for payment and may not be copied or used by any other party without authorisation. Page 48 happens from a handover stand point. When you go in Figma and layout things, especially if you are using auto layout, there is work that we do to approximate and create an equivalent representation of that for code. In this example, virtually all combinations of what you can do with the layout, mapped to one of the primitives in our system, Box, Stack and Inline. Let me show you specific examples but just to draw a comparison to the typography, you can use the same approach but in this case, we use tokens more directly. Here we have a design that are is specifying that a particular frame that they have selected should have a vertical layout and that means it maps perfectly to the Stack representation that we have in code, you could just use a component like that. One more for good measure. We have a horizontal layout in this type of situation but it indicates that it wraps, so you can see the square there. This becomes an Inline with our system and we achieve that so it matches what Figma has. That is great. Naturally, some of you could be thinking with your hats here and thinking there are only so many combinations of layout or things like this that we can express with a high level primitive in code. That is fair. For more bespoke experiences we still want makers to maximise their creativity, while still adhering to the system in place. Remember what Eva mentioned, we want to keep everyone in the system still. Our solution for these types of cases is called Xcss. To better understand Xcss, think about vanilla CSS first, even if you are not overly familiar with CSS, it handles all your styling needs but with all that power, even if you have this support from variables, there is little guidance that you receive as an engineer in context. CSS is often enough, the wild west for what the web site looks like. Xcss, on the other hand, is explicitly opinionated. We offer makers the power of customer styles within the guard rails of our system. We get the best of both worlds, linking back to

CaptionsLIVE Raw Transcript _____________________________________________________________________________________________________ Note that this is an unedited transcript of a live event and therefore may contain errors. This transcript is the joint property of CaptionsLIVE and the authorised party responsible for payment and may not be copied or used by any other party without authorisation. Page 49 that guidance piece Eva spoke about before. To cover all the characteristics about Xcss, I will need 15 minutes of your time which I don't have but here is a 30 second to point showcase instead. When an engineer is specifying values in code, such as dimensions, colours all those things, they use token names and these token names match one-to-one what appears in Figma, in perfect parity. There is no confusion or no guess what. Similarly, when someone is doing a responsive work, there is no guess work around break points and engineers don't need to craft media queries on their own or just get things repeated or sometimes accidentally wrong. We use the same terminology for responsive as presently designed, again no confusion. Excellent. Let me take a second here because some of you could be thinking at this stage that you heard me saying the word Figma and parity in every single slide. You could be thinking with yourself "Aren't you guys too close to what Figma is doing? Isn't that a case of vendor locking in?" Another great question. It is a good question because you never know Figma could be acquired by a big company, change its direction, who knows. You have to be prepared. (LAUGHTER) Just to say that what we have based our solution on is a stable and well tested set of open standards, the web platform. So behind the scenes what you really see and use in Figma, in the same way that our primitives in code is an implementation of Flexbox being used, we know this is a solid web standard and it is not going away any time soon. Even if we decide to change our tools to use for something else, we can realign the terminology and we still maintain the same foundations throughout. With all the under the hood now covered, let's talk about the project itself to give everyone a higher level of a view in everything that we have employed to support things. I am going to highlight three key principles that our work has followed throughout and that we understand it has

CaptionsLIVE Raw Transcript _____________________________________________________________________________________________________ Note that this is an unedited transcript of a live event and therefore may contain errors. This transcript is the joint property of CaptionsLIVE and the authorised party responsible for payment and may not be copied or used by any other party without authorisation. Page 50 helped us reach our goals. The key things are cohesion, composition and confidence. Let's start with cohesion. Cohesion, we want our suite of Atlassian products to maintain their familiarity, at the same time that the experience is unique and distinctive on our own. Designers and engineers are makers, they know they can use solid and cohesive building blocks to create all types of user experiences. Composition. Interesting question. Have you guys wondered why Lego pieces are so small? Not just because they are dangerous for kids, but because the smaller pieces mean higher fidelity. No matter what you view, you can always identify what the general purpose for that construction is and you can always identify that they are Lego pieces. We have designed a set of primitives to be small, but representative enough, so they can be composed virtually infinitely, where its users is the intentionally expressive. Finally, confidence, when code is written in a clarity and expressive manner it reads like poetry, like I showed before, code transforming tools, such as code mods can modify existing users and evolve the system as a whole, and we can bring everything forward if needs be. If we ever need to realign terminology, remember Figma could be acquired, we are just a code mode away from fixing things because we are confident we can tag the right code and identify their proper usages. Now with all that nicely covered, I am happy to hand over to Maria to talk about the future of our system. MARIA CHRISTLEY: Thanks, Klaus. Now that we had our team going smaller and we figured out how to do composability to go smaller and we had those in place, this gave us the capacity as a team to work on our design systems future. With our design system being 10 years old, we

CaptionsLIVE Raw Transcript _____________________________________________________________________________________________________ Note that this is an unedited transcript of a live event and therefore may contain errors. This transcript is the joint property of CaptionsLIVE and the authorised party responsible for payment and may not be copied or used by any other party without authorisation. Page 51 asked ourselves what do the next 10 years hold? What might our design system need to support in the year 2033? One of our strategic guiding principles of the future is this: to make experience quality the pit of success. Imagine the effort of climbing a mountain and now compare that to the effort of sliding down a hill and into a pit. That is a lot easier and exactly how we want our designers and developers to feel when they are using our design system, but the right thing to do should happen by default and this is where tooling, automation and engineering linting come in. But when this is not possible, the right thing to do should be easier than the wrong thing. We are making it easier to use our design system than not use it, in essence. As Jennie Yip, our principal design architect, who takes a lot of inspiration from the global design systems community, she reminds us we are shifting our culture through systems thinking and this starts by laying the foundations at enterprise scale to rebuild and reimagine our design system from the ground up. This starts to democratise our design system and multiply our impact and the potential of every team that uses it. All of this is really nicely summed up in our vision of the future. (VIDEO PLAYS) >> The language we all speak is Atlassian design. It is woven into our experiences and it has changed as much as Atlassian itself. Like any language, it adapts and the next evolution is here. After 10 years in the making, we are reimagining Atlassian Design System, we are using elements of our language to evolve with us, making Atlassian Design System the cornerstone of crafting quality interfaces that are unmistakably Atlassian. Constellating starts by establishing a stronger foundation. The building blocks are easier to use and configure,

CaptionsLIVE Raw Transcript _____________________________________________________________________________________________________ Note that this is an unedited transcript of a live event and therefore may contain errors. This transcript is the joint property of CaptionsLIVE and the authorised party responsible for payment and may not be copied or used by any other party without authorisation. Page 52 empowering developers and designers to create seamless beautiful experiences better and faster. Every part of the system works together harmoniously by supporting accessibility, performance and consistency from the ground up, all designers and developers have the power to cocreate inclusive, accessible and on brand experiences that meet our world class standards. Atlassian Design System is built to be empowering for everyone who relies on it, we are giving you the tools and freedom you need to create and manage your own local systems, building your experiences with the design system as the base ensures that we continuously evolve and scale our design language efficiently and harmoniously. Because ultimately, Atlassian Design System is what we create together as a community, as our system of systems multiplies, so does the potential of every team. We all can't wait to see what you make next. MARIA CHRISTLEY: The impact of this recently saw us deliver a universal dark thing solution across the company and into products like Jira, Trello and Confluence. This is actually underpinned by our colour system which contains over 300 design tokens, all powered by the Atlassian Design System. We have now rolled out primitives across the company to see us power designer and develop a productivity. We have every confidence that we are going down the right path, which is definitely not easy and has its challenges every single day. We have also anchored our future strategy in these three systemic shifts that will see us into the next 10 years. The first one is foundational. As you saw Eva and Klaus present, we are going smaller to go bigger and strengthening our UI foundations to modernise our system. Harmonious, we are meeting the maker, the

CaptionsLIVE Raw Transcript _____________________________________________________________________________________________________ Note that this is an unedited transcript of a live event and therefore may contain errors. This transcript is the joint property of CaptionsLIVE and the authorised party responsible for payment and may not be copied or used by any other party without authorisation. Page 53 designers and developers where they are to build trust and improve the end to end service experience of our design system. Finally, empowering, where we scale our system into a platform that powers other local systems as we make it more flexible and extensible to build from. To see more of the work that we have presented, please visit us Atlassian.design and we can't wait to see what each of you do next inside of your design sections. A thank you to our 50 plus team for evolving with us over the last two years. Thank you very much. (APPLAUSE) STEVE BATY: We have time for questions. Before we go to them, I have one that came in via the virtual channel which is "Are you accepting suggestions or ideas from the community and if so what kind of governance process do you have in place?" MARIA CHRISTLEY: That is one of the hottest topics going around. STEVE BATY: I am sure. MARIA CHRISTLEY: I might add to that, I think contribution of 10 years ago is not the same as what contribution should look like moving forwards. Because we are working on our UI foundations and the primitives as we shared today, we are enabling designers and developers to make the right choices for the right context of that product experience. We are no longer the design governing authority or the police and we are empowering and making those other design leaders more accountable for the decisions that they make within their products. We are in the middle of revamping our design system engagement model and one of those aspects of that engagement model is contribution. We pilot and partner with a lot of our stakeholders because we want to do things in practice

CaptionsLIVE Raw Transcript _____________________________________________________________________________________________________ Note that this is an unedited transcript of a live event and therefore may contain errors. This transcript is the joint property of CaptionsLIVE and the authorised party responsible for payment and may not be copied or used by any other party without authorisation. Page 54 and we want to learn from actually shipping something in the real world, even if that is a pilot to a small subset, moving from Alfa to Beta to general availability. That is something that is ongoing and it is something that you need in order to test and learn. >> I am Elle, fantastic presentation. It looks really slick. Yesterday we had a great presentation from a team who have been redesigning a calendar for swimming or Zumba for elderly people in New Zealand. I don't know whether you caught it but they designed this amazing app and they realised when they piloted it, that they were getting negative feedback because the content wasn't right and, as a content strategist, I was like correct I am interested in whether you can tell me a little bit about how content fits into your design system? I know it is there, give me the spiel. MARIA CHRISTLEY: We have an amazing content lead as a part of the design system and several content designers. As you saw in our vision video, content tokens are actually really important part in making sure we have consistency in the labelling and terminology that we use across the board. A UI content system is necessary and thinking about the content strategy and how we execute our content across Atlassian is something that is very much at the forefront. EVA PLAISTED: We are trying to be more and more content first with what we do. We are trying to make sure that we are working on that guidance piece, alongside with what we are doing which is an interesting place because it means you have to be more opinionated in the beginning which is successful. It is an interesting technique because it means that we have something to work against pretty much from the get go and that

CaptionsLIVE Raw Transcript _____________________________________________________________________________________________________ Note that this is an unedited transcript of a live event and therefore may contain errors. This transcript is the joint property of CaptionsLIVE and the authorised party responsible for payment and may not be copied or used by any other party without authorisation. Page 55 is a really nice way to start. We are doing those at the same time. STEVE BATY: A question over there, Kevin? >> It was actually Elle's question, I was going to ask on her behalf. The only other thing I was going to say was, having worked with Atlassian and knowing Atlassian people, I wondered, in the mix, how involved the technical writers were when you started to look at this system from the get go? Could you talk about that journey? Was there discussion around in future we are going to try and make our content more condensed, or we will try and make it less complicated, or we will try and not use our tech talk so to speak - does that come into play at all? MARIA CHRISTLEY: It is a similar answer to what Eva touched on, was we look at content from the beginning and we have got a number of developer, as well as content designers because we need to make sure that the content is what we call pervasive IA, so we have the same labelling and terminology that is used in Figma that is used on our web site and it is used in product and it is also seen in code and in our technical documentation as well. That all has to be consistent. That is just a really important factor in delivering a system that is actually not going to break down at any point and we have a service designer who is helping us to make sure we are mapping that end to end ecosystem. A lot of the time - I get this question a lot "Why do you have a service designer on a design team?" And I am like "Because we are delivering a service and we need to understand the front and back of stage to make sure they marry up". The technical writing and content experience side is extremely important because it drives adoption and adoption for a design system is what one of the measures of success that we have.

CaptionsLIVE Raw Transcript _____________________________________________________________________________________________________ Note that this is an unedited transcript of a live event and therefore may contain errors. This transcript is the joint property of CaptionsLIVE and the authorised party responsible for payment and may not be copied or used by any other party without authorisation. Page 56 STEVE BATY: One last question down the front here in the middle. >> Hi, thank you so much for this inciteful presentation. It was super helpful. I was going to ask the same question as Steve, around the contribution system if Atlassian has a contribution system or not, in terms of new component? You have answered that already. I also want to ask, when you are starting a design system, there must be a lot of products already being designed and they are not following the current design system that you have done, so what is the process? Were you implementing a new design system to those ones that have already been built? How was that - was that difficult? MARIA CHRISTLEY: I would say that the reason we kind of undertook and kicked off this journey two years ago was because we had a design system that was great for the size and scale that we were at but it wasn't great for this hyper-growth that we talked about in our talk. We see it as - firstly, you can't mandate a design system if it doesn't meet the designers and developers' needs, right? We needed to take time to understand and actually Eva and our other colleague spent a lot of time to interview designers and developers to understand what their core needs were and apply our design methodologies and our processes to our actual product. Then from that, we identified actually how we needed to evolve the usage, education, maintenance and ongoing evolution of all of our UI foundations. Through that we found that doubling down on our colour system and getting that adopted at scale across the company has led to a lot of momentum. The first thing that you need to find is what is the most important valuable thing that matters to your business right now? Then attach your design system success to that particular program or project.

CaptionsLIVE Raw Transcript _____________________________________________________________________________________________________ Note that this is an unedited transcript of a live event and therefore may contain errors. This transcript is the joint property of CaptionsLIVE and the authorised party responsible for payment and may not be copied or used by any other party without authorisation. Page 57 You can't boil the ocean, you need to start small first and that is why we chose the colour system because it would unlock theming and dark mode and light mode and high and low contrast and we got feedback once we put it out to Jira that our dark mode was too dark. But because we had implemented the infrastructure and the tooling both from an engineering and design, once the team had dissected that research and decided on how to resolve it, we were able to roll out the change to the entire company within five days and that would not have been possible if we didn't slow down to speed up, so to speak. I think you have got to find that first thing that really is the hook, or as we called it, the Trojan horse, that is going to come in and drive that initial adoption to get that momentum. STEVE BATY: Thank you. (APPLAUSE)