Parq.ai

Enterprise fleet operations rarely follow one universal set of rules. Different clients operate across different locations, vendors, service agreements and operational conditions. As Parq.ai expanded, the product needed to support that variability without becoming fragmented or impossible to operate.

The challenge was not simply to design more screens. It was to make complex business logic understandable.

I worked closely with the Product Owner, Operations and Engineering to translate business and client requirements into usable product experiences.

Requirements typically arrived through working sessions, documents, videos and operational context gathered by the Product Owner from business stakeholders, clients and internal Operations teams. My responsibility was to understand the problem, structure the information, explore interaction models, design the experience in Figma and iterate with Product until the solution was ready for development.

The team operated in fast weekly cycles. Initial solutions were often developed within two to three days, leaving the remainder of the cycle for feedback and refinement.

Some design problems could not be solved by understanding the interface alone. Fleet operations were tied to physical spaces, vehicle movement and lot capacity.

For the Site Plans initiative, I structured infographic lot maps using approximate measurements to represent parking areas, lanes and operational zones. This connected the digital product with the physical environment where users actually worked.

The product brought together Fleet Management, Workflows, Work Orders, Tickets, Loads and Transportation, Lots, Vendors, SLAs, Pricing, Readiness, Automations and Administration around the asset and its operational history.

The point was not to expose users to the architecture. It was to preserve enough context for them to operate confidently across it.

Operational information related to a single asset could exist across different objects and processes. Users needed to understand not only each record, but how tickets, work orders and assets related to one another throughout an operational process.

I explored ways to make those relationships explicit and maintain context as users moved between operational records.

Operations could not rely on manually scanning large Work Order queues to identify every issue requiring attention.

The Exception Engine evaluated Work Order conditions, identified thresholds and generated actionable tickets with an ordered ownership path.

Within-threshold, approaching-threshold and breached states communicated urgency through green, yellow and red. Configurable triggers covered situations such as unassigned, stalled, aging or incomplete Work Orders, while the ownership sequence made clear who should act when an exception occurred.

Asset Readiness depended on client-specific logic that Operations could not see or modify without Engineering. The design direction expressed this logic as a natural-language rule.

The experience accounted for multiple conditions, optional warning states, conflicts, manual overrides, migrated rules and validation without asking administrators to think like programmers.

Previously, answering that question required moving through the Pricing database, identifying the activity and vendor, opening the SLA, finding the margin and calculating the final price manually.

The product supported three perspectives — client, lot and activity — and two pricing mental models: calculating a client price from vendor cost and margin, or working backward from a client price to internal cost.

Operational users did not simply need more data. They needed enough context to identify where attention was required and what action should follow.

Vendor health, turnaround time, rework rate, SLA compliance, downtime, cost trends and vendor comparisons helped turn performance data into operational decisions.

As the product evolved, the system needed to account for multi-tenancy, distributed ownership, partnerships, cross-client access, shared assets, permissions, possession, SLAs and audit trails.

This expanded the design problem from individual workflows to the foundations of a configurable enterprise SaaS platform.

As the platform expanded across modules and use cases, consistency became a product problem of its own.

I developed and maintained reusable interface patterns — tables, filters, cards, badges, statuses, navigation, forms, inputs, modals, empty states, alerts and tabs — to reduce reinvention, improve predictability and accelerate product delivery. The design system covered 7+ core product areas.

Design was not treated as a final deliverable. Solutions moved through Product feedback, refinement and implementation, with additional adjustments as operational needs evolved.

Parq.ai taught me that designing enterprise products is often less about simplifying the business itself and more about creating interfaces that let users operate that complexity with confidence.

Simple interfaces do not necessarily come from simple systems.

Some of the most important design work in Parq.ai involved understanding relationships, rules, exceptions, permissions and operational constraints that users should never have to interpret as technical complexity. My role was to preserve that capability while making the system understandable enough to operate.