Both have a similar influence on two different jobs, design and development, creating a new division of labor.

Design systems and the designer roles

Design systems are somewhat new. Even if everybody in the design sphere is talking about them right now, the consequences of their introduction in big companies are yet to be fully understood.

In my experience, one of those consequences is the separation of designers into two categories:

Great article! I wonder how you could automate the result of the contrast between 2 colors with a plugin in your design tool of choice.

What I learned by building a design system from scratch

Radiant documentation portal
Radiant documentation portal
Accessible at


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.


… and no, it doesn’t have to be how to code.

Here are a few points that have helped me assess what technical knowledge is necessary for designers to be successful.

Why it’s not necessary for designers to know how to code

One very simple reason: division of labor.

I’m not saying designers won’t benefit greatly from adding code to their skill set, but in my experience, this question arises mostly when the outcome of the production team doesn’t match the design specifications.

Nonetheless, like in team sports, the worst you can do when your team is underperforming is to take over your teammates’ roles — whether or not you are…

Z le maudit

Who wants a better solution than throwing a random number in a z-index and hope for the best?

The situation

In a complex application, developers will always compete for the highest number to put an element on top of the rest, without easily knowing what layers are already in place.

One cannot simply just write:

.my-modal {
z-index: calc(on-top-of-the-page);
.tooltip-on-my-modal {
z-index: calc(on-top-of-my-modal);

So most of the time you end up in a situation like this:

The Sketch Library version.

Part of our work on Radiant — Thoughtspot’s design system — was to recreate our Avatar component, and more specifically its crescent shape when we need to display more than one at a time.

Our first intent was to set a white border to the round shape, which might look like this:

.avatar {
width: 32px;
height: 32px;
border-radius: 50%;
border: solid 1px white

As a side note, I often ask candidates to create a round-shaped element to see if they’ll use border-radius:50%, it gives me an indication on how much they know about CSS.

OK, so this works…

Now that I’m close to having 20 years of experience (shhhh 🙊) as a designer and front-end developer, I’m realizing that I’m constantly operating based on a few principles. Here there are — in no particular order — in case you’re looking for inspiration.

1. Use the right tool for the right job.

A good tool is designed to be good for a few use cases only. That means:

- don’t try to use the same tool everywhere just because it works wonders in one instance. …

Eugene Onegin and Vladimir Lensky’s duel - Ilya Repin

As a UX Engineer at Thoughtspot and manager of Radiant (the company’s design system), one of my goals is to improve the code base of our product and especially the CSS: I’m focusing on getting visual consistency across the board (243 unique colors!) but also trying to improve the scalability and robustness of our code.

After an audit, I found out that the CSS (344 files) was written in Less with a ton of technical debt, so while I was trying to refactor everything, I’ve advocated in favor of switching from Less to Sass.

Why change?

While Less and Sass offer very…

The United States Capitol.

Being a designer means influencing your user to do the right thing — or at least to do the right things in the product you designed.
But let’s make a more general and bolder statement: designers are influencing users.
And because most of us want to solve real users’ problems — as we all should — we’re trying to make users’ lives better. When we’re lucky enough to succeed, then we’re definitely changing people’s lives. Our products do.

But let me ask you this: what are the traditional external elements of your life that influence you to do the right…

Tools. They’re all meant for a purpose. Seriously.

Like a lot of UI designers, I moved on from Photoshop to Illustrator, and from Illustrator to Sketch. But when I look back, I feel like something is missing.

I remember when Flash and Dreamweaver were the tools of choice for web projects. I used them every day for a very long time.
And I remember when Steve Jobs killed Flash and why.
I also remember that, back then, we were promised that the new tools would do the exact same things in HTML5, and rid us of the clumsy, energy-hungry, prone-to-virus Flash ecosystem.

But where are those dream tools?


Challenger of habituation on a mission to improve humanity, one idea at a time. UX Engineer Manager for the Intuit Design System.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store