Instacart’s Lead Product Designer on Creating A Design System
Jordan Staniscia tried — and claims he failed — multiple times to create a single, re-usable design system for all of Instacart’s visuals, icons and interactions over many years at the company.
We at Initialized Capital frequently get asked about how startups should create style guides that define the brand identities of their companies, and so we asked Staniscia to share some lessons with portfolio companies this week.
So, first off, what is a “design system”?
Staniscia prefers to use the word “system” because it implies that this is something re-usable; it’s a framework. Design systems are, in Josh Clark of Big Medium’s words, “containers for institutional knowledge.”
It sits between the design and engineering teams as a common language that helps them stay on the same page. Otherwise, designers will end up in a situation where they have to explain their product vision over and over again and engineers will have a hard time ensuring they’re building an efficient system.
Design systems are not experimental. They are backed by research on how users behave and what they want. Staniscia says once you have solidified successful UI paradigms, you want to document them and stick to them.
However, design systems are built to evolve over time. No design system ever stays the same for a very long time. Something that’s obvious to someone in 2017 isn’t the same thing that might have been obvious to someone in 1995. Designers and companies are trying to strike a moving target that sits between ease-of-use and newer levels of abstraction that technology continually introduces.
A design system can have many pieces including:
— A style guide: This is the visual or brand identity of the firm. Let’s say, if you were working at Target, they would include guidelines on not using photography of people not smiling. Or the guidelines would include certain kinds of language to use. Design systems expand upon this; they bring many elements into play that are systematically thought out for re-usability.
— Component library: These are the individual, re-usable pieces that co-exist and interact with each other within the larger system.
— Defined interactions: These are specific user experiences that repeat across the entire organization or product — such as the way that navigational transitions, search or animations work.
Building Instacart’s Design System (Attempts #1, 2 and 3….)
Staniscia tried three different times in 2015, 2016 and 2017 to create a design system that Instacart engineers and designers could re-use in building and rolling out products.
Instacart, a pun-friendly company, called its first design system “Beetstrap.”
2015: In the beginning, Staniscia was one of two designers at the company. At that point, they weren’t sure of how Instacart was going to evolve. They didn’t know which UI ideas were going to stick around which ones were going to get trashed on a weekly basis. The team was experimenting and user-testing everything.
In January of 2015, an engineer approached Staniscia and asked, “Wouldn’t it be great to make a component library of all our styles?”
So they created — har, har — a system called “Beetstrap.”
It contained Instacart’s colors, buttons, styles and most importantly, the company’s icon set. Up until then, they had been using an off-the-shelf icon set.
Attempt #1 at building a design system in 2015 included basic buttons, colors and styles.
Creating their own icon set was a big win, because they previously had been using symbols that were a bit off. The delivery icon used to be an 18-wheeler truck icon. (No Instacart delivery has ever been completed using a freight truck.)
So big success, right?
Wrong. Engineers didn’t know the icons were in the component library. They also didn’t build everything necessary for the system. They had no plan for how people could add to it.
It was also desktop-centric, and there was no plan for mobile.
But the biggest error was that they hadn’t communicated the existence of the library to the rest of the team.
“We expected to release it into the world and poof — people would start using it,” Staniscia said.
2016: So they tried again a year later in January of 2016. They now had five designers and many more engineers. By that point, Instacart’s growth had picked up and the company was getting better informed on how customers behaved.
Growth, of course, presented new challenges — namely the problem of getting lots of different designers to collaborate on the same product and not have it look disjointed from one experience to the next.
Having learned from the previous attempt in 2015, Staniscia tried again. His team built guides for all platforms with instructions about buttons, navigation and illustration.
There was some improvement in process; designers were better at sticking to the rules and they were creating more cohesive mock-ups.
But because they had put everything in Sketch, a designer-centric tool, engineers couldn’t really see or understand their work. They wouldn’t be able to see the larger picture and there was very little documentation. A lot of this information was just living inside the design team’s heads.
Why had the process fundamentally failed both times?
Ultimately, it was about trust. When designer requests feel scattered, engineers want to understand what they are doing and that they are doing it for a bigger purpose or reason. But because engineers weren’t involved in creating these design guidelines, they weren’t bought into them.
This time, Instacart catalogued everything it had built before into a 90-page document covering screenshots, components, interactions and colors.
2017: With two attempts behind them, Instacart tried again in 2017. Now they had seven designers, a new marketing design team and a lot of engineers.
This time, they catalogued everything they had built before into a 90-page document covering screenshots, components, interactions, and colors. Out of that process, came a wish list of what they later wanted to build. They then decided on foundational elements like spacing, type and color.
The third step was heavily considering what Staniscia called their main “use case” — or their main content from the beginning of a user’s experience. They realized item cards displaying each grocery item were the main content on almost every page of the site. So they re-thought the structure of these components, to make them easier to display and interact with. Instacart’s main grid, for example, is designed to the exact width of these item cards.
After those foundational steps, they set an initial three-month deadline for the design team for an initial release. They split designers into three functional groups covering cards & containers, forms and feedback and navigation and actions. They created a before-and-after view to make sure their user flows felt consistent and natural.
To make sure they had buy-in across the entire company, they made sure to create many socializing opportunities to intermingle both designers and engineers. There was a gallery day, where the team printed out before-and-after versions of core flows, got a bunch of wine and cheese and invited the entire organization to come by, look at everything and give feedback.
In total, it was three months of design work with one meeting a week and a big wine and cheese day at the end to get to the initial release. Then came the engineering.
Lessons for other teams?
— You need to think in a multi-platform way from the beginning. Instacart was slow to adapt to mobile.
— Build for your use case.
— Plan for changes.
— Make sure that your design and engineering teams are communicating productively so that your work actually gets adopted across the organization.