Appcues Design System

2018 marked the growth of the Appcues team from 40 to 75, the start of its mobile product, and a company rebrand.  It was time to kick design into high gear and take the company from fledgling startup to forward-thinking industry leader.  Developing a design system would help set the direction and pace for the organization to scale.

My goal was to create, maintain and evangelize a design system for Appcues. What that entailed—pixel-perfect specs with scalable and nested components in our component library, applying brand look and feel, scouting opportunities in the app to use better UI/UX patterns, policing the system, working with devs to build and document it, and encouraging its use.

May 2018 - present
file org

THE BEAUTY OF DESIGN SYSTEMS

When you start on a project with approved, consistent and scalable solutions and stop reinventing the wheel each time for basic page designs, you have way more time for the more complex user needs.

When you start on a project with approved, consistent and scalable solutions and stop reinventing the wheel each time for basic page designs, you have way more time for the more complex user needs.

THE PROBLEM

Features had been built fast and loose.

You should easily be able to picture our issue—there were haphazard styles floating throughout the product—different dialog menus on every screen, off-brand and custom colored buttons, strange menu and form behaviors…no consistent design, and tons of custom code. This is completely normal for the majority of organizations that start with small teams of engineers quickly building features for product-market fit. But normal doesn't always mean good, and as a user experience product, we wanted to start early rethinking how we were doing things and ensure that we were applying the best practices to deliver the best product to our users.

GOALS

UI / UX consistency

Speed up workflow

Build for scale

CHALLENGES

Planning and prioritization
Balancing the design system as its own project amidst the rest of our workload...how would we prioritize building components for that system vs designing for a particular product area? Especially as a small start-up?

2. Designing for multiple building experiences
Appcues users can build content in three main places: a web app dashboard, a chrome extension Builder for web, and a new mobile Builder.  Each have different building paradigms and UI, some light and some dark. How could we design shared components that met the unique requirements for each product area?

2. Designing for multiple building experiences
Appcues users can build content in three main places: a web app dashboard, a chrome extension Builder for web, and a new mobile Builder.  Each have different building paradigms and UI, some light and some dark. How could we design shared components that met the unique requirements for each product area?

2. Designing for multiple building experiences
Appcues users can build content in three main places: a web app dashboard, a chrome extension Builder for web, and a new mobile Builder.  Each have different building paradigms and UI, some light and some dark. How could we design shared components that met the unique requirements for each product area?

2. Designing for multiple building experiences
Appcues users can build content in three main places: a web app dashboard, a chrome extension Builder for web, and a new mobile Builder.  Each have different building paradigms and UI, some light and some dark. How could we design shared components that met the unique requirements for each product area?

Designing across platforms
Appcues users can build content in three main places: a web app dashboard, a chrome extension Builder for web, and a new mobile Builder. Each have different building paradigms and UI. How could we design shared components that met the unique requirements for each product area?

2. Designing for multiple building experiences
Appcues users can build content in three main places: a web app dashboard, a chrome extension Builder for web, and a new mobile Builder.  Each have different building paradigms and UI, some light and some dark. How could we design shared components that met the unique requirements for each product area?

2. Designing for multiple building experiences
Appcues users can build content in three main places: a web app dashboard, a chrome extension Builder for web, and a new mobile Builder.  Each have different building paradigms and UI, some light and some dark. How could we design shared components that met the unique requirements for each product area?

2. Designing for multiple building experiences
Appcues users can build content in three main places: a web app dashboard, a chrome extension Builder for web, and a new mobile Builder.  Each have different building paradigms and UI, some light and some dark. How could we design shared components that met the unique requirements for each product area?

2. Designing for multiple building experiences
Appcues users can build content in three main places: a web app dashboard, a chrome extension Builder for web, and a new mobile Builder.  Each have different building paradigms and UI, some light and some dark. How could we design shared components that met the unique requirements for each product area?

Speccing end-user content
Appcues is a builder tool, meaning not only did we need to manage the specs of our own tool, but we needed to manage the specs of what users could create with our tool. How could we organize our end-user content in the same systematic way as our own interface?

3. End-user content needed its own specs
Appcues is a builder, meaning not only did we need to manage the specs of our own tool, but we needed to manage the specs of what users could create with our tool.  How could we organize our end-user content in the same systematic way as our own interface?

