Chili Piper

Product Design

Design System

2019

Context

Filling out a contact form to get a product demo is so last decade. What you get is a couple of auto-generated emails and, if you’re lucky, someone reaches out — but only after days have passed.

What a drag, huh? Not for Chili Piper, who turned it into a profitable business. The recipe? Qualify the leads, connect them with the right salespeople, and schedule meetings within a click.

The next step for the company was to scale its secret sauce into a productivity suite for revenue teams.

I designed a few MVPs, all while creating and maintaining a design system for a team of designers, developers, and managers.

Concierge

I started by introducing a free version and a set of new features to Chili Piper's beloved Concierge.

It replaces a call-to-action button with an interactive widget that shows different contact options based on who's visiting the website.

Instant crush

First impression counts. And it’s best when short and sweet. So the onboarding has just enough steps that it doesn’t feel like a chore.

The first step of the onboarding process. The main part of the screen contains a few options to customize the widget’s design. On the right side of the screen, there’s a live preview of that widget.

The second step of the onboarding process. The main part of the screen contains the option to customize the widget’s welcome message and contact options. On the right side of the screen, there’s a live preview of that widget.

Everyone's welcome

When used to their full potential, lead qualification criteria can get tangled. To show what's happening behind the scenes, I designed a visual rule builder.

The “Rules” subpage. It contains a full-page canvas with a diagram that shows what goes into the algorithm.

Don't repeat yourself

Never retype the same meeting details. With Chili Piper, you can save them as a template to automate your scheduling process without losing the personal touch.

A “Meeting Type” subpage titled “Product demo”. It contains a form to customize the event details like title, location, and description.

Who's there?

While the goal is to instantly connect with the most valuable prospects, that's not always feasible. Nobody's picking the phone late at night or when in the middle of another pitch.

The “Prospect Log” that is a table of all the prospects who have interacted with the widget. It shows what contact options they were presented with, if the salesperson was available, and what was the outcome of that interaction.

Calendar

Meetings play a huge role in salespeople's daily routine. Yet, their calendar feels disconnected from their workflow. Let's change that.

Clock in, clock out

Meetings, tasks, time blocks — they're all here, so you can realistically plan your day.

A calendar view of the user’s week. On the left side, there’s the month preview, the option to view other user’s calendar, and the user’s calendars filter. The main part of the screen contains a weekly view of the user’s schedule. There are about 4 meetings and/or tasks per day scheduled.

2 drawers to add a new event or task. They both contain a few inputs to set parameters like template, title, and time duration.

Write that down!

When the conversation is flowing, it's hard to capture all the relevant details. It shouldn't be with Meeting Notes, though.

Set an agenda for each meeting type and get your sales team on the same page. And if you wanna make sure you got everything right, send the meeting recap with just a click.

The “Meeting Notes” feature. The main part of the screen contains the meeting agenda, where some bullet points have input fields to save information from the meeting. On the right side of the screen, there’s a sidebar that contains all the information on the prospect’s company that’s available in the system.

An email composer with a summary of the meeting generated from the meeting notes.

Ready for business trips

Chili Piper also helps salespeople at in-person conferences. It gives the managers a bird's-eye view of the team's schedule while they have access to the meeting details on-the-go.

A calendar view of the team’s schedule for a 3-day conference. On the left side, there are a couple of filters. The main part of the screen contains a 3-day view of all the team’s meetings. There’s like more than a dozen scheduled for each day, some happening at the same time. One of these events is clicked and on the right side of the screen, there’s a drawer that shows that event’s details.

Design system

To talk about the design system, let's go back to the point where none of the products were "done".

It's been a few weeks since we (I and two other designers) started working with Chili Piper. After producing a ton of diagrams and wireframes, we were excited to move on to the high fidelity phase.

But with that advancement, a new challenge arose: how to design the whole product suite in a consistent design language, with each of us focusing on separate parts?

A page from the design system documentation. It contains information about “Why use a design system?” and “What are our design principles?”.

We thought that a primitive library where everyone could dump the tokens and components they were using would be enough. It seemed intuitive, but got messy after a few days. (Surprise, I know.)

To embrace the chaos, we decided that it'll be best if just one of us was responsible for maintaining the design system. And that someone was me.

A page from the design system documentation. It contains information about the usage and variants of 2 colors: orange and keppel.

Shipping the MVPs was still my priority, and I was working on that full-time — except of Wednesdays. On Wednesdays, I was focused solely on the system.

A page from the design system documentation. It contains information about the anatomy, specs, and possible states of a button component.

I organized the list of ideas, improvements, and bugs into a kanban board in Notion, so that everyone could track my progress.

(I'm such a sucker for kanban boards.)

I also set up a Slack channel where I shared updates about the new changes to the system.

A page from the design system documentation. It contains information about the content guidelines based on an inline alert component.

Inside the design team, we met every Friday to discuss what we liked and disliked about working with the system that week. And if we had enough time on our hands, we conducted peer-to-peer reviews of our source files.

A page from the design system documentation. It contains information about some components (like input fields) having a different background based on the background that they’re placed on.

The developers mirrored our components, tokens, and patterns in a Storybook library. That let them write front-end code in no time, and we could launch the suite into beta on schedule.

A diagram showing how the project’s files are has been grouped. The “Library” group has files names: Typography, Layout, Native Elements, Styles, and Components. The “Source of Truth” group has only one file, Documentation. The last group “Product Files” has an unspecified number of files, and they are named after each product from the suite.

Even more benefits of the design system became clear once more stakeholders joined the process. In the old way, they had to wait for the designers to visualize their ideas.

Now, they could use the library to outline their concepts without reinventing the design language.

Credits

Shout-out to the people who also worked on this project.

Damian Redecki

Product Design Leadership

Michał Nowakowski

Product Design