Thinking in Systems
A strategic redesign for mid-sized businesses scaling with multiple entities. The system simplifies roles, permissions, and navigation—bringing clarity, control, and efficiency to daily operations.
Meet Jordan Blake
Jordan is the Regional Franchise Director at Mobility City, overseeing multiple locations across regions. He is moderately tech-savvy and open to new solutions but prefers minimal disruption to existing operations.
With high decision-making authority, he plays a key role in platform evaluations, pricing conversations, and scaling strategies. His main objective is to assess whether Method’s multi-entity platform can simplify franchise management and boost efficiency—while carefully considering the potential complexity and cost involved.
Meet Michelle Ramirez
Michelle is the Operations Manager at Mobility City, overseeing day-to-day operations across several franchise locations. She is confident with software tools and plays a central role in setting up entities, managing user access, and configuring permissions in Method’s multi-entity environment.
Her top priorities are clarity and control—ensuring the system remains organized, flexible, and scalable as the business continues to grow.
Role
AI Product Designer
Service
UX Strategy
Deliverables
AI Website Prototype
Prototype
Overview
Managing growth across multiple business units is never simple. As Method’s clients grew more complex, our existing multi-entity model fell short for businesses managing multiple brands, teams, or locations. At the same time, our partner Intuit launched its own multi-entity solution for QuickBooks users — prompting a strategic shift across the ecosystem.
This created a key opportunity for Method to align with Intuit, attract mid-sized clients, and evolve into a more scalable platform.
As the AI Product Designer, I was tasked with rethinking the admin experience from the ground up. The goal was to lay the foundation for a multi-entity framework that could meet the operational needs of our users, support future growth, and solidify Method’s place within the QuickBooks ecosystem.
Discovery
To reimagine how admins manage multiple entities, I first needed to understand how they were navigating the current system. Using a design thinking approach, I conducted stakeholder interviews, audited the existing setup, and mapped out the end-to-end journey.
What surfaced were clear patterns of friction. Setup relied heavily on the Support team, with a 17-step internal process triggered only after users were informally assessed through unrelated touchpoints. Even after activation, admins faced challenges with visibility, permissions, and understanding how to manage their entity structure effectively.
These pain points revealed a deeper opportunity: beyond new features, Method needed a more intuitive and scalable way to help users discover, qualify for, and manage multi-entity experiences from day one — without relying on support as a gatekeeper.
01
Barriers to Adoption
Despite growing interest in multi-entity, adoption was limited by a system that was never designed to scale in this way. Through journey mapping, interviews, and system audits, we uncovered critical barriers—ranging from hidden setup processes to permission confusion—that made the experience feel inaccessible and inconsistent for end users.
1.1 - Setup & Qualification
Activating multi-entity was never a self-serve experience. Instead, users typically stumbled into eligibility through unrelated conversations with the Sales, Support, or Professional Services team. If users seemed like a potential fit, the Support team would direct them to their success manager for a pre-qualification assessment. If they met the criteria, Support would then initiate a 17-step backend process to enable multi-entity on their account.
The lack of visibility into this path made it feel exclusive, unpredictable, and dependent on manual intervention — all of which created friction and slowed down adoption.
1.2 - Onboarding & Configuration
While the Support team was available during setup, the overall experience lacked intuitiveness. There was no structured onboarding flow, and the interface offered limited functionality to help admins understand how to properly configure their accounts.
The concept of entity and sub-entity relationships felt vague and underdeveloped, making it hard for users to see how the system mapped to their real-world business structures. This disconnect made the onboarding experience feel incomplete and overly reliant on external guidance.
1.3 - Permission Management
Once more users were added to a multi-entity account, managing their access across entities quickly became a repetitive and manual task. Permissions didn’t carry over between entities, so admins had to recreate roles and access settings for each one individually.
There was no centralized place to view or manage user permissions across the account, which made oversight difficult and time-consuming. These gaps introduced unnecessary complexity, especially for admins managing multiple teams or locations at once.
1.4 - Navigation & Usability
Navigating between sub-entities felt clunky and disconnected. Users had to jump between external login links rather than using a seamless toggle or in-platform switcher. Important account details were often hidden behind subtle UI elements, like sub-entity names that didn’t appear clickable or offer any visual feedback.
Even core actions like adding a new user or sub-entity were wrapped in vague calls to action, with inconsistent terminology that left admins second-guessing what each button would do. These usability issues created avoidable friction in what should have been simple, everyday tasks.
02
Design Direction
With the core challenges uncovered, the goal was to simplify the multi-entity experience without sacrificing control. The design focused on helping users confidently explore, activate, and manage their structure with minimal friction.
While the ideal state leaned toward self-serve setup, we accounted for real-world constraints. Because activation is permanent and inherently complex, the Support team would continue guiding users through the initial stages. The experience was shaped to include clearer touchpoints, more intuitive flows, and the flexibility needed to support both decision-makers and daily operators.
Tools that brought
strategy to life
Figma: Flow Mapping &
UI Design
Cursor: AI-Assisted Coding
GitHub: Version Control
Vercel: Live Prototype Hosting
03
User Personas
To design a solution that truly met user needs, I focused on two primary personas central to the multi-entity experience. One represented the strategic decision-maker responsible for evaluating and adopting new tools.
The other captured the day-to-day operator managing the system post-setup. These personas helped frame the design challenges, define success from both ends of the journey, and guide the features we prioritized.
04
User Journeys
With Jordan and Michelle defined, I mapped their end-to-end journeys to uncover how each interacted with the platform — from initial discovery to day-to-day operations. These flows helped break down the experience into actionable stages and informed the user stories that would guide the prototype.
By tracing their thoughts, frustrations, and goals across each step, we clarified what mattered most to each persona and uncovered opportunities to streamline the experience for both strategic and operational users.
05
The Prototype
The prototype brought the strategy and journeys to life through a focused set of flows designed for both decision-makers and day-to-day admins. From self-guided qualification to role and entity control, the experience aimed to simplify complexity while giving users the flexibility they need to scale.
Each flow was built to reduce friction, improve clarity, and deliver a foundation for scalable operations.
5.1 - Smart Qualification Flow
Who it’s for: Jordan
What it does: Guides users through a lightweight self-assessment to determine if multi-entity is a fit, before contacting Sales or Support.
Why it matters: Reduces reliance on the Support team, gives users clarity upfront, and builds trust in the process.
5.2 - Sub-Entity Creation
Who it’s for: Michelle
What it does: Allows admins to create sub-entities within a clean, structured UI.
Why it matters: Helps admins mirror their real-world organization and set a scalable foundation.
5.3 - Entity Details View
Who it’s for: Michelle
What it does: Displays key insights about a specific sub-entity, including revenue, outstanding invoices, team members, and contact details.
Why it matters: Helps admins quickly understand the health and activity of each entity, reducing the need to navigate across multiple tools or request updates manually.
5.4 - Group Management
Who it’s for: Michelle
What it does: Enables grouping of entities and applying shared roles/settings.
Why it matters: Saves time and reduces human error when managing multiple locations or teams.
5.5 - Roles & Permissions
Who it’s for: Michelle
What it does: Streamlines role assignment and permission management across entities.
Why it matters: Addresses a top pain point from the current system — manual, repetitive setup.
06
Strategic Impact
With no live metrics available at this early stage, the prototype proved instrumental in aligning teams around a shared vision.
By leveraging AI-driven design and prototyping, I uncovered four major experience gaps, reduced ambiguity around entity management flows, and established a clear blueprint for development. The journey maps and flows are now referenced internally as a model for future platform redesigns.
Potential next steps include user testing and phased rollout planning. Validating the prototype with real admins and franchise leads would surface usability gaps, while integration planning with the Support team would help streamline activation.
From there, analytics could be layered in to monitor entity usage, adoption barriers, and permission efficiency at scale.
