Sarah Federman — Senior Frontend Developer, Design Systems at Atlassian
Hi, I’m Sarah. I am a senior front end developer I guess at Atlassian and I work on our design system, which is called Atlas Kit or ADG depending on who you talk to and at what point you talk to them.
Nice. Okay, well let’s get right into it. Sarah, what’s the most difficult thing you’re facing right now in relation to design systems? Get it out of your system.
So many things, so many things. I think probably one of the top things right now is just honestly really understanding for ourselves and for the external, well internal company, external perception of what it is because we have this whole long history. We’re actually one of the older design systems out there. We’ve been around for over three years and it kind of evolved into a platform that also lives inside of our repo. So the Atlas Kit repo, which is where we house our react components, also houses a lot of other shared components that belong to other parts of the company now. So it’s kind of this watered down perception of what belongs to the design system and what belongs to other teams. And they’re inside of our repository, so we’re responsible for managing them on a repo that they live in as well.
Yeah. Interesting. So what do other people think that it is? What do they mistake it for?
I wish I had better clarity on that, but I think that a lot of it is just people want us to be everything to everyone. And some of this is coming from management and some of this is just coming from our diluted marketing, but we have things like navigation that live in our system. And navigation is a really large problem at Atlassian, which possibly should have a team around it, the way that we did at LinkedIn. And navigation has full time people on it that are being taken away from design system tasks so that’s something that we’d like to split out of the system.
And then there’s just the fact that we don’t really have a clear idea of what really is in the system, the core parts of the system and what is just kind of tangentially related. So our inputs core is something like our form layout core or is that just a pattern? These are all things that we haven’t quite worked out and we actually ran a workshop a couple of weeks ago to try and figure this out and we made a lot of progress, which was really cool.
Nice. That’s awesome. Can you talk more about that workshop? Who attended that workshop? What was some of the things that you discussed? What can you share about that?
Yeah, so it was a few people. It wasn’t everybody unfortunately. We have a rather large team, so sometimes we have to just send representatives from each of our subgroups, which are constantly changing. So it was me representing some of the theming work and the documentation websites, one of our principal engineers who is responsible for how our system relates to the rest of the platform initiatives, and two lead designers, and a content strategist. So we went around for two and a half days almost, kind of defining what makes a core component and some of the rules around that and what else is in the system. We didn’t actually drill down on categories besides what is core or foundational we call it. We just figured that out and then we figured out what’s not in the system and everything else that we are responsible for.
So next time we’ll probably drill down a little bit more. We started thinking about what is a pattern in addition to what’s core. And it just got kind of confusing with ambiguous rules so we decided to drill down on what’s core and what’s in the system but not core. And that worked out pretty well for us. One of the interesting exercises we did was we started out, before we even started the workshop, we made a Trello board just with some of the questions that we really wanted all of the team’s input on. And then during the meeting, we went through all of those cards and added to them, sanitized them, and then prioritized them. And that actually informed the way that we ran our meetings so it felt like everybody was heard, hopefully.
Yeah. That’s basically how it went. I think one of the interesting, and stop me at any point if you want to drill down on anything.
No, that’s great. Yeah.
But one of the interesting things that I was excited about as a starting point for what makes a core component was, and I’m going to take credit for this because this is actually my idea. In ARIA there are, ARIA is basically a part of the way that you can make things accessible if you’re not using default HTML elements. So we use ARIA quite a bit since we have custom selects and whatnot, but ARIA has this concept of roles and they have a, drill down a little bit this concept of widget roles and these are things that are interactive UI elements that live on the web and they’re just like a set of archetypes for these elements. So things like checkboxes, dialogues, et cetera, are types of ARIA widget roles.
And each element on the web, an HTML element has an implicit ARIA role, so input type of checkbox has the implicit ARIA role of checkbox, even if you just don’t put it on there. So basically one of the criteria that we created for determining whether something is a core component is does it align with an ARIA widget role to start. So that basically gives us things like our checkboxes, our texts fields, our inputs, our selects, our buttons, all of these things that are basic. And then it also gives us that built-in documentation and specification for how it should work based on those ARIA roles.
Interesting. So is that part of your process when you create a component or make a variation of a component, that sort of check to say, “Does it align with those widget roles?” It’s just part of that workflow now?
Going forward, yes. We haven’t quite implemented it, but it’s basically the first question of whether a component is a core component, does it adhere to one of these ARIA widget roles that are already existing and are cross platform?
What are some of the other criteria for deciding whether something is a core component?
Yeah. So I guess we are not kind of thinking about it as criteria so much as signals because anything can be a little ambiguous. And trying to make something that’s ambiguous, concrete is just an exercise in frustration. So we’re kind of thinking about it as the majority of these signals should be observed and some of the other signals are, it’s reusable and context-agnostic. So a component doesn’t really need to know where it is to know how it looks and should behave and it’s independent and isolated. So it’s not a layout component, which is still part of our system but not considered foundational. And it has to be standalone, which means it doesn’t require additional components to run. So some presentational wrappers that we have require additional wrappers to manage states. So we wouldn’t consider those foundational and it’s not tied to a specific action, usually like a business logic action or something.
So it can be used to achieve different tasks. It’s not highly related to what it says. It’s not part of the name of what it should be doing and then not opinionated about content. So it’s basically a dumb container. It needs to follow best practices, but the best practices are a guideline that aren’t built into the functionality of the component. So in a button, we expect you to truncate it in a certain way, but it’s not a limitation of how the button is built in most cases. And another one is it has to be independent of its data source. So if it has a data service or a data provider required to use it, it’s not foundational. Something like that would be the editor and possibly even our avatar service, which we’d like to kind of take away from the requirement of having the service.
But for right now, it requires that you use the avatar service as well so that wouldn’t be considered foundational. And then it just, it has to not embody Atlassian specific concepts. So an example of that would be like an issue or a status or queue. And those things are very Atlassian specific, which means that it wouldn’t be foundational.
Yeah, that’s awesome. So I mean clearly you’re working at a level of depth that is not, that is more than just like this is not a basic design system. This is a very mature design system that you’re working on. So I guess kind of to your point from the beginning of this conversation, you all went into a workshop for two days. How do you now take the findings and the things that you decided and how do you socialize that with the rest of the organization? I mean it sounds like that’s part of the challenge, right? So how do you even begin to do that?
Whew, that is a hard question to answer and I might not be the right person to answer it, but part of, right now what we’re doing is just collecting feedback from different parties about what these requirements are and how should we change them and how should we adopt them. But it’s interesting because it all sorts of plays into different organizational initiatives. So we might have something coming down the line where we actually want to move out of the current repository so that we can manage our own monorepo, et cetera, et cetera. We’re also thinking about a rebrand. So a lot of these things can kind of correlate. I’m working on a project where we combine our designer and developer documentation. So this is all kind of becoming a framework for how we move forward with all these different initiatives that are really affecting the future of the system.
And this is not on the roadmap but in my view, one of the ways that I think that it might be good to do this is to just create a very large marketed version because we do a lot of continuous versioning and releases in our design system in part because we are in a monorepo so we can individually version our components and release them. But we lose out on of the marketing opportunities of having a large version change that correlates with an event like the Atlassian conference and a named version and all of the socializing that we can do around that. So hopefully as part of a rebrand, we can do a whole marketing campaign for our system that takes all of this stuff into account and changes the perception of how we’re doing it.
Oh that’s fascinating because it sounds like what you’re saying is that this is not a design system problem specifically. This is a marketing problem for design. Is that right? Am I interpreting that right?
Everything’s a marketing problem. If you think about it hard enough. It’s an internal marketing problem and I mean there are other initiatives that are externally facing because we do have vendors that build with our components, but it’s not totally part of our concern right now.
Yeah. Gotcha. That makes a lot of sense. Well all right, so as we wrap it up, what advice do you have for somebody who’s in your position at another company? What can you tell them? What has worked for you all in figuring out how to market this well to the people that it matters to?
Resist self-imposed silos. This is my experience, is that this stuff is really hard and it’s really complex and there’s a lot of players and there’s always politics and it’s just hard and sometimes it can actually be easier to just go heads down, do this thing, present it and be like, “Well now other people should adopt this.” Or, “Well we finished this problem but you should work on yours separately.” And it’s sometimes it’s easier if you’re on a short term timeline and you don’t really want to care about other things. But in the longterm, it’s always easier to just bring other people in and create accountability for yourself by doing check-ins with management and get feedback at every level. Even though it’s going to change things, things are going to get moved around. It’s just better. For example, right now, as I said, we’re working on creating a combined design and developer documentation site.
As part of that, we were doing a technical plan and the technical plan, originally it was just like we should augment what’s there and then we found out that there’s also another initiative at the company to start working on something that helps document monorepos and we are in a monorepo, so why not use that? And then we realized that they also want to move to a framework called Gatsby and we also wanted to use Gatsby. So now we get to have the person that was working on that, on our team hopefully. And we get more manpower and womanpower to do this and it’s just a better result for the full company rather than just making our goals better.
Yeah, hooray for collaboration on that.
Yeah. Collaboration is hard but it’s good.
Awesome. Well there you have it. The most difficult thing Sarah is up against regarding design systems is fighting inaccurate perceptions and marketing it well to the people that it matters to. Sarah, thank you for joining me and for getting it out of your system. Appreciate that. I’m Dan Mall from SuperFriendly. Thanks for listening to this episode.
Linzi Berry — Design Systems Lead at Lyft