Design systems exist for one purpose: to help you and your team ship good software.
That means that everything you do in and around your design system that isn’t shipping good software is additional process. It also means that every artifact created for your design system that isn’t shippable software is design ephemera, which will ultimately be thrown away once the software is shipped.
Heads up! This post is part two in a three-part series that expands on a conversation with Dan Mall about design systems on Learn With Jason.
Design tooling is critical, but it’s not the goal.
Tools like Figma help you create pictures of software. These pictures help provide guidance as we write software, but the pictures themselves end up in the trash after the software is built.
This requires a subtle, but very important, shift in how we think about design systems: the artifacts we create along the path to a shipped product are temporary and disposable.
Disposable doesn’t mean unimportant.
Just because something is disposable doesn’t mean it’s unimportant. This is an important point, because the intention here is not to spark a debate over the value of design, but rather to discuss the dangers of assigning too much value to short-lived artifacts and the processes that generate them.
The goal is to ship good software as quickly as possible.
In any project, we start with a goal like “ship this feature” or “add this information”.
Our job is to accomplish that goal with an optimal balance of speed and quality. If we take forever to ship because we’re trying to make it perfect, we lose. If we ship quickly but the solution is buggy, we also lose.
When we set out to build a design system, how can we make sure we’re providing the right safeguards while also keeping teams fast?
Effective software teams balance the tension between “doing it right” and “doing it fast”.
Design systems exist as guidance and guard rails to help teams quickly ship the right things.
Creating any system requires introducing additional processes. Processes provide good friction that encourage us to do the things the team has decided are best, and that’s a Good Thing™.
However, if we become dogmatic about our processes, we get bogged down in bureaucracy and things take far too long to get done. Timelines expand and we end up spending more time jumping through process hoops than actually getting anything done.
Design processes are toolkits, not checklists.
It’s fairly common to see design processes introduce checklists that look something like: first we do research, then we do wireframes, then we design in Figma, then we create a clickable prototype, then we code.
Each of the boxes on this checklist is extremely valuable, but if we’re too dogmatic and require that every design needs to be created in a certain way, we run the risk of generating artifacts for their own sake, and not because they’re actually useful.
If we reframe our thinking about design and treat our processes as toolkits instead of checklists, we can get all the benefits of healthy design processes without the slowdowns and frustration that lengthy checklists can introduce.
Tools for your design toolkit.
If we need to solve a design problem, we shouldn’t worry about how or where the work to solve the problem happens. We should instead provide our teams with a toolkit that empowers them to create designs with the fastest, least expensive approach available.
Here are some specific strategies you can use to power up your design toolkit and create effective design systems quickly.
Embrace creative chaos over dogmatic approaches.
If we can let go of thinking there’s a “right” and “wrong” way to design, we can get out of our own way and just start creating things together.
The idea is to get away from a dogmatic approach and dive into creative chaos — don’t get bogged down in getting it exactly right, and instead work on getting something that works.
Have “pixel engineering” sessions.
When collaborating with design and development, we can speed up by working across media. Maybe it makes sense to start by writing some code on Codepen — it can pretty fast to set up boxes and borders in CSS. This is what Mina Markham calls “pixel engineering”.
When you hit a more design-focused piece, take a screenshot of the code, drop it into Figma or Sketch, and design on top of it. Once you’ve got that component worked out, you might jump right back into the code.
This free-form creation removes the medium as a blocker and lets teams collaborate in a more fluid, efficient way.
Make it “kinda like this”
A great strategy here is to get away from the “it needs to be polished” mindset is to talk about designs as being “kinda like this”.
Find a design on another site or product that’s pretty close to the goal, share a screenshot of it with your team, and say, “Let’s try something kinda like this.”
If your team is into it, the developers can keep working on the general layout with a pretty good idea of what’s coming, and designers can go off and create a more polished mockup of what the final look should be.
Protip from Dan: make it super obvious that a piece of the UI is a placeholder to avoid fixating on it. Make it neon green or otherwise make sure that it’s absolutely clear this is not a final design.
Don’t get attached to pictures.
Every design artifact we create is a stepping stone toward shipping software. That means we can be a little rougher with them — we don’t need pixel perfection; we need to get unblocked so we can ship this feature!
When we use design tools, it’s easy to get attached to the designs themselves. The design artifact is ephemera. Design artifacts get thrown away when we turn them into code.
Design ephemera is trash, so let’s treat it like trash.
A challenge in design-led culture is that we get attached to pictures — but pictures aren’t software. As designers, it’s important to recognize that the goal is to build software, and we need to live in that world as much as possible.
The pictures we create lead us to great software, but we shouldn’t get attached to the pictures themselves. That means our mockups are ephemeral — if we give them too much reverence, we’re focusing on the wrong things at the expense of shipping software.
Remove layers of abstraction.
When we’re designing, we should try not to build artifacts that aren’t the thing we’re building, which is software.
Everything we generate that isn’t software is only useful in the context of the software it helps us ship. That means it’s not worth much if it prevents us from getting that software across the finish line.
Adding extra artifacts — whether they’re reports, meetings, presentations, or design files — is documentation. The only thing that’s not documentation is code, so we need to make sure we‘re focusing on that primarily, because that’s our actual product.
What’s in your toolkit?
How does your team design? Let’s talk on Twitter!
For more on design systems, check out the resources on SuperFriendly’s site, and make sure to watch out for the next post in this series!
