Trello

methods used
‍• customer interviews with enterprise organizations like Etsy,
• empathy mapping across four personas (Team Champion, Team Contributor, Personal User, Admin)
• jobs-to-be-done framework
• user journey mapping
• competitive UI analysis
• stakeholder workshops

I also presented directly to Mike Cannon-Brookes, Atlassian's CEO, to shift the product direction toward end-user needs instead of focusing my Enterprise work on admin-only or security features.

‍key insights
‍70% of participants didn't understand what workspaces were or how they functioned.

People were building workarounds like saving board links in Slack, maintaining spreadsheets of "where things live," asking around in meetings.

Product usage data showed how organizations had multiple or sometimes several workspaces with only a few members in each. People weren't choosing to be siloed within an , they just had no other option given they could not find these other workspaces.

When I mapped the jobs-to-be-done, three patterns showed up across each persona. Users wanted to:
1. Discover how others structured their work
2. Get access without friction
3. Understand what was happening across teams

From a competitive analysis perspective Trello was lacking since Notion, Monday, Wrike and others solved these jobs on day one.

‍design implication
‍Three things had to change:
1. Define what an "organization" actually means in Trello and give it structure that connects isolated workspaces
2. Build discovery so people can see what boards and workspaces exist across their org
3. Create request-to-join flows so users could initiatte access without waiting on external invites

scaling the object model
"Organizations" didn't exist before and workspaces were just isolated folders. So, the core systems work was scaling Trello's architecture from sporadic workspaces that contained boards into Organization > Workspace > Board.

The most logical way to form and retrofit the existing 500M user base into organizations was email domain grouping. This system automatically put everyone at @ibm.com into the "ibm.com" organization. However, multinational companies with country domains would fragment, acquisitions with alternate domains wouldn't unify, and contractors would technically be locked out of an organization view. To fix this, I roadmapped the needed features for admin capabilities to handle these cases while keeping my iteration, which covered 95% of cases, simple.

The constraint to this object model and permissions change was we couldn't force existing workspaces to become organization-visible since that would break trust with Trello's 500M users. The system had to support both legacy private workspaces and newly created or migrated org-visible ones simultaneously.

I designed a model where organizations became the container, mapped how permissions would cascade through each level, and solved for edge cases like:
• Now, how would users in multiple organizations (like a consultant at both IBM and Acme) navigate between them?
• Now, how would workspaces shared with external users (like an agency partner) appear and function?
• Now, how would boards shared with people outside the organization hierarchy inherit permissions (sometimes people share just one board with an external person, not the whole workspace. Where does that board live for the external person, and what can they do with it?)

‍permission architecture as platform foundation
Trello, already 10 years old when I began working on it, had workspace admins, board members, guests, direct board access.
What I had to figure out was, when adding organizations as a container, how do organization-level controls interact with all those existing permission types?

I worked with engineering to map how organization-level permissions would interact with Trello's existing permission model. For example:
• How would organization visibility settings affect someone who was already a workspace admin in one place but only a board member in another?
• How would organization membership differ from the existing guest/member distinction?

‍designing an organization view that could scale
The organization view needed to handle vastly different scales, whether 5 workspaces or 500. I explored multiple patterns: tile views that mimicked Trello's kanban cards, searchable list modals borrowing from Slack's channel search, and a cluster map visualization with workspaces as bubbles sized by activity.

The cluster map was visually ambitious and would have differentiated us from competitors. But it had fundamental scalability problems as rendering degraded beyond 200 workspaces, spatial algorithms needed constant tuning as organization structures changed, and the interaction model wasn't intuitive. I killed it.

The tile view turned out to be the right solution. It leveraged Trello's existing card mental model, which users already understood from boards. More importantly, tiles scaled predictably, especially with pagination patterns that kicked in at scale thresholds, lazy loading for performance, and density controls that let users adjust information hierarchy based on their needs.

The component architecture was reusable. Every future Enterprise feature that needed to display workspace collections (admin dashboards, search results, analytics) could build on these same tile primitives. These patterns gave us a foundation that could grow with organizations without requiring re-architecture.

‍why this mattered
‍This work repositioned Trello from "small team tool" to credible enterprise platform, which directly enabled us to compete for $100K+ deals we were losing to Notion and Monday.

The object model, permission architecture, and component patterns became the foundation every subsequent Enterprise feature built on from admin dashboards, organization-wide search, analytics, to compliance controls.

teaching through the UI, not documentation
‍When admins created workspaces, the workspace visibility dropdown didn't just list options, it explained what each one did right there. Pick "Organization" and you'd see: "This Workspace allows anyone at [organization name] to view and request to join it."

People learned how visibility worked while making the decision, not from help docs they'd never read.

