Scaling from MVP

to operational platform

71% ↓

Cut visitor check-in time from 3.5 to 1 minute

Cut visitor check-in time
from 3.5 to 1 minute

Cut visitor check-in time from 3.5 to 1 minute

1st pass

SOC 2 Type II audit
passed

SOC 2 Type II audit passed

1 → 3

Facilities supported
No redesign required

Facilities supported
No redesign required

Facilities supported
No redesign required

Domain

Security
WorkTech
B2B SaaS
VMS

Security,WorkTech, B2B SaaS, VMS

Team

Product Owner
Project Manager
Developers
QA specialist
Product Designer (me)

Product Owner, Project Manager, Developers, QA specialist, Product Designer (me)

Operational roles

Background Check Officer
Security Manager
Gate Guard
Sponsor

Background Check Officer, Security Manager, Gate Guard, Sponsor

Visitor types

Personal
Contractor
Subcontractor
Internal

Personal, Contractor, Subcontractor, Internal

What I did

Workflow analysis
Information architecture
Key product design
Design system
Test planning

Workflow analysis , Information architecture, Key product design, Design system , Test planning

Context

We were building a modern Visitor Management System (VMS) for managing visitors, access, security checks, and on-site entry. The MVP started with a simple use case: managing personal visitors.

Before: one generic visitor experience

Before: one generic visitor page

After: the experience adapts to the visitor type + operational role

After: adaptable by user type visitor page

Problem

The original experience treated all visitors essentially the same. But contractors, subcontractors, and internal employees required different information, verification steps, and permissions. One generic flow could no longer support the growing complexity.

The product needed to evolve from one generic visitor workflow to experiences shaped by visitor type and operational role.

The MVP no longer matched how
the operation worked.

From one visitor type to four

From one visitor type
to four

One visit, multiple operational roles

One visit,
multiple operational roles

Research

I mapped the existing workflows and interviewed stakeholders to understand how different roles and visitor types moved through the process.

What the research revealed:

1. Different roles own
different steps

Security teams, sponsors and front desk teams interact with the same visit at different stages

2. Visitor types require different information & verification

Personal visitors need basic details,
while contractors & subcontractors require extra data and checks

1. Different roles own different
steps

Security teams, sponsors and front desk teams
interact with the same visit at different stages

2. Visitor types require different information & verification

A personal visitor doesn't require the same
data or checks as a contractor or subcontractor

3. A visit is a state-based process

Invitation → verification → approval →
arrival → check-in

3. A visit is a state-based
process

Invitation → verification → approval → arrival → check-in

I mapped the existing workflows and interviewed stakeholders to understand where the MVP no longer matched the operational process. This revealed two distinct dimensions:

1. Different roles own
different steps

Security teams, sponsors and front desk
teams interact with the same visit
at different stages

2. Visitor types require different information & verification

A personal visitor doesn't require the same
data or checks as a contractor
or subcontractor

3. A visit is a state-based
process

Invitation → verification → approval →
arrival → check-in

These findings shaped the design model: visitor type determines the information and workflow, while operational role determines the actions and access.

These findings shaped the design model: visitor type determines
the information and workflow, while operational role determines
the actions and access.

These findings shaped the design model: visitor type determines the information and workflow, while operational role determines the actions and access.

Current-state workflow

Current-state workflow

Design Solutions

Identify the right visitor

Security Managers couldn't distinguish different visitor workflows from the dashboard.

I made visitor type, project, sponsor and verification status visible and filterable. This allowed users to identify the right workflow before opening the visitor.

By showing only the information required for each visitor type, the new flow reduced unnecessary fields and steps.

Collect only what’s relevant

Different visitor types required different information, but the MVP used the same invitation flow for everyone.

Different visitor types required different information, but the MVP used the same invitation flow
for everyone.

I created a dynamic invitation flow that adapts to the selected visitor type and reveals only the information required for that workflow. So users don’t have to scan / complete fields that don’t apply to their visitor, making it faster and easier to complete.

Make visitor management scalable

Managing visitors one by one becomes inefficient when teams need to onboard multiple people at once. So I introduced bulk visitor creation via CSV alongside
the individual invitation flow.

Managing visitors one by one becomes inefficient when teams need to onboard multiple people at once. So I introduced bulk visitor creation via CSV alongside the individual invitation flow.

That is important because teams can onboard multiple visitors in one step instead
of repeating the same workflow.

That is important because teams can onboard multiple visitors in one step instead of repeating the same workflow.

Supporting the four visitor types

As the product expanded, visitors were no longer one homogeneous group. Each visitor type has different information, status and verification requirements.

I designed the Visitor Details experience to surface the right information for each type while keeping all visitors within one consistent model.

This allowed the product to scale from a simple personal-visitor MVP
to a system that supported more complex operational workflows.
This allowed the product to scale from a simple personal-visitor MVP to a system that supported more complex operational workflows.

Design validation

Before rollout, the redesigned flows were tested with security staff through the Product Owner. The feedback confirmed that the role-specific structure matched how teams actually work and pointed to two concrete refinements.

So I reworked the filters on the Visitors Dashboard and adjusted the detail cards for Background Check Officer
to better fit his day-to-day workflow.

So I reworked the filters on the Visitors Dashboard and adjusted
the detail cards for Background Check Officer to better fit his
day-to-day workflow.

Results

Six months after rollout, we noticed significant improvements in both security performance and operational efficiency:

71% ↓

Cut visitor check-in time from 3.5 to 1 minute

Cut visitor check-in time
from 3.5 to 1 minute

Cut visitor check-in time from 3.5 to 1 minute

1st pass

SOC 2 Type II audit
passed

SOC 2 Type II audit passed

SOC 2 Type II audit passed

1 → 3

Facilities supported
No redesign required

Facilities supported
No redesign required

Lessons & learnings

This project taught me that scaling a product isn’t about adding complexity, but about creating clarity. I learned how essential it is to design for the specific needs of different security roles, and how much the underlying data model shapes the overall experience.

Most of all, it reminded me again why my work matters and why I enjoy it: turning high-stakes problems into solutions that people trust and rely on every day.

next / Restructuring the transaction model

next / Restructuring
the transaction model