Alex Skougarevskaya is the Design Manager for Atlassian’s Design System. In 2015, she joined Atlassian’s Sydney office to help build up their design system when it was still in its very early stages. She worked her way up from senior designer to its Design Manager—a job that previously didn’t exist at the company.
These days, she plays a pivotal role in scaling the design system as the company evolves, sponsors team members to take on new opportunities, and facilitates a secondment program, among other initiatives. She also runs Design System Meetup in Sydney.
We spoke to Alex about the magic of design managers, the meaning of design systems, and why designers should spend time with other designers.
* This interview has been edited for length and clarity.
Inside Design: Sometimes job titles can be misunderstood or jumbled together. A senior designer isn’t necessarily accountable for the same things as a team lead or manager. How would you define the role of a design manager?
Skougarevskaya: For me, the definition is super clear. But I think it can be quite a contentious definition in the wider industry. I think design managers should have just enough to do with the day-to-day of design. I think the role is almost invisible. It’s about enablement. I’m behind-the-scenes but I make all these things happen. And on the surface, it might seem very serendipitous but there are a lot of conversations happening in the background: moving people into different projects, deciding who should take a new opportunity.
The magic of design managers is that they’re skilled at seeing opportunities for other people: being able to say, this person’s at this level right now, but in a year’s time they really should be at this level, and knowing what projects or initiatives to put in front of them to grow into that level in a year’s time.
ID: In a talk you gave earlier this year at ANZ Coders, you pointed out how each discipline that contributes to a design system “has a voice.” If a design system has various arms and legs such as content design, design, code, and brand at Atlassian, does one of these aspects have a louder voice than everything else? Is there one particular thing that holds it all together?
Skougarevskaya: We had a lot of product feedback from our external customers saying our products felt dated and clunky. This went on for a long time, so the business decided that we really needed to have a much stronger brand positioning. That’s where the business goal for that iteration of the design system was born: We needed to rebrand to position ourselves as the company for teams and collaboration.
So we brought in the right mix of people from all of those different disciplines—content, design, code, and brand—in order to create the design language that evolved as part of that project. That was a design-led initiative, but it was still supported by content, code, and tech.
That’s the beauty of design systems: they’re always evolving. There isn’t a set definition. Everything can change because maybe your company just bought another company and they have their own design system that needs to be integrated. But that’s a constraint that you never knew you were going to have. It changes all the time because the company does, too.
ID: I like how Atlassian’s design system addresses consistency: your products are fit-for-purpose individually, but they “adapt to people’s devices and contexts, rather than being consistent for the sake of consistency.”
Skougarevskaya: Previously we were so focused on consistency that we lost sight of the new parts that the design system needed to have. What we’re doing now is really looking back and making sure that we give designers far more flexibility with the components, not limiting the products in what they could do.
Ideally, you’d want to give designers very nuanced guidelines that help them make the right decisions and help them identify common UX opportunities across product.
ID: You do something at Atlassian called “design detention”—what does that involve, and how does this contribute to design system building?
Skougarevskaya: Design detention is one of the rituals that we do across the company. It came out of designers wanting to spend time with other designers. We’ve actually renamed it to “craft time” so it can extend to product and content teams, too. It helps people feel they belong to their own discipline.
It’s an optional block of time in everyone’s calendars where you come in and work on your own stuff, but you’re basically sitting with a bunch of other designers that you would not necessarily ever get to sit with. Designers are often embedded in their own products and don’t get a lot of exposure to other designers. They need an opportunity for that.
ID: At Atlassian, you’ve described design systems as “a service”. Can you talk a little bit more about the philosophy behind that?
Skougarevskaya: We weren’t really focused on being a product, we just shipped a lot of features that products required, such as drop-down menus in JIRA. We started to lose the people part of it.
When we started to shift our way of thinking, we figured that the design system should be a service that people used and kept coming back to because it was relevant to a problem they needed to solve. Once we focused on their needs and what are they were missing from the design system, it gave us a lot of focus and a great ability to demonstrate value.
When we started to talk about how many hours we saved people, it translated into full days of headcount for the scaling of a particular discipline like design or content. That really gave us an edge when we started to talk about maintaining the value of the design system across the company.
ID: A design system will never be finished. That can mean some people might be a bit hesitant about how much time and energy to invest in it. But you’ve been advocating for its value and visibility, to show that there were actual results that came out of it.
Skougarevskaya: Without having any evidence, such as gathering sentiment from our peers, it can be difficult to demonstrate what we’ve learned to our company’s management or leadership; how we’ve evolved the idea of what a design system should be offering, and what kind of resources we need to provide.
We have atlassian.design. We also have atlaskit.atlassian.com. One’s for designers, one’s for engineers. They are difficult to maintain and sync because they’re managed by different teams. Over time, we’ve been doing lots of auditing to make sure that they are consistent. But, they tend to slip because they’re two separate entities not connected in any way. We are working towards a single website. It’s really tricky.
When we started to talk about how many hours we saved people, it translated into full days of headcount… That really gave us an edge when we started to talk about maintaining the value of the design system.
I think it’s not so much about the luxury of time and resources. We’ve grown so much as a company that we really need to invest in this to make sure it can scale with us into the future.
ID: Your goal ultimately is efficiency. You don’t want the same ten people to ask the same question over and over again when you could do one search query and find a single answer within seconds.
Skougarevskaya: I think it also speaks to the amount of investment you need to do. When I talk to people about the Atlassian Design System, they look at it like, “Oh my god, it’s got so much stuff.” And it does, but it’s also been around for so long—which not a lot of other systems can really speak to.
The magic of design managers is that they’re skilled at seeing opportunities for other people.
But we’ve also evolved. It started off with figuring out why we had 44 drop-down menus when we really should only have three. It’s just finding that one thing you need to solve for your company and solving that really well… and then finding the second thing to solve to keep things moving.
Feature image courtesy of Crystal de Passillé-Chabot on Unsplash.
Nathania is a writer and editor based in Melbourne, Australia.
