After three years, only now are we figuring out “what design is” for Supabase and how it functions in the wider org.
We recently became a team of three, developing a somewhat-unique culture to increase the output and quality of our own team and the product teams. Here are a few insights into what we’ve learned along the way.
Our approach to design
To design at Supabase, you have to think like an agile developer.
What minimal increment will have the biggest impact, with the lowest engineering effort? We make small daily gains while simultaneously solving large milestones. We aim to ship daily and dream in years.
The emphasis is on the daily gains, unblocking problems with design work so that no team is paralyzed by how something should work, function or look. This can manifest in: static mockups, interactive prototypes in Figma, code prototypes, wireframe sketches, and sometimes we actually start building it (👀). We do any work that can help the organization build consensus.
Let’s take an example, our LWX ticket page:
Late in the build process an idea was floated to try and integrate a Wordle type easter egg into the site. We build some designs to help the discussion:
The left image is Figma where as the right is Prod. The team aligned quickly on an outcome and aesthetic and then we iterate, simplify, and evolve the concept as we go.
The designs helped to avoid bikeshedding—confining the engineering discussions to “how will someone find this” or “will someone use this”.
Iterative changes
After we have shipped to prod, design work becomes expired. Whatever is mocked before no longer serves a purpose.
We took some inspiration from Linear’s approach—taking screenshots of what is in prod, and using the screenshots to construct mockups.
Here’s an example where we are making changes to the Table Editor:
We simply screenshot what is in prod, (in this case the cells in the Table Editor) and then overlay any Figma elements on top to quickly iterate. We don’t need to keep re-building UI components in Figma just to keep up with what’s in prod.
Principle led
For a long time we operated without any sort of consensus of what Design is at Supabase: what are our values, what do we like, what do we not like?
It’s surprising how far you can get without these. After three years, we noticed that we were drifting into contradictory aesthetics and it was becoming challenging to support other teams.
When Supabase was founded, the team agreed on a set of Product Principles. Internally, we’ve expanded this concept to all teams, products, and functions at Supabase.
The Design team adopted and maintain two sets of principles:
Aesthetic principles
We needed to agree on what we collectively like and dislike on an emotional level. Aligning on a common aesthetic avoids debates on individual elements.
After the team voted on their likes and dislikes, patterns begin to emerge: colors, tones, shapes, typography, layout, etc.
We used these preferences to build higher-level alignment, leading to our founding principles such as:
Timelessness
- We always ask critically: will this still feel good in a few years?
- Are we following a trend we’ve recently seen?
- We buck trends, not follow them.
Less is more
- Always remove the fluff
- Remove overbearing information
- Dieter Rams ftw
We enforce these principles by following agreed tactics: mantras such as “be more subtle”, “simplify simplify simplify”, “use brand green only for CTA”.
This has helped the team push in a unified direction. Perhaps you have already noticed recent updates? They are more fine-tuned, more subtle, use less green, and so on.
Product design principles
Product Principles are about collaborating with Product teams. We came up with a list of principles that we think are important for effective velocity. To share just a few of our favorites:
Design for the "Postgres developer"
We are moving towards a SQL-first experience in the dashboard. You’ll see some LWX announcements that lean more into empowering developers to learn SQL.
Consolidation follows kaizen
Product Teams must ship kaizen improvements. But it’s the Design team’s role to consolidate after. This helps with velocity: we are not a blocker in the development process.
For example, yesterday the Frontend team added a “New organization” button in the Dashboard based on a message from Kevin (see below). They skipped Design team input and shipped a quick solution. The Design team can do a more refined layout update after LWX, improving the page as a whole.
80/20
We bias towards the 80% of developers using Supabase. Following the Pareto Principle, we focus on the smallest changes that have the largest impact on our userbase.
This isn’t always easy, since there is usually a vocal minority.
Build patterns
Repeatable actions that enforce muscle memory will always be preferred. When adding new features, (or, most likely nowadays; overhauling features) we always consider how the same UI patterns can work in other areas.
You will start to notice these principles being applied more throughout the LWX features announced this week.
Tools and Tactics
We use very few tools (across the entire org), and we build good processes and practices around them. Let’s review a couple for the Design team:
Figma
No introduction required. We’ve used Figma since the beginning and will continue to be our workhorse for application UI design and marketing design.
We’ve organized our Figma library into quarterly files, that are clearly labelled as “in progress” or “archived” so anyone can easily find the latest and greatest.
Design system
We started maintaining a library during LW5, but only recently started using it in earnest. We’ve kept the system deliberately small, only adding what we’ve used more than a few times. The library then doesn’t spread into unique use-cases and suffer from content bloat.
Luckily, Figma features such as nested components came out while we were revamping this set of components. This meant we could reduce the footprint of the design system significantly. Figma libraries previously required every permutation of a component, but it’s now easy to contain things like swappable “icons” or pseudo states like “active” within components.
The Design Engineer
They say designers who code are unicorns. So we found a few.
At some point in many Designer’s careers they become so frustrated with the speed of development and decide, enough is enough, I’m not satisfied, I’m going to learn JavaScript!
Or, it’s the other way round, a Developer is frustrated at designs handed to them, and decide it’s time to figure this out themselves.
We are describing a Design Engineer: The Unicorn.
Several team members now fit the “Design Engineer” description and it has enabled rapid shipping. Design doesn’t stop at wireframes: often some of the best iterations happen in code. Design work is treated as a reference more than a pixel-perfect outcome. With multiple Design Engineers, they are all co-owners, fine tuning what matters and what inevitably ends up in production.
Design files that update prod
Just today we saw this tweet:
Today, this statement is true. But does it need to be? Can we update production from Figma? The answer is, yes; partly.
At Supabase, we have a pipeline that exports Figma variables into CSS custom properties, used with TailwindCSS. What does this mean? Developing apps with TailwindCSS in the main monorepo uses the same color palette as our files in Figma.
Our Tailwind can now be used like this:
background.default in TailwindCSS is "bg"
background.alternative in TailwindCSS is “bg-alternative”
foreground.DEFAULT in TailwindCSS is ”text”
foreground.light in TailwindCSS is “text-light”
Now we have a fully sync’d color system between design files and our actual development environment. We can also expand into other properties such as spacing, sizes, typography and so on.
Team of three
The team has been kept small, and deliberately! Only adding people when we hit a resource tipping point. Today, we only have three people.
Jonny was the first team member in Supabase with any design background. We (just) survived until before LW5, when Marijana joined. And before LW7, Francesco joined. You may have noticed the quality creeping up while also accelerating recently.
All three compliment each other: while one shines in visual design, another does in product design, another in motion design. Though we also overlap enough in a way that helps to keep the ball rolling in an async setting.
I like this, how do I join?
We’re always on the look out for talent, even if there’s no job posting, reach out to Jonny, Marijana or Francesco on Twitter.
