Feedback Loops: Designing for Behavior Change

Trello had spent a year building personal productivity features, but the features weren’t creating the behavior change we needed. The problem wasn’t any individual surface, it was that nothing connected them together making it harder for users to discover and engage with new features.

I led a cross-discipline group to explore the opportunity, facilitated the discussion, and turned what we learned into a framework that shaped how the team approached feature work and discovery across multiple work streams.

Reframing the opportunity

The initial instinct across the team was to solve for engagement by building something new: a rewards mechanism, a streak system, or both. These ideas had proven successful for other apps and streaks, in particular, felt like an obvious answer given how widely they’re used to build user habits.

Something about this direction didn’t sit right with me, and I wanted to understand why before the team committed to it. I did some research examining how streak mechanics actually work in practice: rather than reinforcing the underlying goal, these types of features tend to shift motivation toward streak maintenance. When users break their streak, the friction of restarting is often enough to push them out of the app entirely. The engagement number goes up, but for the wrong reasons. I wrote a post and recorded a detailed walkthrough to share these findings with the team, making the case that we had a system problem, not a feature gap.

That post reframed the real opportunity and shifted the conversation away from which feature to ship next and toward how to create a system that reinforces user behavior at each step and drives users naturally forward.

Mapping the opportunity to the core loop

Before designing the workshop, I needed a concrete structure the team could pressure-test ideas against. I anchored the work to Trello’s core loop: Capture → Organize → Done. Each transition in that loop was a moment where users could either continue or drop off. Our opportunity was to make those transitions more rewarding and obviously connect to the next step without disrupting the ways users already worked.

Designing the workshop

I designed a cross-functional working session with designers, project managers, and engineers that had three objectives: establish a shared definition of the problem, explore what we wanted users to discover and why, and align on enough confidence to take next steps. I set the agenda, facilitated the discussion, and captured outcomes.

What
Help users reach their goals through non-intrusive, but high impact feedback using concepts like matching law, quantified self, and highlighting achievement to reinforce behavior.

Why
Coaching and reinforcing behavior loops can increase the value users experience in Trello and help them discover new personal productivity workflows.

How
Using in app messaging and personalized data to help users quantify their achievements and share their success.

So what?
→ Reinforce behaviors that drive our metrics.
→ Build value in Trello by helping users feel organized, productive and accomplished.

From there, participants mapped ideas to each stage of the core loop, finding connections between user need and feature opportunity. After 90 minutes, we closed by assessing confidence and blockers. The confidence was high across the room. The blockers were practical: roadmap fit and research gaps, not disagreement about the problem itself.

Turning the workshop into a reusable framework

Talking about an opportunity in workshops isn’t enough to change how a team works. I turned our discussions into a documented framework focused on driving and reinforcing behavior through each step of the core loop. I built a toolkit to make it usable by anyone on the team: a FigJam template; a Confluence guide with prompts for exploring discovery, feedback, and next steps; and a recorded walkthrough to help teams make their first working session with the framework impactful. The goal was to make it evergreen: as useful six months later as it was on day one.

Example of mapping out what a user is trying to achieve and mapping those objectives to existing features in the app. If a step is missing in the journey, it can prompt teams to discuss how that gap could be filled (e.g.: if there is not an easy way to mark content as done, how could we address that?). With this framework, we assume all user actions move through the core flow of Capture, Organize, and Done.
After mapping out the Journey we can fill in details that help users get to each step in the apps. The framework helps teams explore where there could be gaps between features/steps that could be filled with discovery moments, automations, or intuitive suggestions based on a users most likely action.

A system that traveled

The Feedback Loops framing started surfacing organically across the org: in Planner vision work, evergreen discovery strategy, personal boards exploration, and early AI agents thinking. Teams that hadn’t been in the original session were using the language and the mental model because colleagues had brought it with them.

That happened because we had built a shared way of thinking about the system, not just a document. The framework was grounded in understanding the user journey and behavior so it transferred across different product surfaces and team contexts in ways a feature-level solution never would have.

I received feedback from leadership who saw an opportunity to take the conversation beyond Trello to other teams across Atlassian who were thinking about similar engagement challenges. Not to land on the same solution, but to build a shared understanding of how feedback and reinforcement could tell a more cohesive story across products.

Results

The Feedback Loops framework became the foundation for how the team thought about discovery and engagement across the product. It directly informed the onboarding and discovery work I designed and led afterward, which drove up to a 56% increase in Inbox views.

More than any specific outcome, the framework shifted something about how we worked: we stopped asking what feature to build and started asking what behavior we were trying to support, and why. That question traveled further than any single project could have.

Working across disciplines to build the framework made it easier for others to adopt and understand. In hindsight, I’d want to go further to identifying owners across disciplines who could champion it within their own teams long term, rather than relying on organic spread from participants.