Donut: Building Blocks

Background

What is Donut?

Donut is a culture operations platform with the goal of helping companies to operationalise practices that improve company culture. With Donut Onboarding, companies can build reusable templates of content (messages, tasks, polls) through Slack and email.

What was the impetus for this project?

I started working on this project about 3 months after Donut Onboarding publicly launched.

The most common question our CX team received was “Do you have ideas about what to include in my onboarding process?”. This led to the idea of giving users a library of onboarding content.

The team also realised that a content library could increase revenue:

1. Improving trial conversion. Our conversion was already solid: ~20% of customers who trialled the product converted, but we saw in FullStory and heard in interviews that users who started a trial and then ran away were often intimidated by the “blank page” of an empty template.
2. Increase revenue per customer. Our premium tier has usage based pricing - the more content our customers delivered with Donut and the more roles included, the more we charged. Giving them ideas could increase the amount of content per customer.
3. Convert “Starter” tier customers to Premium. We were also trying to push customers from our flat priced “starter” tier with a limited amount of onboarding content to the premium tier. Perhaps giving them a view of content they could include could encourage that.

Design Exploration

I kicked things off by facilitating a design sprint with 8 people (the 4 co-founders, myself, an engineer, head of marketing, and CX lead). By the end of the sprint (the end of the week), the goal was to have a product direction we were reasonably confident in.

We settled on a set of key questions to try and answer with our prototype on Day 1:

1. What scale of best practices are people looking for - whole templates, modular blocks, individual message guidance?
2. How would users want to explore best practices - proactively? Only while building a culture workflow to add to it? When and how should we surface them?
3. What kind of content are users interested in? What about use cases besides onboarding?
4. Does this improve product engagement during the trial period?

After mapping out the main workflows we were interested in - how users trial the product, and how they build their content after starting to pay for it - plus lightning demos of other products for inspiration, we each made solution sketches. We discussed and upvoted favourite ideas to settle on elements to include in a rapid prototype.

I created a prototype incorporating the most popular ideas (where compatible) and drafted a research plan while other people recruited users to do 1 hour qualitative research sessions with. We found 7:

• 4 prospective customers - users from the onboarding waitlist who hadn’t trialled the product yet
• 3 existing customers - including 1 power user, who already used the product for onboarding

Findings

• The library effectively prompted ideas. For both new and existing users - a lot of “oh, I didn’t think of that!” comments during testing. Users were most interested in:
  • Software tips, eg for people new to Slack
  • Benefits reminders
  • Preboarding reminders (eg to assign and set up desk, send a pre-start survey, etc)
  • Role-specific content
• Smaller > larger units of content. Onboarding is personal, so users were unlikely to copy an entire template. The more content it contained, the more they’d have to edit it. Even within a “best practice”, rather than adding the whole thing, users want choice to add individual pieces, especially to control dates.
• Proactively looking for content? Maybe if I had time. Users doubted they’d find time to look for templates proactively - they had a lot of other responsibilities. Also, with smaller units of content, they want to see them in the context of their template rather than in a separate page to know if they were adding too much.
• Interest in what other companies do was general, not specific. “I don't want Slack’s exact content, but I’d like to know what practices they do.”

Iteration

Based on the key findings, I reworked the designs over the next few days and did another round of testing to see what worked and didn’t.

Some of the decisions made:

• Prioritised a content sidebar over separate a library page
• Added the ability to add single messages from a Building Block with drag and drop (to allow easily adding to right date)
• Introduced the sidebar with an interactive step in the setup wizard
• For Starter Users with limited content, added an upgrade path via “locked” premium content in the sidebar as an experiment

Most of the feedback for this round of designs was positive - I made a few small changes, like interaction improvements to drag and drop, and we renamed the content from “modules” to “Building Blocks”.

Launch + Results

I worked closely with engineers as they built the feature to answer questions and give feedback on the interactions and animations. Because other projects were in progress and we needed to draft the best practices, we launched about 6 weeks after round 2 of the design, in early November.

While it was being built, I worked with the CEO and CPO to define our success metrics and make sure they were measured:

• Trial conversion rate
• Usage - % of users who used them, and usage by building block
• Average number of messages per user (including during trials)
• # of users who upgraded via premium content

Results

After the feature was out for a month excluding Thanksgiving Week, we saw some positive results. Overall, the feature was an effective driver for the goal of increasing usage and therefore revenue among premium customers:

• 37% increase in average messages for paying teams (~21 -> ~29)
• 60% increase in average messages for trial teams (~11 -> ~18)

However, it didn’t impact trials positively as we hoped.

• No change in conversion rate: steady at ~21%
• Only 2 users converted from starter to premium via the new funnel over that period

Although the feature didn’t drive starter to premium upgrades, we later decided to just scrap the starter tier because it wasn’t converting users at a higher rate, which was its goal to begin with.