Atlassian design system workshop

To evangelize Atlassian’s new marketing design system, I developed a workshop focused on information and empathy building. The team building simulated the current design processes and its pain points, resulting in shared understanding of each team role.

The background

Atlassian’s marketing organization comprises multiple teams and specialties that focus on creative campaigns, user research, analytics, and digital usability. Each of these teams own different aspects of Atlassian’s digital properties and require a high level of communication and collaboration.

Three men reading the team building exercise brief together


The goals

As the owner of the new digital marketing design system, I took responsibility for the system’s adoption and evolution.

Previous communication relied on staff learning through memos, and while that disseminated high-level information, it did not inspire collaborative adoption. In turn, I developed a workshop  for onboarding and training focused on pain point discovery and empathy building.



Pain points by roles

Product marketing managers (PMM)

PMM’s didn’t have a reliable submission and prioritization process when submitting work to the web teams. The focus was so strongly attached to project ticket completion that the overall strategy often became secondary.

Developers

Developers were outnumbered by the design team 3:1. Developers were often faced with in-progress designs and inflexible deadlines that led to unnecessary crunch. Finally, the lack of a reliable pattern repository exacerbated this pain point as the amount of work scaled with the company.

Designers

The pattern library was outdated and there weren’t clear avenues for designers to validate their work with developers. Without a single source of truth, the smallest details of type spacing and color required more time for each of their corresponding developers. Designers were also unaware of the amount of tech debt that accrued which complicated the build and led to miscommunication and misaligned expectations with developers.

Evoking empathy with LARP

LARP, or Live Action Roleplaying, is an interactive experience where the participants assume “roles” and play out a scenario. I referred to this workshop as such, as the scenario that I designed would require each team member to assume a different role than their own and run through a parallel process of the current workflow.

  1. I assigned each workshop participant a contrary role to their own paired with permissions, goals, and constraints of the specified role of PMM, designer, and developer.

  2. The participants were divided into eight teams: 7 of “designers” and 1 “PMM,” and one shared team of 5 “developers.” Through paper prototyping, I facilitated a tactile experience to their screen-locked teammates and emulated the actual production process without relying on metaphor.

  3. The friction from expected challenges emerged. 

  4. Every team had access to a shared craft table of materials and tools. They also had the ability to create any additional materials that they thought were necessary. The scenario had only a single success condition: the paper prototype must have been delivered within the time limit.

  5. I facilitated an all-participant discussion that identified each role’s frustrations and led to cross-functional team process changes.

1

4

5



Outcomes

The scenario successfully emulated the workflow that the participants had currently been experiencing. This gave the teams a low stakes environment to practice their communication abilities and challenge their assumptions.

  • The “designers” proceeded to work siloed without the devs, not wanting to involve them until they were comfortable with their progress. 

  • The “PMM’s” both tried to backseat design, as well as compete for the “developers’” attention. 

  • Twenty minutes went by before the “developers” realized that they could take a more proactive role and start looking at the other teams’ progress as well as insert themselves and their knowledge base when necessary.

The scenario was so parallel to the real workflow that even the team members echoed the same pain points that their counterparts have said before:

“But it looks nothing like the design!”

“No, we’re not ready for a dev right now.”

“Is there a component for this $#*%?!”

At the conclusion of the workshop, there was overwhelming buy-in to participate and contribute to the marketing design system, knowing that their effort would help everyone across the entire organization.

Previous
Previous

Atlassian marketing design system

Next
Next

Tie Your Laces