Delivering quality at speed with a design system accelerator
Overall design leadership
Experience strategy
User experience
Research
Design system
DesignOps
💡 Key takeaway #1
Allowing time for the team to learn, and practice 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
Risk-managing our deliverables, and avoid usage of pre-made kits or past client work
Centralize knowledge
Upskill the team in best practices and methods for Figma usage
Rapidly scale up
Quickly converting opportunities by having pre-made and well-thought out designs
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, as a designer isn't likely to do much beyond their core skills, 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, especially as I'd built my career dipping in and out of the entire 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.
↑ Above: A snapshot of how we organized note-taking, and a glimpse of how earlier sessions were used as observation sessions before the team ventured into moderating sessions themselves
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 not just the design activities, but also for research.
They learned more about different methodologies and what we considered using — surveys? focus groups? interviews? card sorting? what is that! tree testing?! — and participated in deciding on the best methods.
↓ Below: Capturing our entire research plan on Notion -- Notion is an amazing tool, but we all know that already. Chef's kiss, no notes
More to the point, they conducted interview sessions and were notetakers for others, both the user interviews that we scheduled from our own networks within the Publicis Sapient global team. They also supported in the setting up of reverse card sorting, which was a first for them.
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. Even better: they had immense fun and pride after doing so!
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.
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.
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.
We needed to discard old ways of thinking, and embracing systems thinking:
Maximize reusability
Thinking ahead of what components are needed. across different industries, ensuring that they are broad enough to fit most use cases
Enable painless updating
Creating robust design tokens and variables to enable painless updating for individual projects
Accomodate differences
Each team, in different regions, industries, and leadership, are going to have different ways of working
I am certain doing this has helped to sharpen our skills as designers and strategists, and ultimately fulfilled my goal of letting all of the team stretch in ways we couldn't have on client engagements.
💡 Key takeaway #2
User research illuminates, even for a persona you think you are
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.
↓ Below: 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.
We could group archetypes into how familiar they are with Figma, as they yielded different behaviours (broad strokes incoming!), driven by…
Taxonomy
"CTA" vs. "Button" vs. "Link" were all used interchangeably for their search
Action: the naming of each component had to be robust
Convenience
Detach, detach, detach! (triggering the aforementioned horror from the designers)
Action: Upskilling designers on how powerful components are
Proficiency
Auto-layouts, tokens and other such features still seemed like a mystical concept to most
Action: Training and hands-on sessions to teach designers
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 takeaway #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, including:
Step-by-step instructions during onboarding
Walkthroughs on how to use the design system
Componentizing components (how meta!)
Best practices for component usage, variations and tokens
Recommendations on extending components
Accessibility do's and don'ts, with a checklist
Guidance on how to update and contextualize for projects
Changelog and roadmap for future enhancements
↓ Below: Walkthrough of each section, and its purpose for orientation
↓ Below: An example of the value add we wanted to bring beyond a component library: Options for best practices within the flows to spark discussion
↓ Below: Accomodating for the different ways users will search for a component. See "cta" being crawled in the button component
Version out-of-control
For transparency, we worked off a non-Enterprise Figma account, which meant that we couldn't use built-in features to fully wield the power of the feature.
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.
In the end, between cost, ease, and usability, we opted for these methods:
Native comment system
For folks who are perusing the file for the first time, in each page where a component and its variation lives
Over emails and Teams
For teams/designers who are using the system in progress
1 subject-matter expert
For admin matters and governance of distribution, recommendations, and updates
We're in conversations with our global capability Design Ops team to scale this up globally — an organization of 1,800 designers. This is extremely exciting as it means we'll get to tackle version control and distribution for a much larger impact now!
Alright, here's the showcase —
Some final thoughts:
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, with bespoke development based on their requirements.
This design system on Figma is still scalable enough to be passed from project to project, where it wouldn't be a prudent usage of time and resources to develop in code things that will be discarded by the clients.
Now, if I were doing this in-house with products that we own, this would be a very exciting evolution of this product indeed.
Beyond the actual design, I'd be thinking about:
Ecosystem
Beyond Figma, what is the stack that our engineering teams are using?
Deployments
Using branches, Git, and other similar methods for release cadences
Systemizing workflows
For governance, distribution, and updates
Times have changed certainly since 2022 - not just in the general design scene, but also in the way generative AI has enabled us to work more efficiently.
A lot of what we set out to do has been solved by Figma as a tool itself: UI kits, an enhanced Dev Mode, design branches, version control, design tokens… You name it, the team at Figma probably has it on their roadmap.
Yet, I'm still really excited and passionate about design systems. Giving organizations easy ways to consolidate the language and intent will be the needle-mover for their processes in the next 3-5 years, and the rising tide will bring the overall experience up as a hygiene factor.