From Solo to Shared — Designing Collaboration for a Data Platform

Giving teams the means to work together on data

Mammoth is a no-code platform for managing data journeys — connecting sources, transforming datasets, automating pipelines, and extracting insights. But it had been built around a single-user mental model. Every workflow was tied to one account. If a team needed to collaborate, they shared login credentials. There was no concept of workspaces, no way to invite a colleague, no roles to control access, and no structure to prevent work from colliding.

A platform built for one, used by many

Mammoth had no organisational backbone. Without projects, folders, or permissions, every dataset lived in the same flat space — and every user had access to everything or nothing. Teams needed a way to structure their work independently, protect what shouldn't be touched, and share what was ready. The platform offered none of that.

• No multi-user access — teams resorted to sharing credentials, creating security risks and eliminating any audit trail
• No visibility into how data was being used across an account — coordination happened entirely outside the tool

What was missing wasn't just access control — it was the structural layer that would let users pursue their own projects without disrupting shared ones. Projects, folder hierarchies, role-based permissions, and a way to manage plan feature coverage would give teams the gating and oversight they needed to collaborate with confidence rather than caution.

Two sources that made the gap concrete

Customer Success flagged the pattern first

The Customer Success Manager was fielding the same request repeatedly — users asking how to give a colleague access. There was no answer to give them. The frequency made the gap impossible to ignore: this wasn't an edge case, it was a basic expectation the product couldn't meet. CSM insights confirmed that teams were sharing credentials as a workaround, creating security risks and making it impossible for the platform to understand its actual user base.

User interviews named the structural pain points

Interviews with participants matched to Mammoth's two core personas went deeper than the access question. Three distinct pain points emerged: the inability to grant access at all, poor visibility into how data was being used across an account, and difficulty keeping datasets organised without any project or folder hierarchy. Interviews pointed toward differentiated roles, an improved hierarchy, and the ability to work on folders in isolation before sharing.

Alongside primary research, a review of established products with similar collaboration concerns — workspace-based tools handling shared data, role hierarchies, and tiered access — helped identify common patterns and conventions users already understood. This informed decisions around invitation flows, permission models, and settings architecture, grounding the design in familiar mental models rather than inventing from scratch.

Holding together competing definitions

Setting direction with competing pressures

The project had a clear objective but three competing pressures. Users needed teams to work together on data. The business saw collaboration as a vehicle for restructuring pricing — connecting multi-user access to new plan tiers. And the product was already overloaded with features, so adding collaboration couldn't just bolt on new functionality — it needed to use the new structure as an opportunity to simplify.

Mapping the structural problem

The existing structure was flat: one account, one user, all workflows in a single undifferentiated space. The target introduced a workspace layer where a single user account could belong to multiple workspaces, each with its own plan, billing, and invited users, with access scoped by role at both workspace and project level. This required mapping invitation flows, defining the account access schema, and designing the full workspace user flow.

Designing roles and permissions

At the workspace level, three roles were defined: Owner (full control including billing), Admin (user management without billing access), and Analyst (content access with no admin control). At the project level, a separate permission layer let members set whether an invited user could edit or only view — or mark a project as private, visible only to the workspace Owner and Admin. The key tension was making this feel lightweight for a two-person team while being robust enough for larger organisations.

Validating through usability testing

Before finalising designs, usability tests were conducted with both internal and external users. The core workspace model — switching between workspaces, inviting users, managing roles through settings — was intuitive and easy to follow. Minor areas for refinement were identified around onboarding touchpoints and role distinctions at the project level, and folded directly into iterations before handoff.

Navigating scope through constraints

The full vision was larger than what could ship in one phase. The work was structured into stages — starting with plans and settings infrastructure before tackling the core of the project: workspace navigation, invitation flows, and role assignment. What to defer and what to prioritise were decisions made deliberately and early, in collaboration with Product and Engineering.

Workspaces as the organising principle

Workspaces

A workspace model that gives teams a shared container for data workflows, scoped by plan and role. Users can belong to multiple workspaces, switch between them from the homepage, and create new ones through a guided setup flow — plan selection, payment, naming, and user invitation.

Settings & Management

A consolidated settings experience covering user management, plan and billing, data usage monitoring, and API key management — all scoped to the active workspace and accessible based on role. Data usage views were designed with monthly and yearly perspectives, allowing users to identify ingestion surges at specific intervals.

Invitation flows

Three distinct invitation paths — for new self-served users, new invited users, and existing users being added to a workspace — each designed to minimise friction and set clear expectations about what the user is joining. Each path was treated as a design surface in its own right, not bolted on.

Validated design, structured handoff

I left Mammoth before this project completed development, so impact is measured in design validation and structural groundwork — not shipped production metrics.

Usability tests confirmed the core workspace model was understood and easy to use. Minor refinements around onboarding touchpoints and role distinctions were iterated on and folded into the final handoff. A quantitative measurement framework had been defined — tracking average session length, workspace adoption conversion rate, and monthly active user growth — but the project hadn't reached production maturity for those metrics to be captured.

The project also produced organisational artefacts intended to outlast any single feature: a role and permission framework that subsequent features could build on, a workspace model that gave pricing and billing a structural foundation, and onboarding touchpoints designed to scale across the different entry points the platform now supported.

Designing for competing definitions

The deepest challenge wasn't any single design surface — it was holding together competing definitions of what "collaboration" meant. For users, it meant working on the same data without stepping on each other's toes. For the business, it meant a pricing architecture that could grow with team size. For engineering, it meant rearchitecting how workflows related to accounts without breaking existing setups. The workspace model was the structural answer that made satisfying all three possible.

The scope negotiation was the other defining aspect. The full vision was clear from the start. The discipline was in deciding what could wait without undermining what shipped first. Structuring the work into phases wasn't a fallback — it was the strategy that made shipping possible given the constraints. If there's one thing I'd approach differently, it's pushing harder on the quantitative measurement framework earlier in the project.