Design System principles
Case study
In the midst of a remote-only working environment, it had become difficult to coordinate a growing team. It was tough to answer questions amongst the team and consumers of the design system in a consistent manner. It was even harder to ensure our team was working towards the same mission as we were now spread across many locations. We’d not been intentional about time as a team and gathering around our mission.
A small group (~5) of us put our heads together in our “20% time” to plan a workshop with clear goals – unifying the team. We believed that our team was missing values and principles. Values, a set of beliefs to unite around, and principles, guidance on how we’ll work in order to achieve our mission.
An entire team out for multiple consecutive days is a tough ask – support channels, scheduling conflicts, and sprints needed to be organised. What proved even harder was getting buy-in from leadership. Our triads weren't oblivious to the problems but were reluctant to commit such a large chunk of time.
Atlassian Design System
Lead designer
2021
Principles, in practice
Many companies and teams have values and principles. The need was fairly obvious but we all had slightly different ideas of what values and principles were and how they were used. We needed to be crystal clear about what they meant to us in order to create our own. I had tried-and-tested experiences about what I believed successful principles should be, and pushed to drive these for our team.
Our CX org has various principles at work. These weren’t specific enough to help us day-to-day. We needed our principles to focus on the Atlassian Design System context, but work within the wider CX landscape.
As a group, we felt they should be driven by our values and memorable. From my experiences, more specifically, the principles needed to:
- be applicable to resolve real-world discussions,
- capture our priorities to help make decisions.
The framing of our principles mattered. I proposed the framing of [important thing] > [related, equally important thing].
Alignment is hard
Our group aimed to provide as much clarity about what we wanted to do, what the output would be, and what success looked like to our leadership teams. We recorded our presentations that were reviewed and sparred across two leadership groups in multiple timezones. With some back-and-forth, we negotiated 1 total day (2 consecutive half days) and planned accordingly to keep the team running through the workshops while maximising their participation.
Remote-only workshops
Our small group shared facilitation of workshops with 30 people; fully remote. I facilitated the workshop for the creation of our principles. The wider team involvement was crucial but wasn’t necessary every step of the way. The expectations set were that these workshops are for input, so we won’t leave with final outputs. We wanted discussion verging on clarity. Words on a page can always be misinterpreted though; they can mean different things to different people at different times. To help preserve our intent, we recorded our workshops in full.
To create principles that met our criteria, I asked for input around two questions:
- conversations we consistently have,
- challenges we consistently face.
These two questions help bring to light the situations where we need our principles most.
The breadth of discussion from the workshops was heartening. It was clear our team really cared. When the workshops were complete, our group began to synthesize and clear themes emerged. We began to refine and write together as a small group, pitting our priorities against each other using the mission, strategy, and values as a guide. When creating principles in this way, using our particular framing, I needed to regularly remind our team that it’s [important thing] > [equally important thing], as it can be easy to fall into the more common [important thing] > [not important thing] which might make principles sound nice but reduces their effectiveness significantly in making decisions and capturing priorities.
Facilitation was key
Bringing the entire team together to openly discuss can get out-of-hand quickly. While cathartic, for a period, I needed focus to utilise the short amount of time we had together. When things started going to far, it was essential to be a firm voice and steer the conversation to keep us on track.
The earlier efforts aligning with our triads proved useful when refining our short list. They understood what we were trying to do. When we sparred the work, they were able to offer more pointed feedback without nearly as much time wasted on providing context. The golden piece of feedback was to go with fewer principles. If necessary, we can add more.
The principles ✨
1. Trusted fundamentals before comprehensive patterns
2. Meeting system needs before delivering features
3. Bringing people on the journey before helping for the moment
Even with no context, you can see their ability to resolve discussions and make decisions with a real sense of what we value. The team always wants to do both but if (and when) push comes to shove, we’re clear on what comes first and have a better idea, in retrospect, on how we arrived at that decision.
Application is success
The discussions in the workshops gave the team a clear sense when and where the principles were applicable. They are public on atlassian.design, which brings a certain level of accountability. The shared sense of ownership and identity these bring helped the team use them effective immediately. Our small group started highlighting this usage in team settings and giving kudos when it happened to build momentum and unify around the newly created values and principles. This showed us they were being used, our primary measure of success.
To push these even further, I set personal goals around championing, demonstrating, and advocating. We set a goal, as a team, to monitor usage numbers as well as outcomes of their use. It’s one thing to help drive work forward, but the work should be completed and/or resolved.
These values and principles are something that the Atlassian Design System team stands behind. While they might change over time, they are a clear stake in the ground for who the team believe we are and the direction we are headed.
Enough is enough
The tricky part was knowing when to stop! The deeper we went into making sure we had the exact phrasing and words, it became easy to lose sight of what the intention was – the recordings and workshop outputs were a constant to keep our words in check with the workshop intentions. I called it, after realising we’d done a few circles. In hindsight, we could’ve stopped earlier with slightly different words but still the same intent.