Xcelerator: Delivering at speed with a design system accelerator

Timeframe: 2022 - ongoing
Role: Experience & Research Lead in a team of 5 UX and visual designers

Type: Figma, Notion
Status: Launched & live

xcelerator-hero-2

⏱ project overview

As a concept, we are all aware of how significant DesignOps efforts, and design systems are for any product, brand, service and experience.

Yet, at the start of every project, we find ourselves scrambling to either set something up from scratch, or trying to refashion a previous client's design kit -- and, sometimes unfortunately, failing to pay attention to how layers and styles are named and exposing the re-use.

How might we accelerate our Experience practice, to deliver at speed with the quality we'll be proud of?

"I think this is going to be the best thing to happen to a lot of project groups."

— Design Lead in Publicis Sapient's NY office

💫 Impact

60+ / 20+

ready-to-customize components / flows within the financial sector

6+

projects and pitches used Xcelerator kit to speed up design process

67+%

Design delivery sped up via the usage, from 12 weeks to 4 weeks on average

Key learning #1

1. Allowing time for the team to learn, and put into practice what they have for new skills, will pay dividends

This initiative was borne out of the need to:

  • Accelerate our time-to-market, reducing our set-up and delivery time to meet client expectations
  • Ensure consistency and quality, as opposed to a pre-made kit from the community
  • Centralize knowledge and upskill the team in components and design tokens
  • Rapidly scale up our design system, and quickly converting opportunities

Those were the quantifiable metrics we'd used to gain approval from the leadership team to pursue this while we were on the bench.

I had a final -- and more important -- quest, though: Skill up our team members, breaking free of the siloes that their titles afforded them in the company through learning hands-on about design's full stack of skills.

Skilling the team up through hands-on experiences

As a consultancy selling services, there is a certain box that allowed for efficient staffing on projects. Unfortunately, this meant that frustration were bound to rise.

For an example, a visual designer can continuously deepen their T-shape and be an expert in art direction and concepts on client engagements, but not given the chance to participate in research and user interviews, as they weren't scoped to do the work as it was sold. 

This was a sticky point for me as an experience lead on the team, and especially as I'd built my career dipping in and out of the different parts of the design spectrum.

While I understood the business rationale of staffing an engagement, it felt like a huge loss that opportunities were tucked away from others.

Take for example: We had visual designers who'd never sat in as observers in user interviews. Through the Xcelerator, they were fully involved in planning for the research, for both the user interviews that we scheduled from our own networks within the Publicis Sapient global team, and supporting in reverse card sorting, which was a first for everyone else in the team.

More to the point, they conducted interview sessions and were notetakers for others, and had immense fun and pride after doing so. 

I'm truly grateful for the team wanting to learn new skills, and was able to push beyond the boxes for everyone who wanted to expand themselves.

upskilling

A snapshot of how we organized note-taking, and a glimpse of how earlier sessions were used as observations before the team plunged into moderation themselves

This was made possible through our quick setting up thanks to the ResearchOps we'd set up prior, and using Notion as our base for everything that needed to be captured pre, during, and post the research activities run.

This was also one of the first projects that we tested Notion as a tool to operationalize our activities, and remains something we continue using today.

reops-base-1

Notion is an amazing tool, but we all know that already. Chef's kiss, no notes

Training the accessibility muscle

After the successful sessions for inclusive design, which included getting the team up to the basics of accessibility, we still found ourselves fumbling and clumsily correcting ourselves.

This happened occasionally, when the team kept saying "master component", rather than a more inclusive "base component".

Where it started with just me giving reminders of switching our own taxonomy, it continues today with the rest of the team being able to gently remind others of the reason why language is important.

There were also frustrations about a perceived rigidity of colours that couldn't be used because it didn't pass the check. Still, the team rose up to the occasion and were able to challenge ourselves to find good design and still keeping it to a good constrast.

It also served as a really good lesson for how accessibility should be considered from the start, rather than a process that was stacked on top by software engineers when it got to them. 

This is a muscle that needed training, and one that would hopefully be stronger as we keep iterating.

Scalability in more dimensions than one

