A deeper view of the system behind the screens
Roles, rules, workflows and product decisions.
This documentation was created after parts of the project had already moved into high-fidelity UI. I revisited the work to clarify the product logic, record confirmed requirements, reconstruct missing context and improve future design and handoff decisions.
Product understanding
Two portals support different parts of the vehicle lifecycle.
Product configuration
Build Your Own
Vehicle tracking
Yard management
Master data
Portal integration is not presented as confirmed.
New Delivery
Vehicle PDI
Retail delivery
Service Center
Warranty claims
Portal names, major modules and VIN-based workflows came from project screens, requirements and implementation work.
- Decision
- Document each portal separately, then show the vehicle and VIN as the connecting operational reference.
- Reason
- This makes the product easier to explain without presenting an unverified technical integration.
- Constraint
- Direct synchronization and backend ownership between the portals were not confirmed.
- Trade-off
- The map explains product relationships, but it does not claim a complete systems architecture.
Users and access
Each role sees the same vehicle through a different responsibility.
Configure products, track vehicles, review warranty claims
HBR / DealerManage dealer organizations, users and platform access
DealerManage dealer employees and operational records
DealerRaise deliveries, complete PDI and deliver vehicles
DealerCreate Repair Orders and submit warranty claims
HBR / DealerThe role map combines confirmed screen access with responsibilities reconstructed from visible actions. Final permission boundaries still need stakeholder review.
- Decision
- Describe roles through responsibilities and permitted actions instead of demographic personas.
- Reason
- Enterprise behaviour is shaped mainly by operational ownership, access and the next required action.
- Constraint
- Formal user interviews and validated behavioural personas were not available.
- Trade-off
- Proto-personas support workflow design, but they do not replace direct research.
Information architecture
Navigation follows operational areas, while the VIN keeps the record connected.
Build Your Own
Vehicle tracking
Yard management
ConfigurationAll master data
Product configuration
New Delivery
Vehicle PDI
Retail delivery
After-salesService Center
Warranty claims
Menu structure and module grouping are grounded in the designed portal navigation and delivered screens.
- Decision
- Separate master data from product configuration and keep dealer tasks grouped by operational stage.
- Reason
- Reference data, dependency rules and daily vehicle work require different mental models.
- Constraint
- Approved navigation patterns and existing modules had to be preserved.
- Trade-off
- The structure improves clarity, but final labels still depend on product-wide naming governance.
Cross-role workflow
A New Delivery transfers responsibility for an existing vehicle.
The workflow reflects the agreed Dealer A and Dealer B process. Service coordination happens outside the portal.
- Decision
- Show the completed stage, current status, responsible dealer and next action as separate signals.
- Reason
- A single status label cannot explain where the vehicle is, who owns it and what must happen next.
- Constraint
- The workflow had to preserve the agreed business sequence.
- Trade-off
- More explicit signals improve clarity, but require consistent status rules across list and detail screens.
Status lifecycle
Status should tell the team what happened and who acts next.
Review request
Accept or reject
Prepare vehicle
Mark in transit
Complete transport
Vehicle arrives
Log inspection
Arrival recorded
Complete checklist
PDI passes
Deliver to customer
Retail delivery recorded
This normalized status and ownership model documents the intended workflow. Final system values need engineering and stakeholder confirmation.
- Decision
- Define every status with an owner, next action and exit condition.
- Reason
- This reduces labels that describe a state but leave the operational team unsure what to do.
- Constraint
- Existing status values may be shared with backend integrations.
- Trade-off
- Clearer UI language may require mapping user-facing labels to existing system values.
Business rules and edge cases
The screen is only one layer of the product.
Core rules
A New Delivery uses an existing vehicle or VIN. It does not create a vehicle.
Product options appear only when the selected chassis, GVWR, wheelbase and battery combination allows them.
Warranty registration requires a Passed PDI.
A failed PDI item requires a comment and can include supporting evidence.
A rejected quotation requires a reason before it can return for correction.
A Sales Order must not be created twice for the same approved quotation.
Important edge cases
An earlier configuration change invalidates a later option.
A saved product rule changes while a draft is open.
No product matches the requirement details.
A copied quotation contains an option that is no longer active.
NetSuite creates an order, but the response times out.
A vehicle reaches the dealer with incomplete arrival or inspection data.
These edge cases are a design and implementation checklist. Priority, system behaviour and exception ownership require product review.
- Decision
- Document rules next to the workflow and include failure paths before developer handoff.
- Reason
- A successful happy path does not explain how the interface should behave when data or dependencies change.
- Constraint
- Requirements were often clarified while UI work was already in progress.
- Trade-off
- The catalogue improves coverage, but it needs active maintenance as business logic changes.
Design development
Three decisions made the operational work easier to follow.
Dependency-based configuration
Keep unavailable downstream options visible, disable them and explain which earlier selection caused the restriction.
Reduces invalid combinationsOpen decision storyStatus plus next action
Keep lifecycle status separate from the current stage, responsible dealer and next required action.
Clarifies operational ownershipOpen decision storyEight-step PDI
Group inspection items by task and keep a final review before dealer sign-off.
Reduces visual overloadOpen decision storyThese decisions are visible in the Product Configuration, New Delivery and Vehicle PDI screens.
- Decision
- Use repeatable interaction patterns for dependency selection, long checklists and operational status.
- Reason
- The product contains many modules, but the same clarity problems appear across them.
- Constraint
- The UI needed to reuse existing styles and preserve approved functionality.
- Trade-off
- Shared patterns improve consistency, but each module still needs its own business rules and validation.
Scalable forms
Changing requirements needed a form structure that could change with them.
Data type
Required state
Validation
Label
Options
Order
Conditional visibility
Renderer options
Approved input component
Validation message
Required and disabled state
Conditional behaviour
PDI checklist
Inspection details
Pass or fail states
Evidence upload
Final review
The team introduced JSON-driven forms because field requirements frequently changed during the project.
- Decision
- Move reusable form behaviour from hardcoded screens into configuration.
- Reason
- Labels, validations, required states, options and ordering changed often.
- Constraint
- The UI work still depended on engineering integration and the supported form component set.
- Trade-off
- Configuration reduces repeated changes, but complex custom interactions may still need dedicated components.
Labels, required states, validation rules, options, order, default values and conditional visibility.
New interaction patterns, complex uploads or behaviour that the existing component set does not support.
Version schemas, test affected workflows and keep renderer support documented before a configuration is published.
KPI measurement plan
Each design decision has a measurable operational result.
Invalid configuration rate
Invalid reviews ÷ completed configurations
Selections, validation errors and quotation status
Unclear hand-off rate
Requests needing ownership clarification ÷ total requests
Status, owner, next action and support events
Field-change turnaround
Release time minus approved requirement time
Requirement, schema change, QA and release timestamps
First valid selection to quotation-ready setup.
Requests that remain beyond the expected time for the current owner.
Defects caused by updates to labels, validations, required states or options.
Track a baseline before release and compare the same event definitions after release. Keep KPI ownership with product and engineering so the measurement remains consistent.
Validation and delivery
The documentation now supports design, handoff and future requirements.
Requirement intake
Product understanding
Flow and rules
High-fidelity UI
Developer handoff
UI QA
Documentation
Vehicle Transfer and Service Center UI reached the shared test environment.
Roles, status ownership, dependencies, business rules and edge cases became easier to review together.
Configuration errors, hand-off clarity, overdue actions, PDI completion and form-change effort.
I would document the product model and lifecycle rules earlier. It would make design reviews, requirement changes and developer handoff clearer before high-fidelity work begins.