LOTIQ · CASE STUDY 04
Built for the manager who can't be on-site
A mobile-first parking enforcement app for commercial property managers who run 3 to 4 lots at once and are rarely standing in any of them.
- Role
- Product designer
- Tools
- Figma · Lovable (React + Tailwind)
- Team
- Self-directed. My mentor, who built and launched LotIQ, provided the product brief. The design decisions were mine.
- Timeline
- April – June 2026
01 · CONTEXT
Who LotIQ is for
LotIQ is a camera-based parking enforcement product for small and mid-sized commercial lots. This case study is my own version of its app, designed from the founder's brief and my own research, without reference to the shipped app. Cafes, dental offices, and shops share one lot. Each tenant is promised parking for its customers. Non-customers take the spots anyway.
The app is for the property manager. They run 3 to 4 properties with 15 to 30 tenants each, and they are almost never in a lot. They check a phone between meetings.
02 · PROBLEM
What goes wrong today
The manager does not need a camera system. They need to run parking as a business problem, from a phone, across every property, with evidence they can show a tenant. Three needs go unmet by the tools that exist.
They need to see every property at once. Existing tools are built one lot at a time. A manager with 4 lots opens, exits, and re-enters each one. They need one screen that shows all of them, ranked by urgency.
They need to start the day in control, not in reaction. The first look at the phone is often before reaching any property. A live list of violations puts them in firefighting mode before they know whether anything is wrong. They need a summary first: what happened yesterday, and whether today looks normal.
They need evidence before acting, and a record after. Towing is a high-stakes call and tenants dispute it. Without a timestamped photo and a log, the manager has nothing to show. The record has to be made by the system, not typed in afterwards.
03 · PROCESS
How I worked
Research
I started from a one-page brief written by my mentor, who built and launched LotIQ. I audited the apps managers already use, Parkade and Reliant Parking among them. Both are built for residential lots and show one property at a time. I also interviewed a commercial property manager about how they handle parking and where it costs them time.
Persona and jobs
From the brief and the interview I created a persona, Michael Chen, and a jobs-to-be-done list for him: 6 functional jobs, 4 emotional, 3 social. A jobs-to-be-done list names what a person is trying to get done, in their own terms.
Design
I created the design system first: tokens for color, type, and spacing, plus a short set of rules drawn from the jobs list. One example: a tow is irreversible, so the app never lets it happen in a single tap. Then I prototyped in Figma and built the working app in Lovable.
04 · SOLUTION
What I designed
Every property on one screen. The Properties tab is a hub. One card per lot, with live status, tenant count, camera status, and a color for urgency. The manager reads across all lots in one pass.
Job: “I want a single-screen view of all lots and active issues so I can triage my day in under 2 minutes.”
A morning brief instead of a live list. Home opens on a summary: yesterday's flagged, resolved, and towed counts, today's active count, and the last camera scan. The incident list is one tap away, not first.
Job: “When I'm off-site for hours, I want to feel like nothing is slipping through the cracks.”
Evidence on every incident. Incident detail leads with plate, spot, tenant, and timestamp. Below that sit the photo and the camera source, logged by the system, not typed by the manager. Three actions are pinned to the bottom: Dismiss, Warn, Tow.
Job: “When a tenant disputes a tow, I want an audit trail I can share immediately.”
Setup in steps, with the price inside it. The app does nothing until zones, spots, tenants, cameras, and a towing partner are configured. Onboarding walks through that in 12 steps. The plan price is calculated from the manager's own lot size and exit count and shown before they commit. They can run the math against an enforcer's salary themselves.
05 · OUTCOME
Where it stands
4 tabs
Home, Incidents, Cameras, Properties. The whole daily loop.
12 steps
Onboarding, from account to pricing. The count is a hypothesis, not a tested number.
Under 2 minutes
The morning triage the jobs list asks for, and what the Home screen is built to hit. A target, not a measurement.
The prototype covers onboarding through daily enforcement. No property manager has used it yet.
What I'd test first
The onboarding. 12 steps is a guess. The right number is whatever does not lose a manager before the first lot goes live. Then the home screen bet: that a summary beats a live list.
What I learned
The hard part was not building the system. It was refusing to simplify it for the wrong reasons. Shorter setup would have made an app that feels easy to start and is useless to run. The job was to make the complexity navigable, not to pretend it was not there.