iLobby
ContractorOS
A compliance platform for facility managers, vendors, and the contractors on the ground.
- Role
- Lead Product Designer
- Timeline
- 6 months
- Team
- CTO · VP Engineering · PM · 4 Engineers
The problem
Compliance was breaking at the edges — on clipboards, in inboxes, on the warehouse floor.
Facility managers were responsible for keeping every vendor and contractor on-site compliant — insurance, training, safety certifications — but the tools they had were email threads, spreadsheets, and filing cabinets.
Vendors didn't know what was expired until they got turned away at the gate. Contractors showed up to sites they weren't cleared for. Managers spent hours every week chasing paperwork instead of running operations.
iLobby had the relationship with facility managers. We needed to build the product that matched.
of facilities hit compliance issues yearly
Gartner
of contractors working with expired credentials
Forrester
of contractors rely on phone as primary work device
Internal survey, n=70
Research
Three users. Three very different surfaces.
Early interviews made the shape of the problem clear: one product couldn't be one interface. The facility manager, the vendor, and the contractor on-site had almost nothing in common except the compliance record between them.
David
Facility ManagerRuns a large facility from his desk. Wants a dashboard: who's compliant, who's expiring, who's on-site today. Power user, desktop-first.
Arya
Service ProviderManages a crew of contractors for a vendor company. Lives between the office and the field. Needs to administer her team AND act as a contractor herself.
Mike
On-Site ContractorShows up at a facility with gloves on and a phone in his back pocket. Needs to prove he's cleared in under 30 seconds. Mobile-first, zero patience for friction.
How it came together
Process
Concept
Wireframes & flows
Research
Interviews & forms
Design
Three responsive UIs
Iterate
Beta & rebuild
Phase 01 · Concept
Wireframing the shape of the system before picking up a pixel.
Strategic wireframing
We started with low-fidelity wireframes across all three user surfaces at once. The goal wasn't to design screens — it was to find the objects and actions the system actually needed to support, before any interface decisions locked them in.
Every wireframe session included the PM and an engineer. If the flow didn't survive the engineering read, we rewrote it.
Artifact
User flow diagrams
Mapped the end-to-end path for each persona before touching visual design. These became the scaffolding for the rest of the work.
Artifact
Low-fi wireframes
Grayscale, no branding, no typography decisions. Just boxes and relationships. The point was to argue about the structure.
Phase 02 · Research & Flows
Talking to 100+ facility managers and contractors made the form problem unavoidable.
Compliance data lived in forms. Every facility wanted different forms. Every vendor had their own forms too. The question wasn't whether to support forms — it was how much flexibility to give people building them.
Form triage flow
How a contractor's submission gets routed, reviewed, and either cleared or kicked back for correction.
Form creation flow
Research methods
- · Semi-structured interviews
- · On-site observation
- · Industry reports (Gartner, Forrester)
- · Internal surveys
Sample size
Facility managers / Contractors
Phase 03 · Design
Three surfaces. One data model. A shared design language.
Admin Dashboard
Information-dense but navigable. At-a-glance compliance status, drill-down into any vendor or contractor, alerts for expiring credentials.
The three surfaces shared a data model, a component library, and a visual language — but the layouts, densities, and interaction patterns were tailored to the context of use.
Phase 04 · Iterate
Then we put it in front of real users. And rebuilt half of it.
Method 01
Heatmaps
Where people actually clicked versus where we thought they would.
Method 02
User interviews
Follow-up sessions with facility managers from the research phase, now using the actual product.
Method 03
First-click tests
For the form builder specifically. People either figured it out in one click or gave up in thirty seconds.
4 out of 5 users didn't want our custom form builder.
We'd spent weeks on a drag-and-drop form builder. It worked beautifully. Nobody wanted it. Facility managers didn't want to build forms — they wanted to pick one that already matched their industry and their insurer.
of vendors wanted a hybrid admin / contractor role
Beta research, n=40
wanted expirations tracked at the document level, not the form level
Beta research, n=40
The 74% stat validated Arya's existence — the hybrid role wasn't an edge case, it was the default. The 45% told us we'd modeled expirations on the wrong object entirely.
Outcome
What shipped.
of facilities hit compliance issues yearly
Gartner
of contractors working with expired credentials
Forrester
of contractors rely on phone as primary work device
Internal survey, n=70
- Three tailored surfaces: Admin (web + desktop), Vendor (web + mobile), Contractor (mobile-first)
- Document verification for insurance, licenses, and certifications
- Automated expiration tracking with document-level renewal alerts
- Compliance dashboards with search, filter, and audit-ready records
- Templated form and certificate library, with configurable review-and-approval workflows
- Hybrid vendor role — assign, delegate, and complete tasks in one flow
Reflection
The lesson I took from ContractorOS wasn't about forms or data models or any particular design decision.
It was this: we'd convinced ourselves users wanted flexibility. They wanted fewer decisions. Every hour we'd spent on the form builder was an hour we weren't spending on templates.
I think about that trade-off on every project now.