Telematics fleet merging platform
Discovery and UX architecture for merging mixed-fleet visibility and forklift safety into one role-aware industrial telematics platform.
- Role
- Senior Product Designer
- Period
- 2021
- Focus
- ResearchScenariosUX architecture
- Product context
- NDASaaSTelematics
Merging two industrial telematics platforms into one clearer product experience
The company needed to unite two industrial telematics platforms: one for mixed-fleet visibility and one for forklift safety. The goal was one clearer product experience without making the system harder to use.
As the solo Senior Product Designer in the early phase, I led UX research, interviews, persona and scenario mapping, information architecture refinement and concept-level product direction. I left before launch, so this case documents strategic UX foundation rather than shipped metrics.
Two products, one operating model
The B2B platform sits between fleet visibility, service and maintenance, operator safety, reporting and day-to-day operations. The work was a merge of two product logics, not simply two visual systems.
The Fleet Platform focused on mixed-fleet tracking, geofencing, service estimation and outdoor visibility. The Forklift Platform focused on warehouse safety, checklists, access control, impact detection and operator-related workflows.
The requirement was to keep or improve usability, show information relevant to the logged-in company and user, and create a smoother onboarding path for new customers.
Scope and team
I began as the only Product Designer, working with product and engineering stakeholders through interviews, support-related inputs and operational research notes. A Lead Designer joined later to support screens and project management.
The case covers discovery and concept design. It did not reach interactive-prototype validation or launch.
- Core areas: onboarding, dashboard, fleet and equipment, devices, drivers, battery, track and trace, reports, service and settings.
- Merge objective: preserve valuable domain depth while reducing legacy fragmentation.
The merge had to make work easier
The product had serious UX problems beyond visual inconsistency: unclear navigation, static reporting, inconsistent patterns, confusing list and map interactions, and fragmented settings and account flows.
A CEO, operations manager, technician, dealer, end customer and administrator should not begin with the same information or workflows. Yet the legacy systems did not make those roles clear enough.
Root causes
- Product-model mismatch between two platforms built around different value propositions.
- Weak role segmentation and information relevance.
- Fragmented information architecture across modules, lists, actions and reporting.
- High operational complexity across service, safety, equipment, operators, alerts, compliance and reporting.
Success criteria
- Let users complete core tasks without switching between systems.
- Make assets, alerts, reports and service areas easier to reach.
- Reduce friction in tracking, reporting and service tasks.
- Create a stronger foundation for role-aware decisions and future scale.
A complex operational system
The key operational story was consistent across the platform: find the right fleet or machine, understand status or a problem, investigate details, interpret the risk and take action.
That same sequence connects alerts to root cause, track and trace to history and service, reports to business decisions, and onboarding to the first useful action.
Domains and roles
- Domains: fleet and equipment tracking, safety, checklists, access control, maintenance, alerts, battery and device monitoring, reporting and settings.
- Management needs visibility, utilization, risk and reporting.
- Operational users need live status, fleet control, alerts and daily actions.
- Technical and service users need diagnostics, maintenance, incidents and device signals.
- Commercial, customer and admin roles need relevant access, account context and control.
Research before screens
I began by understanding how both products worked, where their value overlapped and where a merge could introduce confusion. The direction emerged through research, audit, persona and scenario mapping, merged IA, flow refinement and concept UI drafts.
What shaped the concept
- Operational efficiency was the primary value driver: help teams solve problems faster, use fleet capacity better and reduce operational risk.
- Users needed both daily control and higher-level visibility.
- Legacy modules were assessed selectively rather than copied into a larger system.
Working hypotheses
- Structure the merge around roles and key workflows, not legacy product boundaries.
- Make the dashboard a role-aware decision layer, not a generic homepage.
- Make reporting more flexible and task-relevant than static exports.
- Connect tracking, service, usage and incidents in fleet and equipment detail.
Five decisions shaped the merge
Merge by user goals
The platform was organized around user roles, jobs and workflows rather than Fleet Platform and Forklift Platform boundaries. This required more research than a mechanical merge, but avoided turning two confusing systems into one larger confusing system.
Focus on core cases
The concept centered on multi-fleet visibility, a role-aware dashboard, reporting and connected equipment context. These cases linked management, operations and system-wide visibility without spreading design effort evenly across every module.
Make the dashboard role-aware
One generic dashboard would be simple but weak; separate dashboards would increase fragmentation. A modular model could prioritize operational visibility, utilization, risk, service and reporting according to role.
Treat reports as a product capability
Reports were reframed from a fixed table-based export page into a structured, filter-driven decision surface that could support real operational and management questions.
Keep domain depth, organize it better
Fleet and equipment detail needed to connect status, usage, service, incidents and history without oversimplifying an industrial system. The answer was stronger hierarchy and flow, not less domain information.
A role-aware telematics foundation
The following work shows what I defined at concept stage, not a final shipped interface. The proposed structure joined the main product areas into one clearer navigation and operating model.
Merged information architecture
Sign-in and onboarding, dashboard, fleet and equipment, devices, drivers, battery, track and trace, service, reports and settings became parts of a shared product structure rather than isolated legacy areas.
Multi-fleet view
Fleet browsing became a task path: Dashboard to Search to Fleet list to Fleet details to insight selection and comparison. The aim was faster movement from broad visibility to the right asset or issue.
Role-aware dashboard
The dashboard was designed as a modular decision layer. Relevant insight groups include site or fleet summary, utilization, service forecast, impact summary, checklist results, battery activity and geofence visibility.
Reports and asset context
Reports became filter-driven and connected to dashboard insight. Equipment profiles brought usage, service, history, map and movement, battery and device signals, and operator-related context into one operational view.
Onboarding, roles and permissions
Guided onboarding linked sign-in and setup to a first useful action, reducing dependence on manual training and support. Role clarity then defined what management, operations, commercial, customer and administrator users should see and do first.
Strategic foundation, not launch metrics
I left before interactive prototype validation and launch, so this case does not claim shipped product metrics. At the stage I owned, impact was strategic and design-related.
- Reframed the merge as a UX architecture problem rather than visual consolidation.
- Grounded product direction in roles, workflows and operational relevance.
- Provided a clearer merged IA and flow logic for future design work.
- Challenged low-value legacy modules instead of copying them forward.
- Created a path toward role-aware dashboard and reporting decisions, smoother onboarding and lower support dependency.
Reflection
What worked well
The strongest contribution was problem framing: understanding what each platform did, how its value differed, which users and workflows mattered, and which legacy parts were worth keeping. This made the merge a product-architecture decision rather than a surface refresh.
What was hard
- Two legacy systems with different product logic and many operational dependencies.
- Different user types and priorities across safety, service, tracking and reporting.
- Limited validation at the concept stage and pressure to preserve legacy scope.
What I would validate next
- Interactive prototypes for dashboard, multi-fleet and equipment-detail flows.
- Role-based entry points and reporting comparisons, tracking and export needs.
- Onboarding effectiveness against support dependency.
- Smaller AI-assisted opportunities tied to existing workflows rather than broad accident prediction.
Featured Projects
My product design cases from the last few years.
