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

HIPAA audit passed
on first attempt

Achieved first-pass HIPAA audit compliance

1 →3

1 → 3

Facilities supported
No redesign required

The system scaled from one
facility to three

Facilities supported. No redesign required

Domain

Security
WorkTech
B2B SaaS
VMS

Security, WorkTech, B2B SaaS, VMS

Team

Product Owner
Project Manager
Developers
QA
Product Designer (me)

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

Key roles

Background Check Officer
Security Manager
Gate Guard

Background Check Officer, Security Manager, Gate Guard

What I did

Workflow analysis
Information architecture
Key product design
Design system
Test planning

Market research, Personas, Key product design, Design system

Context

We were building a modern Visitor Management System (VMS) integrated with access control, security systems, and internal administrative tools. The initial MVP supported personal visits, while all other visitor flows were still handled through emails, spreadsheets, and phone calls.

As the product evolved, we moved to the next phase: expanding the system to support the full operational complexity.

Problem

Stakeholder interviews revealed that security personnel needed to manage contractors, subcontractors, internal employees and the more complex workflows tied to each group. With the introduction of commercial visitors, the existing flows broke.

My goal was to redesign the core visitor experience to support scalable, role-specific workflows.

Research

Direct user access was restricted, so research ran through two channels. The Product Owner conducted interviews with the three roles who run daily security operations. In parallel, I analyzed the existing email- and spreadsheet-based workflows the team relied on before the system — the clearest record of how visitor management actually worked, and where it broke.

Working from both, I synthesized the findings into four distinct visitor types, each with different metadata, risk levels, and verification logic:

  • Personal — simple one-off guests

  • Contractor — vendors hired by the base

  • Subcontractor — vendors hired by contractors

  • Internal — employees from the facility

Direct user access was restricted, so research ran through two channels. The Product Owner conducted interviews with the three roles who run daily security operations. In parallel, I analyzed the existing email- and spreadsheet-based workflows the team relied on before the system — the clearest record of how visitor management actually worked, and where it broke.

Working from both, I synthesized the findings into four distinct visitor types, each with different metadata, risk levels, and verification logic:

  • Personal — simple one-off guests

  • Contractor — vendors hired by the base

  • Subcontractor — vendors hired by contractors

  • Internal — employees from the facility

End-to-end happy path across Sponsor, Security Manager, BCO and Gate Guard workflows

End-to-end happy path across Sponsor, Security Manager, BCO and Gate Guard workflows

End-to-end happy path

Role-driven hierarchy

Requirements analysis

Design Solutions

The invitation flow starts on the Visitors Dashboard, where a Security Manager creates a new visit.

Now it supports four visitor types, surfaces essential metadata (category, project, sponsor group, RSVP, BG status), and introduces structured filters designed for real SM workflows.

The Create Invite page evolved into a structured two-column layout that separates invitation details from visitor information. The form now adapts dynamically to different visitor types, showing only the relevant fields.

The Create Invite page evolved into a structured two-column layout that separates invitation details from visitor information. The form now adapts dynamically to differant visitor types, showing only the relevant fields.

The new layout reduces cognitive load, minimizes errors, making the workflow significantly faster and more accurate.

The screens below illustrate how Visitor Details adapt across different system statuses, each with context-appropriate actions for Security Manager.

The main difference between visitor types are:

  • Personal visitors require only a simple identity overview,

  • Contractors and Subcontractors display additional metadata including company information, project assignments, and parent-company relationships.

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.

Results

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

6 months after rollout, we noticed 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

HIPAA audit passed
on first attempt

Achieved first-pass HIPAA audit compliance

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 / Reducing drop-off at step one

next /
Reducing drop-off at step one