Radiant, ThoughtSpot design system
What I learned by building a design system from scratch
Context
I was hired in February 2018 by the VP of Experience to build the design system of the company. A couple of attempts had been made before my time, but none had gained the necessary momentum.
After getting familiar with the situation and interviewing stakeholders at multiple levels, I realized that although everybody — from execs to designers and software engineers — agreed on the principle that a design system would be a good thing to have, when push came to shove, it was never a priority. Simply put: it was not a new feature that you can sell.
To be successful, I, therefore, needed a two-part strategy: build a great internal product (with some, quick easy wins), and successfully market it to my users (designers and developers alike), as well as the whole company — including the executive team.
Strategy
Marketing strategy: going guerilla
Although I’m intimately convinced that design systems are a great methodology to produce any kind of software — if not the only one — it’s still a relatively new concept in the industry.
That’s why you have to consider your design system as a product or — to put it in an even better way — a startup inside the startup, disrupting the way things were done before. You need to find your market fit strategy, and more importantly, you need to be loud and create a clear brand for your target audience to integrate, with almost no resources.
To start creating momentum, I had to:
- find a name: after discussing with the VP of Experience, we chose Radiant, because it was close to a geometrical concept (Radius) used in data visualization and it had an interesting glow, being central and touching everything around it — plus it’s rad.
- create a logo: I briefed one of ThoughtSpot’s most talented visual designers (Wei Zheng) and she created a logo that pictured the R of Radiant with 3 different geometric forms (a rectangle, a disc and a triangle) symbolizing the fact that a design system is a sum of different parts, while being in harmony with the brand logo for a clear association
- spread the new brand: I derived the logo into stickers, t-shirts, Slack icons and theme, etc.
And it worked! Slowly but surely, people inside of the company started to integrate the design system as something obvious, and slacking about how cool the Radiant team t-shirt looked.
Organizational strategy: the federal model
For the first year, I was the only person fully devoted to the design system. But as the project gained traction, I scaled up the team for something that was close to my ideal in terms of making progress at a decent pace:
- 2 Designers: one more senior creating designs for the components, and another who was also helping to create the components for the design library (Sketch, then Figma)
- 2 Software Engineers: one senior to be my counterpart on the Engineering side and scaffold the infrastructure and middleware of the project (JavaScript Framework, repo, Storybook, testing suite, etc.) and one who would create components for the system
- 2 UX Engineers: typically more interested in the visual aspects of things than other developers, they were also able to closely collaborate with designers when creating the components of the system
- 1 PM: this addition to the team was more strategic because I needed to have a champion on the Product side, plus she was giving me great advice on how to best track our progress
- I was leading the team, as a technical project manager and an individual contributor, setting up the overall architecture and tools for the front-front-end development (think HTML, Sass/CSS, presentational JavaScript) and the design side (Sketch and Figma libraries)
This team was never as official as other V-teams at the company — and I had to surf a lot of ambiguity — but it was nevertheless consistent through the process of creating the first iteration and a strong permanent team.
The real benefit of the federal model came when we had the opportunity to onboard all the designers of the Experience team on top of a handful of software engineers for a limited time: the company decided to devote an entire quarter to improve upon existing features in the product rather than create new ones, and we jumped on this opportunity to make sizable progress on Radiant.
Even more importantly, everyone who eventually went back to their own teams took with them great knowledge of the system and became its champions across the company.
It’s also interesting to note that not everybody can think at a system level, and that the permanent team had to support the newcomers to make sure they were delivering the best work possible. On the other hand, it’s definitely valuable to have the input from the people actually using the system and creating the new features of the company’s product so you don’t end up working from your ivory tower and totally detached from the product team and the indirect but crucial users of your system: the actual customers of your company.
Doing the work
Ultimately, I think the purpose of a design system is to define how to produce anything at a software company with the highest bar possible in terms of quality, consistency, and velocity.
But each design system has a context and — unlike component libraries — cannot be simply transposed from one company to another. Think about the company brand, the core values, the tech stack…
And to make it efficient, I’d say it boils down to 3 different aspects:
- how to make the best system decisions
- how to effectively curate decisions
- how to communicate decisions at the right time and place
How to make the best system decisions
There are so many decisions to make when producing the content of a design system: technical best practices, design principles, processes, shared language, file naming conventions, color palette, tools choices…
To make life a bit easier, I introduced a North Star, the core value proposition of Radiant: Make it easy to do the right thing.
It was simple, memorable, and yet would help navigate the complexity: it meant that we would guide developers and designers to do what was best; although they had the option to do otherwise, it would just be harder.
When I first joined the company, we were 4 members of the Experience team, and so much ground to cover that I introduced a new form of meeting: The One-Topic Meeting®.
The idea behind it was that everybody in the team was invited (and optional) to participate and that for every meeting, we would have only one topic to discuss at length and hopefully exhaust.
Topics could be anything: sketch file naming conventions, radio buttons, truncation, fonts…
And at the end of each meeting, we would write down all the conclusions that we came up with and move on to the next.
When we started, we had 3 meetings like these a week — I needed answers!
We reviewed all the work on components done by the design team collectively (this is where it’s extremely valuable to have UX Engineers in the room to add the technical perspective), then all design specs were written by the creator of the component, reviewed by at least one other designer (plus me, most of the time), before being transferred to our documentation portal.
The Radiant team also had a sync twice a week so that the essential information was communicated and validated across services.
How to effectively curate decisions
We can make the best decisions in the world, but they have a tendency to be fleeting: two weeks after a discussion, who can remember exactly what was decided and why? It’s especially critical in a startup environment when newcomers arrive at a regular pace. Tribal knowledge is a very insidious and challenging pain point of scaling, intensifying when you start to have a geo-distributed, multi-time-zoned team.
You need the rigor to methodically curate all those decisions, start to organize them, and find a system where you can review the arguments of that time because the software field is still evolving very fast. Truths of yesterday can be changed overnight.
Another challenge comes with the fact that nobody likes to create documentation: people prefer to create and execute, rather than journal what they’ve already done. That was definitely one of the critical aspects of the design system that I had to advocate for over and over again. Document for others, document for your future self, document, document, document.
There’s nothing particularly technical to it, you just need to devote time and resources to it. You also need a place where everybody can at least consult your documentation, ideally with commenting access to propose changes.
How to communicate decisions at the right time
It’s a common concept across design system thinking: a design system is about people and tools. This last aspect is definitely where tools shine.
Here’s the new challenge: although the content has been created, you can lead a horse to water but you can’t make him drink.
And that’s where we can go back to the Radiant core value proposition: make it easy to do the right thing.
You can’t expect anybody on the product team to just read the user’s manual from end to end before doing anything.
In an ideal world, you would want to provide to every team member some kind of assistant to help them make the right decision each step of the way, exactly where they are (i.e. your company’s favorite design tool or code editor) and when they need it, rather than asking them to disrupt their flow to go check the documentation.
But that’s not enough; they probably also need more and different ways to learn which can be accomplished via a multi-faceted communication strategy: documentation available 24/7 and in context, presentations, training, workshops, ad-hoc communication when things are launched or when you want to warn them about a breaking change…
The case for a design token management tool
It’s crucial to have only one source of truth and as much automation as possible, or you’re going to spend a lot of resources and time keeping everything up to date. That’s why I advocated early on to create a design token management tool.
Design tokens are the most basic element of your design system. They’re attribute-value pairs that you’ll find everywhere in your products — think a color, a size, a duration, etc.
If a simple component of your design system is an atom, design tokens are subatomic particles.
And because they’re essential and very simple, it’s also the basic minimum that you can share across different tech stacks. Before you can make your component library available to every framework, you should be able to export your design tokens to every context: CSS, JavaScript, TypeScript, iOS, Android, etc. to support more products.
Several open-source tools already exist (or are in beta state) to manage them. For Radiant, we decided to use Style Dictionary, which offered the right tools for our situation.
I’m monitoring this topic very closely, as it’s becoming a real Web standard that hopefully design tools will adopt. I’ve even joined the W3C group discussion about it.
Outcomes
First, I will encourage you to browse through the documentation portal accessible at radiant.thoughtspot.com
But because a picture is worth a thousand words, check out this before (when I joined the company) / after (when I left) of a List View:
Challenges
Lastly, I wanted to evoke the challenges that I faced leading this project.
Demonstrate that a design system is not just a component library.
Because it’s challenging to define such a complex concept as a design system in just one simple sentence, the analogy that is often used — by me and others — is: if the designers and developers were building software out of Legos, a design system would define the bricks.
It’s a striking image and easy to understand.
But the main disadvantage that I see now in this analogy is that your audience then has a tendency to reduce the whole system to a component library. It’s definitely an essential part of your system, but the risk is to not see the forest through the trees.
Position the design system as a real priority for the company with dedicated resources and a team.
Investing in your internal tools to improve productivity rather than actually producing what you sell to your customers is a hard leadership problem, even more so in the startup world when you need to deliver fast.
A design system is rarely going to be front and center in your company (except if that’s what your company sells of course!). It was an uphill battle for me but here are some arguments that you can use to convince your stakeholders: technical and design debts, scalability, maintainability, velocity — even brand reach and attracting talent when your design system is available to an external audience.
On a more personal level, I firmly believe in the value of investing in your own tools. When facing a mundane and repetitive task, I can’t help but wonder how to automate it. That’s what Larry Wall, the creator of the Perl programming language, called the virtue of laziness:
the quality that makes you go to great effort to reduce overall energy expenditure.
Cultivate empathy in contributors for their fellow teammates and challenge them to think beyond their own use case to embrace the vision of the system.
This a trait that I’ve seen in designers and developers alike: trying to solve the problem at hand without being able to grasp the larger context where their work could be reused. It means going the extra mile to do what’s best: make it cover more ground, easier to understand to somebody else, or just simple to use.
It also means that everybody in the product team needs to understand the breadth of what is already available in the system and how they can reuse it — or improve it — before creating a new component or concept from scratch. It’s less appealing and might be even less rewarding if you don’t create a culture shift at the company level.