I also designed animations for hover states that taught the hierarchy. Hover over a workspace tile and you'd see the boards inside it. This was critical since (a reminder!) 70% of users didn't understand that workspaces were containers for boards. The interaction itself explained the relationship; you didn't need to read about it.

‍tiles and visual cues for 5 workspaces or 500
I designed workspace tiles to handle different types of information, keeping the layout consistent with an icon, name, board count, and member count. Active workspaces got big sizes and I proposed that dying ones faded slowly. You could look at 50 tiles and immediately see which teams were actually working.

The grid went from 4 columns on desktop down to 1 on mobile, same components just responsive. Workspaces you were a part of showed up higher and lock icons indicated workspaces you had to request to access. All of my choices were visual shortcuts so a user could scan fast without reading every word.

‍making rejection feel temporary
‍The request-to-join modal could've felt like getting blocked. Instead I used friendly illustrations and wrote: "Sorry, you can't access {workspace name}...yet!" That "yet" mattered. It said this is temporary, not a dead end. The main button was "Request access," not "Go back." Push people forward, not backward. Empty states worked the same way. Empty organization view? Explain why it's empty, show admins how to fix it, give regular users a way to request. Turn confusion into action.

‍onboarding that shows, not tells
‍The multi-step onboarding walked people through one idea at a time. Illustrations showed what the organization view was; workspace cards for "everyone in one place," a zoomed-out view to show company structure, etc. The modals sat on top of the actual organization view so you learned in context, not in some abstract tutorial.

‍keeping it feeling like Trello
‍Everything stayed true to Trello's visual style: rounded corners, simple geometric illustrations, friendly typography and color! Workspace tiles looked like board cards. Colors extended Trello's palette without breaking from it. Enterprise upgraded workspaces feltl like Trello *fancified* in all gold.  

‍why this mattered
‍Good visual design made complicated systems feel simple (and fun)! Visibility settings taught themselves. Request flows kept people moving forward. The work proved you don't need to make things ugly or complicated to solve enterprise problems.

de-risking through targeted testing
‍I ran a final research round focused on execution, not concept validation:
• Could admins configure visibility correctly?
• Would users discover their organization view? Would they find it useful?
• Did users understand request flows?

Testing with enterprise customers revealed a few gaps:
• Admins didn't know visibility changes wouldn't auto-notify teams
• Users expected instant access instead of request-based
I redesigned based on what broke, roadmapping notification prompts to visibility settings and added confirmation screens to request flows with the specific workspaces' admin names and emails.

When engineering hit load limits, I rethought approaches, not just adjusted UIs.

‍defining success metrics upfront
‍I worked with product to define MVP scope and metrics before shipping. Success wasn't "people use it," it was: 25% of multi-workspace organizations adopt organization view within 6 months (proving demand), 15% of admins enable organization visibility within 6 months (proving willingness to use Enterprise controls). Metrics tied directly to whether the product repositioning was working.

‍iterative rollout
‍We shipped in two milestones.

Milestone 1 - Check if users even wanted to see their organization inside Trello: organization structure and discovery.  

Milestone 2 - Create an organization map and enable access/request-to-join

Future roadmapped features: extended admin controls, searching workspaces, organization-wide billing and analytics, dying or dead workspaces, and more.

What I Prioritized
end-user discovery over admin features
Leadership wanted to focus my time on admin controls like provisioning, security, compliance, even though the focus of my work was to tackle churn and market share.

They weren't really even thinking about organizational collaboration.
I negotiated with my PM and presented directly to Atlassian's CEO to shift direction toward end-user discovery first. If users couldn't find and access work, admin controls would just manage empty organizations.

‍research with real enterprise customers
Product leadership assumed they knew what enterprises needed. I pushed to interview actual customers like Etsy instead of designing from internal opinions. This added weeks to the timeline but surfaced the critical insight that 70% of users didn't understand workspaces, which changed our entire approach.

What I Said No To
designing for every organizational structure upfront
‍I identified the most common use cases: organizations with 5-20 workspaces and 99.5% of user emails in just 1 organization (they would sign in with their other logins if need be), and designed explicitly for those. Extreme edge cases (someone in 2+ organizations, workspaces with 10,000 boards) got documented as technical specs for engineering to handle with pagination and performance fallbacks. I designed the system to scale predictably, not to be perfect on day one.

‍fully designed secondary features
‍Advanced filters, sorting options, and analytics views all mattered but weren't critical to proving the core value. I created rough wireframes and specs for these and handed them to engineering to implement functionally. My design time went entirely to organization structure, the organization tile view, and request-to-join flows. Secondary features shipped looking basic, but they shipped. We could polish them after validating the first two milestones of organization-wide discovery.