Trello had recently pivoted toward personal productivity, adding a range of new features aimed at individual work rather than project management. The problem was that users had no way to understand this shift. The existing onboarding experience was built around a team-focused model and assumed most people would arrive through a work context. In practice, users were landing on empty screens with no guidance which hindered our new user retention.
Existing users weren’t faring much better; new features like Inbox lacked the context needed to explain their value. Without understanding what Inbox had to offer over a board, most users were ignoring Inbox. Early data showed Inbox adoption was low before we invested in discovery.
I led the strategy and design for new user onboarding across mobile, owning the experience from early exploration through experimentation and iteration.
Finding the right approach
Rather than treating new and existing users as separate problems, I wanted to build a single framework that could serve both, one that used existing surfaces and patterns instead of bespoke, one-time UI that users would never encounter again.
I started with an intentionally low-lift phase, introducing empty states with character illustrations on the two main feature screens, Boards and Inbox, to give users just enough context to take a first step. Empty state content was grounded in the core loop of personal productivity: capture, organize, and get stuff done.
On Boards, each element of that loop was reflected in the empty state messaging. On Inbox, the focus narrowed to capture and privacy — specifically, that content in Inbox is visible only to the user. Knowing that content in Inbox was always private is one of the primary differentiators of Inbox over Boards, especially for enterprise or business users.
This small change drove an increase in new feature discovery simply by giving users context rather than a blank screen. That signal gave me confidence to push further.
Running an experiment to learn
The next question was whether providing starter content alongside the empty states would drive even stronger discovery. I also wanted to resolve a strategic question about where to land new users when they first opened the app. Based on our data and user behavior, I believed we should start new users on a board, as understanding newer features like Inbox required a baseline familiarity with boards, lists, and cards. Leadership felt strongly that Inbox should come first, given that it was our most recent launch and central to the product strategy.
Rather than debating it, my mobile PM partner and I proposed running a controlled experiment. This kept us moving and ensured the decision would be grounded in user behavior rather than internal preference.
We built three experiences: one that started users on a board with starter content, one that started them in Inbox with starter content, and a control using the existing empty state. Working with content strategy, we created surface-specific starter cards designed to help users understand what each surface was for. Regardless of which version a user landed in, they had access to both surfaces, so no user missed out on either part of the product.
The data came back clearly in favor of the control. Starter content provided guidance, but it also created a situation where users felt that they needed to manage the starter content on these surfaces. This friction outweighed its usefulness. The empty state, it turned out, gave users just enough context without getting in their way. Rather than pushing further on starter content, we used that finding to double down on the approach that was already working.
Behavior-driven discovery
While the experiment was running, I focused on making the broader discovery experience smarter. I used TipKit on iOS and our existing in-app messaging patterns on Android to deliver contextual tips based on user behavior, surfacing relevant information at the moment it was most useful. This gave us a repeatable mechanism for introducing new features to existing users without engineering new onboarding each time a feature shipped.
For example, a tip promoting the Inbox widget would only appear after a user had added three or more cards in a single session through Quick Add, a signal that they were already a frequent capture user who might benefit from faster access.
I also looked for opportunities to make features easier to discover through the UI itself rather than explicit messaging. Small changes like adding a card count to the Quick Add tile and temporary badges to tab navigation helped users explore at their own pace without constant interruptions.
Results
The empty state approach drove up to a 56% increase in Inbox views across iOS and Android, directly supporting Trello’s broader personal productivity engagement goals. Discovery work ultimately became part of how the team approached every new feature launch, rather than a one-time investment.
The experiment was just as valuable for what it ruled out as for what it confirmed. Having a clear answer meant we could move forward with confidence, and the framework we built gave us a foundation to keep iterating as the product continued to evolve.