Velocity: Designing a scalable team and workspace system for a fast-growing AI startup
Velocity Teams is a systems-heavy SaaS project exploring how team onboarding, shared workspaces, roles, and billing can scale from individual users to enterprise organisations.
Business context
Velocity was built for individual designers, with no concept of teams, shared workspaces, or organisational structure.
As usage expanded into agencies and enterprise environments, this gap became a blocker to growth. Supporting teams required rethinking onboarding, permissions, navigation, and billing as a coherent system rather than a set of isolated features..
My role:
I was the sole product designer on Velocity Teams, with end-to-end ownership across problem framing, systems design, and execution.
I defined the team model, onboarding flows, roles and permissions, information architecture, and core navigation patterns, working closely with product and engineering to align UX decisions with evolving business and pricing strategy.
The team:
I worked closely with the Head of Product and engineering throughout the project, using regular check-ins and reviews to align system design, technical feasibility, and evolving business requirements.
Timeline
Nov – Dec 2025
The project was designed and validated across this period and is currently in development, with ongoing iteration as engineering progresses.
“I want to be able to see everyones reports”
“How can I pay for everyone just one time”
“We need multiple users under one account”
Problem
User problem
Velocity was designed for individuals, leaving teams without shared workspaces, permissions, or clear ownership. As a result, collaboration was awkward and onboarding broke down as soon as more than one person was involved..
Business problem
The lack of shared workspaces, role-based access, and scalable billing blocked larger contracts, limited expansion within organisations, and made the product misaligned with how teams expect modern SaaS tools to work.
Approach & rationale
My approach prioritised defining the system before working on the UI. I focused on establishing clear mental models for teams, roles, and permissions early, ensuring onboarding, navigation, and billing could scale consistently as requirements evolved. Designing in flows and prototyping early helped surface edge cases and validate decisions before execution.
Research
User research & insight synthesis
I speak to Velocity users weekly through ongoing discovery and feedback sessions, which gave me a strong understanding of how the product was being used in real team environments.
As a team, we had already explored this space through opportunity–solution mapping. I revisited that work, grouped opportunities into clear themes, translated them into actionable problem statements, and defined the key jobs to be done. This ensured the system design was grounded in real user needs and aligned across product, design, and engineering.
Product research
I analysed established SaaS tools used by design and product teams, including Figma, Notion, Slack, and Google Workspace, to understand common mental models around team onboarding, workspace switching, roles, and permissions.
This research focused on identifying patterns users already expect when joining teams, switching contexts, and managing access, helping reduce cognitive load by aligning Velocity with familiar behaviours rather than inventing new ones.
System planning & information architecture
I mapped the information architecture for the workspace to understand how all the core areas fit together, including settings, billing, and member management, and how access changes by user role.
This allowed me to define clear permissions for Owners, Admins, and Members, and establish a solid structural foundation before moving into UI design.
User scenarios
Before designing the onboarding, workspace navigation, user profile, and admin areas, I wrote a set of detailed user scenarios to guide the work.
The system was complex, with different roles, access levels, and plans affecting how users moved through the product so using these scenarios allowed me to clearly understand each role and ensure navigation, access, and permissions adapted appropriately across plans before moving into UI design.
Design
The design translated the system definition into clear, role-based experiences across the product.
I’m showing two representative flows (owner/admin & member) to show the core access patterns, with other roles following the same structure through constrained or extended permissions.
Design details
Left navigation
Velocity previously had no global navigation, so I introduced a left-side navigation as a scalable foundation for teams, workspaces, and role-based access..
Team Space Switching
I designed team space switching as a dropdown to keep the left navigation lightweight and avoid visual clutter.
As users can belong to multiple spaces, the dropdown provides a fast, familiar way to switch contexts without overwhelming the primary navigation.
User profile
I designed the user profile as a pop-up modal to keep account details easily accessible without interrupting primary workflows.
Because profile settings are infrequent actions, this pattern keeps them out of the main navigation while remaining quick to access when needed.
Admin panel
I designed the admin panel as a secondary slide-in navigation to keep the main workspace visible while giving admins quick access to deeper settings.
This familiar SaaS pattern reduces context switching and page reloads, helping admin actions feel lightweight rather than disruptive.
Validation & iteration
I validated the designs using Velocity’s AI-simulated user testing, running 100 simulations per flow to surface friction and confusion early. To complement the simulation data, I also ran usability sessions with two users and combined these insights with internal team reviews.
The simulation results and human testing informed small but meaningful refinements, including clearer copy and reducing the onboarding flow by one full step. These changes improved success rates and time to success, while reducing misclicks and drop-off rates.
The improved results from two of the flows are shown in the accompanying image.
Design system
As many of the Teams features were newly introduced, I extended the system alongside the product work, adding new navigation patterns, popovers, inputs, and upgrade components so the product had the building blocks it needed to scale.
Impact (pre-launch)
This project laid the foundation for Velocity to support teams and enterprise customers for the first time.
From a product perspective, it introduced a scalable system for shared workspaces, roles, and permissions, removing a key blocker to team adoption and future growth.
From a delivery standpoint, defining the system upfront and validating key flows early allowed the team to move straight into development with confidence, reducing rework and ambiguity for engineering.
The work is now in build. Once live, I’ll track onboarding completion, time to first successful simulation, role-based navigation success, and team expansion within workspaces, and update this section with live metrics.
Reflection
This project reinforced that designing for teams is about getting the underlying systems right. When roles, permissions, and structure are clear, everything else becomes easier. When they aren’t, small ambiguities quickly add up.
If I had more time…
Test the experience with real teams once it’s live, to see how it holds up in day-to-day use and where edge cases appear.
Spend more time exploring onboarding and role changes as teams grow and evolve.
Refine micro-interactions once real usage data shows where people slow down or get stuck.
My key learnings:
Writing detailed user scenarios early was hugely helpful.
Getting the system clear early made it easier to design with confidence as requirements evolved.