Design Systems at Startup Scale: Yes, Please!
Written by Jessica Schilling and Katherine Brandy — August 20, 2018
As designers, we know the importance of well-crafted visual patterns. As UX practitioners, we know consistency is critical. As front-end developers, we know how much easier atomic design makes our lives. But as team members in a small business or startup … it’s often too easy to let these fall to the wayside in our rush to get stuff deployed. That’s where design systems come in. At first glance, particularly in an Agile shop, this might seem counterintuitive: Why would you devote time to documenting design for something that’s in constant flux? As the user experience team at Solaria Labs, the innovation incubator at Liberty Mutual Insurance, we understand this well: We’re a small team in a lab that’s essentially a group of small, timeboxed startups. But since our incubator is part of our much larger parent company, we’re also well versed in the speed and efficiency that comes with a well-built design system. As the lab’s UX team, we really wanted the best of both worlds: on-the-fly generation of design patterns to serve us in the long run, but not cramp our Agile style.
In true test-and-learn fashion, we decided to try this out on the Solaria brand itself, creating a public-facing Solaria Labs stylebook using InVision’s new Design System Manager. The Solaria visual identity is pretty straightforward, but as a UX team, we’re always re-explaining and enforcing it with an ever-changing roster of interns, staff from Liberty Mutual’s home office joining us for temporary innovation placements, and new lab employees. Creating a lab brand book gave us an opportunity not only to prove that small-scale design systems are valuable for other lab projects, but also to make sure our people always have access to correct, consistent Solaria assets. Plus, we had a lab-wide, two-day hackathon on our schedules — a perfect opportunity to give the project a go. Here’s a run-down on how it went from product designer Kate Brandy and myself (senior product designer Jessica Schilling).
What we did
Jessica: We built an entire design system in less than 24 hours — impressive, right? Joking aside, we did spin up the lab’s design system in two working days, but in the spirit of Agile, it definitely wasn’t intended to be perfect the first time around. This project was about creating a lab style guide, but it was just as much about proof-testing how we might build and maintain design systems for our other projects and products as they — and our lab as a whole — grow.
Kate: This was also a great opportunity to create a public-facing resource— an externally visible brand book — that could act as a window into how we work as a lab. The challenges that came with balancing what should be publicly accessible and what needed to be protected also brought a lot of interesting considerations into play that we’ll be able to utilize for future projects.
Why we did it
Kate: One reason we decided to use the Solaria brand for our prototype design system was scalability, both for our UX team and the lab at large. We’ve been a staff of two for the last year, but we’ve just added a third team member and are expanding further in the next few months. It’s fine to keep track of logos, colors and other assets in an ad-hoc way when there are only two of you, but add even one more person and things get confusing.
Jessica: Plus, there’s always a steady stream of interns or innovation-placement staff from home office needing lab-branded artifacts like logos, official icons/colors, and document templates … followed by a new batch of people a few months later. We needed a way for these folks to easily get hold of what they needed in a way that didn’t involve a ton of intervention on the UX team’s part.
Kate: And also, as as the lab grew in size, we realized we really needed to set aside some time to devote our attention to the Solaria style and brand as a whole — to get together as a UX team, talk through what we liked and what didn’t work so well, and get everything down in words and artifacts.
What tools we chose
Kate: After a lot of exploration, we landed on a combination of InVision’s Design System Manager for public-facing materials and our internal Confluence instance for protected assets. Why? While it was important to us to keep the bulk of our design system publicly visible — the lab is really committed to transparency — we realized that some items really did need to be kept behind a login.
Jessica: We realize that this project only scratches the surface of what DSM can do — particularly in terms of automatically-generated code and SCSS samples — but that said, we know from this exercise how simple it is to use DSM’s code generation capabilities for other, more web-style-intensive projects, and we’re looking forward to making the most of that as requirements dictate. As a lab, we’ve really been focusing on how our UX team can expand our own coding skill sets and just work more collaboratively with developers in general, which naturally leads to everyone focusing more on working under atomic design principles. It’s a great way for each of us to learn bite-sized pieces of each other’s specialties, and to have a common mental model when starting from scratch on new projects. And since our team all uses Sketch in generating assets for new projects, DSM’s integration with Craft makes for an ideal tool for translating design into usable code.
How we did it
Jessica: We knew we only had two days to devote to this project, so we started with an asset inventory of all things Solaria Labs: our website, document templates, logos/icons, print artifacts, social profiles, etc. Then we took the opportunity to examine each item, standardize things like colors, fonts, and visual patterns, and discuss and change the things we noticed weren’t working so well in the field.
Kate: This actually took the bulk of our two-day timebox, and it was the real collaborative work: honest talk about what we already had, making decisions as a team, and thinking in an architectural, scalable manner — even down to making sure our house fonts worked for our team members who were using older Windows PCs. Until now, we hadn’t had the opportunity to have these discussions, so we wanted to spend as much of our available time on that as possible.
Jessica: And that’s why DSM ended up being such an awesome tool — we could spend more time actually making artifacts and standards and less time cataloguing them, because using DSM means the catalog is largely auto-generated. We still had to give careful consideration to balancing what items could be publicly available and what needed to be protected — basically, our rule of thumb was “could someone use this item to impersonate or otherwise harm us?” — but once we assembled all our artifacts, we dropped them either into DSM or Confluence, and annotated with usage guidelines. This process only took us about half a day!
Kate: Then came the best part: socializing the new design patterns with the rest of the lab staff. Everyone loves a contest, so we challenged the team to update their email signatures with the new standard, and send us a note as proof. The winner received a sweet model DeLorean (actually, it was a re-gift of our own prize for being the winner of the lab hackathon!). And who wouldn’t want a DeLorean, even a toy-sized one?
What we liked, what we didn’t
Kate: One of the goals of this exercise was to proof-test the Sketch/Craft/DSM workflow for generating design patterns on the fly, and we weren’t disappointed; the seamless integration of these tools made working a breeze. Plus, on the human side, it really enabled collaboration: Our UX team was able to work together, talking in the same room, but simultaneously working on different pieces of the project on our laptops.
Jessica: Having less implementation stuff to worry about made for an unexpected teambuilding opportunity, too! The speed at which we were able to work meant we were able to take the time to have the really valuable human discussions. (I remember the “old days” when manually documenting a design system took months!) The only real stumbling block was setting up a combination of publicly and privately accessible resources in a way that was the least disruptive or confusing to the lab at large. Ideally, we’d like to password-protect artifacts from within DSM — InVision, if you’re reading, what do you think about getting this in your backlog?
Kate: We’re really looking forward to having this in the wild for a little while and gathering some feedback about how it could be easier for the lab to use. Plus, we’re also excited about building out another DSM instance for something that starts with a website (such as our Dwellbeing home-maintenance platform), rather than starting from off-Web assets, which is more the case with the Solaria brand.
What can you learn from our project?
Jessica: A design system is never overkill! Even if you’re a two-person design team — or a two-person company — making decisions about brand identity and implementation patterns early on can make things a whole lot easier as you scale. If nothing else, you don’t have to end up asking your whole team to change their email signatures!
Kate: Consistency in how you present yourself is one of the most underrated — but most straightforward— ways to boost your brand. Never underestimate how consistent branding, visual design and language patterns can build trust, elevate your company’s message, and reach more customers!