3. End-user content needed its own specs
Appcues is a builder, meaning not only did we need to manage the specs of our own tool, but we needed to manage the specs of what users could create with our tool.  How could we organize our end-user content in the same systematic way as our own interface?

3. End-user content needed its own specs
Appcues is a builder, meaning not only did we need to manage the specs of our own tool, but we needed to manage the specs of what users could create with our tool.  How could we organize our end-user content in the same systematic way as our own interface?

3. End-user content needed its own specs
Appcues is a builder, meaning not only did we need to manage the specs of our own tool, but we needed to manage the specs of what users could create with our tool.  How could we organize our end-user content in the same systematic way as our own interface?

Appcues rebrand

GREEN FIELDS

GREEN FIELDS

A company rebrand underscored the need for starting fresh.

A company rebrand occurring at the same time really underscored the need for starting fresh.

Appcues was getting a new coat of paint to make it more playful, warm and clean. This was perfect timing for us, since we could restyle our UI while we built our components.

THE NEW FOUNDATION

RESTARTING WITH ATOMIC DESIGN

Building with atomic design

Prior to beginning this work, Appcues had a very simple style guide with foundational elements like buttons, type styles, text fields, card content and some information archictecture loosely defined. It was a great starting point, but only covered a small subset of the product, and components were still disparate from each other rather than connected systematically.

We were all already familiar with robust systems like Carbon Design and Google Material, and like theirs, we wanted ours to be based on the principles of atomic design—the organizational scheme that breaks down pages in an app into smaller organisms, molecules, and atoms. 

Prior to beginning this work, Appcues had a very simple style guide, essentially a component library of foundational elements—buttons, type styles, text fields, card content—plus some information archictecture loosely defined.

It was a great starting point, but needed to be better organized, added to, and built for scale. Enter Brad Frost's atomic design—an approach to interfaces that mirrors nature, where complex organisms are comprised of simpler molecules, themselves comprised of even simpler atoms. In interfaces, organisms (i.e. tables) are made of molecules (i.e. a single row), which are an arrangment of atoms (i.e. a user avatar, a line of text, a button).  Designing with this organizaitonal scheme in mind allows your system to scale cohesively—you can swap out and update individual atoms, molecules, or organisms to create or change whole parts of the app within minutes.

Prior to beginning this work, Appcues had a very simple style guide, essentially a component library of foundational elements—buttons, type styles, text fields, card content—plus some information archictecture loosely defined.

It was a great starting point, but needed to be better organized, added to, and built for scale. Enter Brad Frost's atomic design—an approach to interfaces that mirrors nature, where complex organisms are comprised of simpler molecules, themselves comprised of even simpler atoms. In interfaces, organisms (i.e. tables) are made of molecules (i.e. a single row), which are an arrangment of atoms (i.e. a user avatar, a line of text, a button).  Designing with this organizaitonal scheme in mind allows your system to scale cohesively—you can swap out and update individual atoms, molecules, or organisms to create or change whole parts of the app within minutes.

atomic design

KICKOFF

RESTARTING WITH ATOMIC DESIGN

Assemble and map out components

We kicked off with a meeting between the product design team and a lead front-end engineer, Guru Mahendran, who was already bought in to the project. We drafted a rough list of components together and assigned them to categories like overall Style specs, Base elements, more complex Components, and overall Layouts. Initially, all of this was done in a spreadsheet, but we eventually migrated to a kanban board so that we could track each as a card along a design and dev cycle.

We kicked off with a meeting between the product design team and a lead front-end engineer already bought in and assigned to the work.  We were all already familiar with robust systems like Carbon Design and Google Material, and used those to draft a list of components. We organized them in a way that made sense for Appcues while staying true to the principles of atomic.

Meanwhile, I had already begun a new component library using the Google Material Theme Editor plugin for Sketch—essentially a large library with the neat ability to change color, font and icon families to theme the components for our app.

This was a great start just to get a tangible view of how components were organized and styled and to think of any new ones we may not have considered.  However, the library contained components and states that were simply irrelevant for us—like lots of Google Material cards clearly suited for mobile news feeds.  And even for the ones we did want to use, we still needed to do a lot of refinement to reflect our brand and functional requirements. 