This was also an exercise in thinking about scalability in a way that we've not done so before, as we were always confined within projects, or clients.

Thinking about the design system in the concept of our goals needed us to discard old ways of thinking, and embracing systems thinking and mental modes.

I am certain doing this has helped to sharpen our skills as designers and strategists, and ultimately fulfiled my goal of letting all of the team stretch in ways we couldn't have on client engagements.

Principles of THE XCELERATOR

⭐️ Not just a style guide

Principles and governance light up the North Star for the entire experience across devices, touchpoints, and channels

🛠️ Not just a UI kit

Best practices and patterns will guide teams to think beyond the basics, and drive consistency in products

🔂 Not just single-use

Scalability and adaptation are the priorities when building the base that can be used on multiple projects and brands

Key learning #2

User research still illuminates, even for a persona you think you are represented by

I could feel my visual designer's despair during the usability tests, as she watched UX strategists and UX designers alike start detaching instances of components.

Even other visual designers had different ideas on how to use pre-made components.

reops-workflow-1

Visualization of the workflow for different modes of the sessions

There were plenty of aha moments with the ways each of us used the same tool, through the same flows.

Even grouping users into how familiar they were with Figma yielded different behaviours (broad strokes incoming!):

  • Taxonomy-driven: Visual designers tended to use the 'Asset' tab to search for a component, which meant we had to allow for a robust searching taxonomy ("CTA" vs. "Button" vs. "Link" were all used interchangeably for their search!)
  • Convenience-driven: On the other extreme end, a UX researcher copied a component, then detached it, triggering the aforementioned horror from the designers
  • Mastery-driven: With the exception of a designer with web design background, tokens still seemed like a mystical concept to most

It was all very impactful for us as we tweaked the different ways that anybody can find the Xcelerator usable and useful.

Exactly the same as we would with any other usability test with users groups we aren't members of, we learned so much from observing. 

Key learning #3

A system is only as good as its documentation

We run into these issues for regular design systems, but trying to design and distribute a centralized system amplified how tacit written communication and intuitive instructions are. 

Naming conventions are a huge part of the success of a design system, and this initiative also allowed me to dive deeper into how we managed information flows for different types of usage and search patterns.

Communicating configurations

We wanted the system to be self-explanatory and easy to use, instead of adding friction points to already-stretched timelines during projects. 

To do that, we created plenty of documentation.

This ranged from:

  • Signposts with category labels
  • Step-by-step instructions on how each board is laid out
  • Walkthroughs on how each designer is able to update the system to their own needs
  • Componentizing components (how meta!)
readme

Walkthrough of each section, and its purpose for orientation

comm

An example of the value add we wanted to bring beyond a component library: Options for best practices within the flows to spark discussion

Version out-of-control

Version control was a beast on its own, with considerations of not being a bottleneck, but still being able to disseminate updates and changelog efficiently.

I talked about it a little in my case study for the digital transformation for Singtel.com, and while it was (luckily) in the past we had to do manual tables to log changes, we still had to play around with how we could effectively communicate that.

For transparency, we worked off a non-Enterprise Figma account, which meant that we couldn't use the built-in branches to fully wield the power of the feature.

In the end, between cost, ease, and usability, we opted for these methods:

  • The native comment system on the Figma file, for folks who are perusing the file for the first time, in each page where a component and its variation lives;
  • Email newsletters and MS Teams updates for teams/designers who are using the system in progress

We also made sure that there was one person on the team who could effectively serve as admin and governance of the Xcelerator when it got distributed into projects.

I'm still absolutely sure there are better ways to tackle this problem 😅 So much more to learn!

Lastly...

Regrettably, although we had a software engineer on the team, we didn't manage to crack the Figma to code pipeline. Several options were evaluated, from the basic with documenting it on Zeroheight, to building it on Next.js with Tailwind.

Ultimately, we made the decision to stop at Figma, as the operating model of our day-to-day is still confined to individual clients who needed these design systems (and libraries, and code bases) to be their IP.

Figma files are still scalable enough to be passed from project to project, while development wouldn't be a prudent usage of time and resources.

Now, if I were doing this in-house with products that we own, this would be a very exciting evolution of this product indeed.