Driving Capture Through Native Mobile Design

Trello’s Inbox feature set out to solve a deceptively simple problem: before users can organize anything, they have to capture it. Before Inbox, capturing an idea meant deciding which list and board it belonged on. These extra steps, although small, added enough friction that users frequently turned to other apps instead.

I led mobile design and strategy for Inbox across a multi-phase rollout, working closely with the web team to deliver a cohesive experience while making deliberate, platform-specific decisions that would elevate and clarify the user experience.

Card creation in Inbox

Cards added to Inbox appear at the top of the list, the opposite of how cards behave on boards. On web, the card creation input was positioned at the top of Inbox to match the card position. On mobile, however, I wanted card creation to stay within easy reach while also looking distinct from card creation on the board.

I designed a persistent text input anchored near the bottom of the screen that floated on top of the content. It kept content input close to the on-screen keyboard while still setting it apart visually from card creation on a board. The goal wasn’t just a different UI element, it was helping users understand that Inbox works differently.

This portable component would also serve as the base for a quick add tile we would add to the Boards/Home screen, making it flexible and reusable.

Quick add, widgets, and more

The mobile apps had a unique opportunity to unlock card creation outside of Inbox: widgets, voice, and share sheet integrations were all surfaces I saw potential in for driving faster capture.

I designed a quick add tile accessible from within the app and a home screen widget, both giving users ways to capture content in as few taps as possible. I also redesigned the share sheet experience to default incoming content to Inbox, significantly speeding up the process of adding cards from websites or other apps. For even faster capture, I added Siri integrations so users could add content hands-free.

Quick add became a primary driver for content creation. 11% of users who create cards on mobile are active Inbox widget users — a strong signal of how much our users value quick capture.

Organizing cards in boards

On web, Inbox displays alongside boards, making drag-and-drop a natural way to move content between them. On mobile, each surface is its own dedicated view, so replicating that pattern directly wasn’t feasible or appropriate.

Rather than copying the web pattern verbatim, I created multi-select, which not only sped up card management, but provided a unique toolset for users looking to manage multiple cards at once. Users could select many cards at once and either archive them or move them to a board. This feature also provided a more accessible management option for users who could not drag cards.

As we rolled out multi-select, I noticed a gap: users organizing just one or two cards still had to tap into a card to move it, adding unnecessary steps. We had an existing pattern on boards that let users drag cards to a hot zone to archive them. I expanded that logic to include moving a card or adding it to Planner. Dragging to a hot zone launches a bottom sheet where users can confirm the details, giving them speed without losing visibility or control.

Keeping the design system current across phases

With each phase of Inbox, it was important to ensure that new patterns were reflected in the mobile design system, both for user familiarity and to speed up development. Standard mobile components were used first to stay consistent with navigation and other core surfaces across the app, and custom components were used where needed (such as cards).

In some cases, new components needed to be created or existing ones expanded to fit a new use case. As the sole owner of the Trello Mobile design system, I tracked changes to existing components through a change management process and shared weekly summaries across the organization; giving the mobile development team visibility into what had shifted and keeping the broader org informed of our work.

Having a shared design system created a shared language between design and development. We all understood what components were, what they were supposed to do, and their limitations. I worked with developers to establish naming conventions for colors and icons, and documented component behavior so those references were easy to find and reuse. For new components introduced in a project, I created detailed annotations that moved from the project file to the design system, so context traveled with the work.

Because the design system reflects what’s shipped in code, I made a deliberate choice to add new components only after a phase was fully released to avoid documentation that would need to be reworked as designs evolved from concept to code. This kept the system trustworthy: a reliable reference for what actually existed in the app at every stage.

Creating alignment

Keeping leadership aligned on why mobile needed its own solutions was as important as the design work itself. I recorded weekly progress updates and presented our vision for each phase alongside project management and the mobile development team, making the case that cohesion comes from shared outcomes, not identical interactions.

Alignment with the web team mattered just as much. I kept the web designer and PM in our mobile working sessions and proactively flagged changes as they happened, so important functionality never felt like it was missing on either platform at any phase of the rollout.

Results

As we released functionality to test groups (and eventually all users), data and user feedback made it clear that intentional deviation, when it’s rooted in behavior, created clarity rather than confusion.

Inbox became a cornerstone feature for the product. Mobile users engaged with Inbox at a higher rate than on web, reflecting how well the platform-specific approach served users’ capture needs.

Staying aligned on goals rather than specific implementations meant the experiences felt consistent across platforms while still making sense for each one. This approach shaped work on future projects, too. I carried forward what I learned about cross-team documentation and communication, and kept the web team involved in mobile working sessions from the start.