Let’s face it — it’s 2020. Every modern tech company has its own component library and Medium is already saturated with in-depth guides on the subject. As a front-end engineer at Marshmallow who’s been here since we were just a team of 6, I thought I’d instead share some insights into what the process of building one actually feels like. 🌚 🌝
Follow the industry leaders
Whether you’re Uber, Airbnb, or a 3-person start-up, if application designs have creative involvement from multiple people, there will inevitably be disagreements. Whether that’s over visual inconsistencies or implementations of the same component, the benefits of a shared component library and design system that counter this, are undeniable.
At first, our company was building a single product (sign up flow), so the return on investment of a shared package was insignificant. As soon as we started rapidly expanding, the number of actively developing products grew to three (agent portal and customer account). 🛠
One of Marshmallow’s core values is ‘Move Fast’
This means we develop quickly but face unavoidable micro-failures on the way. We always have to be ready to improvise, adapt, and overcome.
I found myself copying and pasting old components that resembled legacy code over to new projects… not ideal.
Even 1 shared component is a solid start
When on top of that each team starts tweaking it to suit their needs, we end up with three different variations of a <Button /> or <TextInput/> components, with slightly different UI, API, and logic. 😰
Frustrating? Yes. Completely unmanageable? No.
If you’re also a perfectionist — you’ll understand. The same way it hurts to see an odd number of pixels in a Figma design, it feels uncomfortable but you know that ultimately, it’s fine.
I personally encourage you to analyze your codebase, pick a commonly used component, confirm the visuals, narrow the core functionality, and make it happen. 🏗
Aim for quick wins and be ready to maneuver
Where companies like Facebook, Airbnb or Uber have teams whose full-time job it is to refine and maintain the most sophisticated company-wide design systems and component libraries, we do not have that luxury. But joining a company so established would mean I wouldn’t have observed a team of 6 with no product, grow to a team of 50+, and sell tens of thousands of insurance policies in such a short space of time. 🚀
Tech people by nature love abstractions and sometimes tend to over-engineer, but for a core developer in a fast-paced startup, with a mission and track-record of hyper-growth, this approach would not be productive. After all, perfectionism is the enemy of progress.
Use what you have, understand your limitations, and make the best of it.
At the end of the day
We’re already enjoying the benefits of Marshmallow’s own component library “S’Mores” (pun intended) — and I’m pretty positive about its future. We’ve seen increased team velocity, consistent UI, and it’s a great foundation for the building blocks of our applications. It’s also a useful resource for our designers, helping them understand any technical constraints and limitations.
On a personal level, the most rewarding part of my work is hearing other teammates benefiting from something you have created for them.🖤
We’ve decided to keep the source code public on GitHub as a way of allowing future joiners to take a look at what we are working on at Marshmallow.
Feel chatty? my DMs are open.