So, instead of continuing to refine, cut from, and add to this plugin library, we started a new file and continued in Sketch. Until we discovered Figma...

Component list
Snapshot of an early spreadsheet draft of our component list and organization scheme.

PLANNING FILES

RESTARTING WITH ATOMIC DESIGN

Organizing by product domain

We also decided early to split our files by product domains to keep things tidy and files snappy. Our main set of components would live in Base UI and feed our three product domains: the Web App, Web Builder, and Mobile Builder. It was necessary that each domain would still be able to have its own components and layouts since each had separate workflows and design paradigms. The eventual goal was to have more shared design, especially between the web and mobile builders, but separate and shareable files made sense.

There was also the matter of handling our end-user content—the stuff that our users could build with our tools. That too made sense to keep in a separate file, which could then feed into the others, given that users could build content in all three product domains.  

We kicked off with a meeting between the product design team and a lead front-end engineer already bought in and assigned to the work.  We were all already familiar with robust systems like Carbon Design and Google Material, and used those to draft a list of components. We organized them in a way that made sense for Appcues while staying true to the principles of atomic.

Meanwhile, I had already begun a new component library using the Google Material Theme Editor plugin for Sketch—essentially a large library with the neat ability to change color, font and icon families to theme the components for our app.

This was a great start just to get a tangible view of how components were organized and styled and to think of any new ones we may not have considered.  However, the library contained components and states that were simply irrelevant for us—like lots of Google Material cards clearly suited for mobile news feeds.  And even for the ones we did want to use, we still needed to do a lot of refinement to reflect our brand and functional requirements. 

So, instead of continuing to refine, cut from, and add to this plugin library, we started a new file and continued in Sketch. Until we discovered Figma...

file org

FIRST STEPS

RESTARTING WITH ATOMIC DESIGN

A set of foundational components

I began a new component library in Sketch with the Google Material Theme Editor plugin that had been released a couple of months prior.  While initially helpful to get a lay of the land and experiment quickly with applying our color palette, it became clear that many of the components in the library were irrelevant to us and that the others would require a lot more refinement to reflect our brand and functional requirements. So, instead of continuing to refine, cut from, and add to this plugin library, we started a fresh file.

Our first set of components were core ones like buttons, text fields, and switches, our color palette, typography and a set of icons. This initial library obviously didn't cover all our needs, but allowed each designer to start using the new components, get a sense of their look and feel in mocks and naturally discover and fill in gaps with new components or suggested revisions. Design reviews and Slack conversations periodically brought us back together to agree upon and codify changes.

I began a new component library in Sketch with the Google Material Theme Editor plugin that had been released a couple of months prior.  While initially helpful to get a lay of the land and experiment quickly with applying our color palette, it became clear that many of the components in the library were irrelevant to us and that the others would require a lot more refinement to reflect our brand and functional requirements. So, instead of continuing to refine, cut from, and add to this plugin library, we started a fresh file.

Our first set of components were core ones like buttons, text fields, and switches, our color palette, typography and a set of icons. This initial library obviously didn't cover all our needs, but allowed each designer to start using the new components, get a sense of their look and feel in mocks and naturally discover and fill in gaps with new components or suggested revisions. Design reviews and Slack conversations periodically brought us back together to agree upon and codify changes.

We kicked off with a meeting between the product design team and a lead front-end engineer already bought in and assigned to the work.  We were all already familiar with robust systems like Carbon Design and Google Material, and used those to draft a list of components. We organized them in a way that made sense for Appcues while staying true to the principles of atomic.

Meanwhile, I had already begun a new component library using the Google Material Theme Editor plugin for Sketch—essentially a large library with the neat ability to change color, font and icon families to theme the components for our app.

This was a great start just to get a tangible view of how components were organized and styled and to think of any new ones we may not have considered.  However, the library contained components and states that were simply irrelevant for us—like lots of Google Material cards clearly suited for mobile news feeds.  And even for the ones we did want to use, we still needed to do a lot of refinement to reflect our brand and functional requirements. 

So, instead of continuing to refine, cut from, and add to this plugin library, we started a new file and continued in Sketch. Until we discovered Figma...

Early version style guide
Snapshot of an early spreadsheet draft of our component list and organization scheme.
figma

