Designing navigation for the next gen of Ford vehicles
Telenav was engaged by Ford to design and deliver the navigation experience for SYNC 4 — Ford's next-generation in-vehicle infotainment platform, launching across a new model year lineup of Ford and Lincoln vehicles. This wasn't an incremental update to an existing product. It was a new platform, new vehicles, and a navigation experience that needed to be built right from the start.
The engagement was scoped around a business and technical deliverable — design and document the full navigation experience for SYNC 4, across Ford and Lincoln vehicles, ready for production. The brief wasn't driven by a specific user research finding. The challenge was a design and delivery one: how do you produce a navigation experience that is cohesive, brand-appropriate, and production-ready across four screen sizes and two brands — in a waterfall model where the documentation has to be complete before development begins?
As the sole UX designer, I had to make every decision count. There were no iterative build cycles to catch gaps — the specs had to anticipate questions before they were asked, hold up under review by Ford program managers, and be precise enough for a remote engineering team in China to build from without ambiguity. Getting the experience right before handoff wasn't a preference. It was a requirement.
B2B2C
The setup of this project was unique in a few ways. Telenav — the company I worked for — was acting as a consultant to Ford, delivering a navigation product that would live inside Ford's broader in-vehicle infotainment ecosystem. That client relationship shaped everything: we had to work within Ford and Lincoln's established design systems and brand guidelines, and our navigation product had to feel native to the IVI environment it lived inside.
Adapting a reference product
A reference navigation product already existed internally. My job was to adapt it thoughtfully for production vehicles — knowing what to carry forward, what to modify, and what needed rethinking entirely for each screen size and brand.
Consultant to client
Working as a consultant means navigating a client's processes, priorities, and constraints — not just your own team's. Design decisions had to hold up in Ford review sessions, not just internal ones.
Waterfall, not agile
The entire UX documentation had to be completed before the development team could begin implementation. No iterative cycles, no mid-build pivots — the specs had to be right before a single line of code was written.
The waterfall model came with its own set of problems. Questions that would surface naturally in an agile cycle often didn't emerge until much later in the process — sometimes after documentation was already complete. That meant I had to be both flexible enough to accommodate late questions and proactive enough to anticipate them before they became blockers for the engineering team.
One product, two brands, four screen sizes
The core UX challenge was designing a cohesive navigation experience across dramatically different screen sizes — without losing intentionality at either end of the spectrum.
Ruthless prioritization for small screens
The smallest screen forced a different kind of thinking entirely. With limited space, I had to make hard calls about what navigation information is truly essential while driving — every pixel was deliberate. Nothing made it onto the screen without justification.
Safety consideration for larger screens
A larger screen isn't simply "more room." At 15 inches, touch targets need to be sized and positioned for real driving conditions — where a driver's arm reaches comfortably, where glancing is safe, and how information density affects cognitive load. All my designs adhere NHTSA guidelines.
How I approached it
I started with the 12" screen as a baseline — closest to the reference product — and used it to establish the core interaction patterns, information architecture, and component behaviors before scaling in both directions. At certain points in the project I worked across multiple sizes simultaneously to pressure-test design decisions.
What I designed
Let's dive deeper...
Map view & browsing
Search & POI
Route planning
Turn-by-turn guidance
Settings & preferences
" style="width:75%; display:block; border-radius:4px; margin-top:1.5rem;">
Navigating stakeholders needs
Because all documentation had to be finalized before development began, the cost of gaps or ambiguities in the specs was high. Questions that might surface naturally in an agile sprint often didn't come up until well into the process — sometimes after I had already moved on to the next feature. Managing that dynamic required two things simultaneously: flexibility to accommodate late-stage questions, and enough foresight to reduce them in the first place.
The waterfall challenge
In a waterfall model, the documentation isn't a living artifact — it's a contract. By the time developers begin, the expectation is that the specs answer every question they might have. That puts significant pressure on the documentation phase, and on the designer producing it, to think several steps ahead of the build.
Beyond the engineering team in China, I held regular review sessions with program managers at Ford — presenting interaction flows, walking through behavioral specs, and fielding feedback on decisions that had to balance UX quality with program constraints. Pushbacks and change requests were part of the process. When they came, we worked through them collectively, across disciplines, until we reached a shared decision. Revisions were then made to the Confluence documentation to reflect the agreed direction.
On occasions where a design decision was genuinely contested — or where we needed confidence before committing to a direction in the docs — we ran studies to validate or invalidate the design.
Specs thorough enough to build from
A core part of my responsibility was producing detailed UX documentation in Confluence that the engineering team in China relied on as their primary build reference. With no ability to have quick in-person clarifications, the documentation had to be complete enough to stand on its own.
This wasn't high-level guidelines — it was granular, element-level specification work. For every screen and every feature, I documented what existed, how it behaved, and what every possible state looked like.
Interaction flow diagrams
End-to-end flows for every navigation feature, showing how users move through the product and how the system responds at each step.
Element callouts
Each screen annotated with callouts identifying every UI element — its name, purpose, and exact behavior within the navigation context.
Full state coverage
For every element, all possible states documented — default, active, loading, error, disabled, and edge cases — so engineers had no ambiguity.
Thorough documentation is often invisible work — but on a product this complex, with a remote engineering team and no margin for misinterpretation, it was as important as the design itself. The Confluence specs became the shared language between UX and engineering throughout the entire build.
Writing state-level documentation also sharpened the design work itself. Thinking through every element's states — including edge cases and error conditions — surfaced gaps in the interaction model early, before they became engineering problems.
Shipped in millions of production vehicles
The navigation experience shipped in production Ford and Lincoln vehicles as part of the SYNC 4 platform — across the F-150, Bronco, Mustang Mach-E, Lincoln Aviator, and Lincoln Nautilus. My work received positive feedback from Ford program managers.
Designing within constraints
Brand guidelines, an existing design system, automotive safety standards, a reference product can sometimes be limiting, but in this case, it's clarifying. The constraints forced sharper thinking about what actually matters to the driver in each moment, and what doesn't.
Leading UX decisions as the sole designer on a multi-brand, multi-screen product also reinforced how much of great UX work lives in communication: aligning with stakeholders, documenting decisions precisely enough for engineers across time zones, and knowing when to advocate for the user's experience versus when to work within the system.
The documentation discipline I developed on this project — writing specs thorough enough to eliminate ambiguity for a remote team — has shaped how I approach handoff and collaboration on every project since. Creating detailed documentation like this one forces me to engage deeply and understand the product inside out.