UXA2023 Eva Plaisted, Klaus Paiva and Maria Christley - Going smaller, to go bigger: A design system evolution

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 | [email protected] | 0447 904 255
UX Australia
UX Australia 2023
Friday, 25 August 2023
Captioned by: Kasey Allen & Bernadette McGoldrick

View Slide

CaptionsLIVE Raw Transcript
_____________________________________________________________________________________________________
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

View Slide

_____________________________________________________________________________________________________
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

View Slide

_____________________________________________________________________________________________________
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

View Slide

_____________________________________________________________________________________________________
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.

View Slide

_____________________________________________________________________________________________________
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

View Slide

_____________________________________________________________________________________________________
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

View Slide

_____________________________________________________________________________________________________
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

View Slide

_____________________________________________________________________________________________________
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

View Slide

_____________________________________________________________________________________________________
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

View Slide

_____________________________________________________________________________________________________
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.

View Slide

_____________________________________________________________________________________________________
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

View Slide

_____________________________________________________________________________________________________
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

View Slide

_____________________________________________________________________________________________________
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

View Slide

_____________________________________________________________________________________________________
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

View Slide

_____________________________________________________________________________________________________
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

View Slide

_____________________________________________________________________________________________________
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

View Slide

_____________________________________________________________________________________________________
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,

View Slide

_____________________________________________________________________________________________________
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

View Slide

_____________________________________________________________________________________________________
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

View Slide

_____________________________________________________________________________________________________
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

View Slide

_____________________________________________________________________________________________________
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.

View Slide

_____________________________________________________________________________________________________
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.

View Slide

_____________________________________________________________________________________________________
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)

View Slide

UXA2023 Eva Plaisted, Klaus Paiva and Maria Christley - Going smaller, to go bigger: A design system evolution

UXA2023 Eva Plaisted, Klaus Paiva and Maria Christley - Going smaller, to go bigger: A design system evolution

uxaustralia
PRO

More Decks by uxaustralia

Other Decks in Design

Featured

Transcript

UXA2023 Eva Plaisted, Klaus Paiva and Maria Christley - Going smaller, to go bigger: A design system evolution

UXA2023 Eva Plaisted, Klaus Paiva and Maria Christley - Going smaller, to go bigger: A design system evolution

uxaustralia PRO

More Decks by uxaustralia

Other Decks in Design

Featured

Transcript

uxaustralia
PRO