FIGMA TURBOCHARGE

Sketch became sluggish—we switched to Figma ❤️

Sketch has been the gold standard for years in interface design, and it does accommodate systems work with Symbols and Libraries. But as we added more screens and more symbols, the master files became sluggish. Simple things like setting overrides on symbol instances or adjusting type styles for alignment or color were slow and frustrating to navigate.

Figma was calling to us—for many reasons, like multi-player mode, commenting, native prototyping, price point, in-browser designing and native version control. But on top of the speed and tool consolidation, it just seemed especially suited to streamline systems work!

Though it meant respeccing everything in Figma, I gladly set aside time to rebuild our components.  And yes, it was worth it.  

Though it meant respeccing everything in Figma, I gladly set aside time to rebuild our components.

Though it meant respeccing everything in Figma, I gladly set aside time to rebuild our components.

Table design_design system demo
Library toggles
You can choose which libraries of components you wish to include in a file by simply toggling them on or off.  Clicking in to any one of them gives you a handy preview of what's included.
Component & overrides
Search for the component you need by name or by thumbnail, and override text with one click directly into the component. No need for special overrides!
Master component link
Use the “Go to Master Component” link, snapping you right to that component, whether in the same or different file, so you can make changes to the master, and continue along with your designing.
Component update
Figma notifies you when component updates are available, let’s you scroll through the changes, and choose either to update individual components or all into your file.

DOCUMENTATION

DOCUMENTATION

GREEN FIELDS

Without documentation, a design system is just a component library.

A company rebrand occurring at the same time really underscored the need for starting fresh.

We didn’t just make a Figma UI kit—we have live components documented in Designcu.es. While obviously still a far cry from the depth and breath of more robust systems, it still hits the basic notes. Anyone coming to Designcu.es can see our React components true to form and with available properties listed. 

We're still improving the documentation. We're planning for adding more examples of where components are used in the product, to include a search, and to write descriptions of each item. We want Designcu.es to be a resource for the entire Appcues organization rather than just developers.

IMPACT

RESTARTING WITH ATOMIC DESIGN

Faster designers. Faster devs. Happier users.

Designers are now able to grab components and whole pages to whip up prototypes on the fly. Developers can plug and play code that has been tested for functionality and behavior. Shortly after Designcu.es going live, our product manager, Jeff Vincent, was able to create a new reporting page for our platform using the design system all on his own during a two-day hackathon. With some quick final touches and linking up to data shortly after, he rolled it out as a Beta feature and got many cheers from customers who had been asking for that page for months.

Customers saw us not only releasing features faster, but noticed that the overall polish of the product was starting to shine through, and support tickets for UI-related bugginess steadily declined. All of us could finally turn more of our attention to what mattered most—solving the bigger customer needs for our product beyond discussing button colors and dialog sizes. (Disclaimer: those discussions are fun and still happen on occassion).

We kicked off with a meeting between the product design team and a lead front-end engineer already bought in and assigned to the work.  We were all already familiar with robust systems like Carbon Design and Google Material, and used those to draft a list of components. We organized them in a way that made sense for Appcues while staying true to the principles of atomic.

Meanwhile, I had already begun a new component library using the Google Material Theme Editor plugin for Sketch—essentially a large library with the neat ability to change color, font and icon families to theme the components for our app.

This was a great start just to get a tangible view of how components were organized and styled and to think of any new ones we may not have considered.  However, the library contained components and states that were simply irrelevant for us—like lots of Google Material cards clearly suited for mobile news feeds.  And even for the ones we did want to use, we still needed to do a lot of refinement to reflect our brand and functional requirements. 

So, instead of continuing to refine, cut from, and add to this plugin library, we started a new file and continued in Sketch. Until we discovered Figma...

A FINAL NOTE

Design systems are never done 😉

Almost every day, I contribute a little bit more. It doesn’t have to be big—it could be something small like fixing some erroneous padding or alignment or adding one more icon to the library. It could be larger, like working out a consistent page header design across the app. Point is—your design system is the backbone of your product, and like your product, it is never done evolving.

Digital footprints

Reach me at jmaggio27@gmail.com or on these other platforms.

Icon – LinkedIn
Icon – Instagram
Icon – Dribbble