lvl360, USA
Designing a dual-sided facilities management enterprise platform for buyers and service providers
Product Design
5 months
Context
lvl360 is a US-based facilities management and real estate services platform.
The product aimed to reduce waste and inefficiency in how large organizations procure and manage facilities services.
The platform aimed to serve two primary users:
Buyers (corporations managing facilities)
Service providers (vendors delivering services)
The same company could act as a buyer for some services and a vendor for others. This made role clarity critical.
My role and scope
I worked as the lead product designer on a pre-launch MVP.
I collaborated closely with the founder and stakeholders.
My responsibilities included:
Defining the information architecture
Designing end-to-end flows for buyers and service providers
Structuring dashboards and creating project workflows
Ensuring role clarity across the system
I designed the system logic and flow, from onboarding to daily use.
How I approached the problem
I treated lvl360 as one system with two perspectives, not two separate products.
Before designing screens, I mapped:
User roles
Shared objects
Role-specific tasks
The key question was: “What stays the same across roles, and what must change?”
Key system insight
The most complex requirement was:
The same company could be both a buyer and a service provider.
This meant:
Role could not be fixed at the account level
Permissions had to be contextual, not global
The UI had to signal role clearly without duplicating the product
Information architecture
I defined a shared system structure with role-specific views.
Core entities included:
Company Profile
Project Workflow
Dashboard
Messaging
These entities were created for both buyers and service providers, but behaved differently based on role.
Buyer-side flows
Buyers could use the platform for:
Gaining portfolio-level visibility
Initiating and managing projects and service requests
Tracking project progress over time
Communicating within the context of ongoing work
The project flow was designed to:
Reduce setup friction
Make project state visible
Keep procurement actions auditable
Service provider-side flows
Service providers could use the platform for:
Monitoring operational performance
Presenting relevant organizational information
Responding to incoming project requests
Managing ongoing engagements
The system needed to support both reactive work (responding to RFPs) and proactive work (initiating projects).
Key design decisions
1. One system, role-aware views
Instead of building two separate products, I designed:
A shared backbone
Role-specific behavior
This reduced duplication and kept data consistent.
2. Dashboards designed for action, not reporting
Dashboards were structured to:
Surface what needs attention
Reflect role-specific priorities
Avoid vanity metrics
The goal was faster decisions, not just visibility.
3. Projects as the core organizing unit
Everything in the system connected back to projects:
Messages
Metrics
Requests
Decisions
This reduced cognitive load and made the system easier to reason about.
Outcome
This work formed the foundation of a pre-launch MVP.
Positive stakeholder feedback, especially around:
Clarity of roles
End-to-end project flows
System coherence across buyers and service providers
Reflection
This project strengthened how I think about role-based systems.
It showed me that many enterprise problems are not usability issues, but alignment issues between people, data, and authority.
Designing lvl360 pushed me to think beyond screens and toward system behavior over time.
