Design Systems or: How I Came To Love the Engineer/Designer Relationship
If there’s one thing I’ve learned in the couple of years I’ve worked in tech it’s that most engineers don’t budget enough time to QA the look and feel of the product they’re working on. Oftentimes (when UI/UX is not roped in from the get-go) developers will overlook problems a designer would catch in an instant (i.e. padding and font inconsistencies, layout misalignment, etc.). That’s not to say that engineers can’t learn to spot these hiccups or that designers always catch them. It’s a yin and yang relationship that gets pushed to the side far too often. But here’s the kicker: if a product is too hard to navigate and understand, no one will want to use it. No engineer I know wants to be associated with a product everyone complains about on a daily basis. This is why designers are integral to the software development lifecycle and why everyone should build a strong relationship with their design team.
Any relationship takes time and effort to build. One way to start that process is through a design system.
First. What’s a Design System?
Like I said, many engineers would rather not spend an eternity debugging a CSS issue. This is where a design system saves the day. A design system is a living, breathing document consisting of two distinct parts: a set of reusable components and shared design guidelines.
You can think of components in a design system as atoms. Atoms can be things like buttons, links, input texts, etc. Smash atoms together and you get molecules, from molecules you get cells, from cells you get tissue, and… you get the point. These complex systems are built from simpler building blocks. If you want to learn more about atomic design, please do check out Brad Frost’s, the creator of this concept’s, book. As for the shared design guidelines, these are things like typography, color palettes, layout/grid system, etc.
Design systems are a shared language between designers and engineers. As with most things in life there are advantages and disadvantages to building one out.
The Pluses
The most valuable aspect to an atomic design system is unequivocally how much it streamlines the whole frontend development process. The gain here is that developers will spend less time fiddling with CSS or coding up the same interaction states for the 100th time and more time on building new features for users with these atoms. The other advantage is consistency. With all our components coming from the same central repository, we can be sure that the hover state on one link on one page will look exactly the same as one on another page. It restricts the developer from running wild and coming up with crazy styles.
Because this language is shared between designers and engineers, designers can create mockups with specs using the component names instead of redlining padding and spacing between elements on a page. For example, on my team we’ve defined layout components that dictate the padding used, one of them being a Section, which has let’s say x padding around it. Our designers can use this name to let the engineer know that this design requires a Section and won’t have to worry about redlining the design. The engineer in turn doesn’t have to know what x is, only that it is a Section. Without having to waste so much time on creating pixel perfect redlines on a single exploration, the designer will be able to try out different designs and see what works best, which is great! Multiple iterations of a design will yield a better final product.
It’s clear there are many advantages to having a design system. It gives designers and engineers more time to innovate, come up with creative solutions, and ensures a consistent look and feel for the product. But this ideal state exists only when the whole design system is finished and ready to go.
The Minuses
Onto the more pessimistic side of the coin. While it’s clear there are many great things about a design system, there are also some less than ideal things about them. Before it’s shared with the company, someone has to implement it, and while it’d be easy enough to convince a product manager of the values in having a design system, that still makes at least 1–2 engineers and a designer indisposed for the time being.
After implementation, the two biggest hurdles are adoption and maintainability. Adoption might not be such a big problem for smaller companies like ActionIQ, but it can be a problem at larger companies. For companies with many applications that were built long before a design system was ever considered, let alone set up, how do you convince 500+ engineers to completely reimplement their UIs using these new components? Hint: It’s not easy and it’s definitely something to take into consideration when roadmapping a design system.
Once your teams have adopted the system, then comes the tricky subject of maintaining the system. Software always has bugs so someone will have to be in charge of addressing said bugs when they inevitably arise. Chances are there isn’t enough manpower to have a team dedicated to this project, so there’s a high likelihood that these bug tickets will fall by the wayside for quite some time. The whole purpose of the design system is that it’s a source of truth for engineers. If there are bugs in that truth, then people will stop using it, undermining the main objective.
I don’t want to understate this; it takes a lot of design and engineering hours to get a design system up and running. It’s a lot of planning, thinking, and rethinking what the deliverables are and should be.
Takeaways
If I haven’t made it clear by now, a design system presents a lot of value for your workflow. But let me say this loud and clear: building a design system is a nontrivial task. It will take a while to flesh out the whole project, and even when it’s “done”, it’s not actually “done”. A design system is a living, breathing document. It’s always evolving and adapting to the changing world of design and tech fads (a bonus advantage I didn’t mention, a design system makes redesigns and design audits much easier).
Of course, it’s true that no company just starts with a design system ready to go, and it takes a long time to execute this project. We at ActionIQ took a two-pronged approach to tackling this behemoth:
- Motivate engineers by assigning owners and keep the timeline flexible so they can work on it in between larger product features.
- Track progress with recurring syncs between component owners and the design team and log all work through products like Airtable.
We’ve found this approach quite useful and fruitful, and hopefully it can inspire you with your own strategy.
Given all this information, we recognize that the pros far outweigh the cons for our given situation. Even with just parts of it implemented, we’ve already seen the benefits of using a design system. Meetings with our design team are much more efficient and fruitful and UI development is streamlined. It’s honestly a great asset for us on Full-Stack.
The single most valuable thing to me about this whole endeavor is the fact that engineers and designers can communicate more efficiently with each other. Engineers often are unfamiliar with design lingo and principles, while designers often lack coding or technical experience. Having a design system project allows designers to become more comfortable with the technical side of things and engineers the design side. As someone who is both technical and creative at heart, I find one of the most important relationships to build is the one between engineers and designers. Whether a design system is the right solution for your team, one thing is for certain: a healthy relationship between designers and engineers makes for great products. In a world where hyper-aware users are abound and are aware (or at the very least subconsciously aware) of what makes good, intuitive UI design, a design system is a worthy investment.
P.S. All the pictures in this article were drawn by your’s truly. If you’re curious who else has decided to put in the effort to create a design system, check out this great website!
P.P.S In case you’re wondering, yes, the article title is a play on the film Dr. Strangelove or: How I Learned to Stop Worrying and Love the Bomb. Brilliant movie, definitely go watch. kk bye!
