All work
CASE STUDY · MSc HCI · IN-CAR UX
AVENUE
How do we make a 4-hour car journey feel like 40 minutes for someone who isn’t driving?
PROBLEM
Rear-seat passengers have little control over their own journey: hard-to-read screens, voice commands that fail, and no access to air controls.
MY ROLE
UX Designer in a team of 6. I owned the context-of-use analysis and sketched and prototyped 4 core screens.
METHODS
5 interviews, Kano model, HTA, SHERPA, KLM, think-aloud testing with 8 people.
TIMELINE & TOOLS
13 weeks · Figma, Miro
52%
shorter task time across 4 key tasks (KLM-modelled)
48.5 → 69.4
net satisfaction, V1 to V2 (n=8)
8 of 8
participants rated V2 higher
6
potential errors caught before testing (SHERPA)
Open Figma prototype
ON THIS PAGE
The problem
Research
Context of use
Prioritisation
Design
Evaluation
Results
Reflection
THE PROBLEM
Rear-seat passengers are the forgotten users of the car. The driver gets navigation, climate and entertainment within arm’s reach. The person three feet behind them gets boredom, motion sickness, and a screen they have to ask someone else to control.
Our brief was open-ended: design an in-car rear-seat infotainment system. My team and I pushed back on that framing. Building another screen wasn’t the problem worth solving; the passenger experience was.
CONSTRAINTS
13 weeks, team of 6, Figma prototypes rather than real hardware
Users spanning kids, working professionals and elderly passengers, with conflicting needs
A moving vehicle: motion sickness, glare, awkward seating angles
A team split across time zones over the Easter break
WHAT 5 INTERVIEWS TOLD US
We interviewed 5 rear-seat passengers aged 24 to 58, about 30 minutes each, focused on the whole journey and not just the screen.
#
Pain point
Mentioned by
1
Hard to read screens in a moving car
3 of 5
2
Voice commands fail and need repeating
3 of 5
3
In-car UI doesn’t behave like a phone
4 of 5
4
Icons hard to find; navigation feels clunky
2 of 5
5
Motion sickness, no rear access to air controls
1 of 5 (but severe)
THE INSIGHT THAT SHAPED THE PRODUCT
Pain point 5 came from one participant, but it was the most visceral story we heard. It’s why rear passengers got their own climate, lighting and sound controls, even though the brief said “infotainment”.
Empathy map from our 5 interviews: what passengers think and feel, see, hear, say and do, plus their pains and gains. Click the map to open it full size.
DESIGNING FOR A MOVING BOX
I owned the context-of-use analysis. Standard frameworks assume a stationary user, so our analysis focused on four risks specific to a moving vehicle.
Motion sickness: led to an adaptive refresh rate and a motion-content filter while the car moves.
Glare and lighting: led to an anti-reflective screen, adjustable brightness and dark mode.
Shared space: led to a headphone jack, volume control and sharing with co-passengers.
Interruptions: led to offline media and a recently accessed section, so passengers can pick up where they left off.
Each factor was traced to a requirement and to the method we would use to evaluate it, so nothing in the spec was untestable.
See all 17 factors
Factor
Impact on UX
Associated requirement
Evaluation method
Task frequencies
Quick and efficient task completion
Shortcuts for high-frequency tasks
Usability testing
Task durations
Minimise user fatigue and frustration
Quick actions for regular tasks
Usability testing
Task flexibility
Customisable and flexible task performance
Support for multiple controls
Usability testing
Task dependencies
Ensure functionality and feature availability
Offline media and functionality
User testing, questionnaires
Physical & cognitive demands
Accommodate varying user abilities
Multi-modal delivery
Task load analysis
Task error risks
Minimise confusion and frustration
Privacy protection measures, error recovery
Usability testing
Group working
Support multi-user interactions
Multiplayer capabilities, user profiles
User observation
Assistance
Enhance ease of use and satisfaction
Voice instructions, tooltips
Questionnaires
Interruptions
Minimise negative impact on interactions
Quick physical controls
Usability testing
Communications
Seamless integration of networked communications
Video calls, microphone, speakers
Usability testing
Discretion
Provide alternatives for user interactions
Barge-in functionality, home button
Usability testing
Visual environment
Ensure legibility and readability
Adjustable brightness, dark/light mode
Usability testing
Auditory environment
Maintain audio quality and privacy
Volume control, headphone jack
User testing
Space constraints
Maximise usability within available space
Prioritise physical controls
Ergonomic testing
User posture
Accommodate different user postures
Physical controls, voice UI options
User testing
Physical location
Ensure comfort, visibility and ease of use
Screen mobility, glare reduction
Ergonomic testing
PRIORITISING WITH KANO
We used the Kano model to sort our requirements into Must-Haves, Performance and Delighters, so we had a real prioritisation conversation instead of agreeing to build everything. We wrote each requirement as a Volere card.
Memory Clippings, which lets passengers record moments from the journey, became one of the most distinctive features of the final system.
Our requirements, written as Volere cards (hover to pause)
FROM PAPER SKETCHES TO PROTOTYPE
I sketched and prototyped the Home screen, Videos library, Audio library and Media player.
Early sketches of the Videos, Audio and Media player screens
KEY DESIGN DECISIONS
Collapsible sidebar: collapsing the fixed sidebar to a thin icon rail kept it discoverable and freed up space for the main content.
AR toggle moved into the map: a permanent AR button for a feature used rarely was wasting the bottom bar.
Semi-circular temperature slider: temperature feels like a range with a comfortable middle, not a line.
TESTING IN TWO PHASES
Before bringing users in, we ran HTA and SHERPA to catch errors at the design stage. HTA showed that starting Maps in AR mode put extra steps between users and their directions, so we made the normal map the default and AR a toggle.
HIERARCHICAL TASK ANALYSIS
The Maps flow, from the full analysis
0
Facilitating access to entertainment, information and utility during a journey
1
Facilitating access to
INFORMATION
Maps flow
1.1 Journey information
1.1.1
Access maps & navigation
1.1.2
Use AR mode during navigation
1.1.3
View ETA
The Maps flow (1.1), the part of the task analysis that changed the design
See the full task analysis
HIERARCHICAL TASK ANALYSIS
Whole system, 4 goals
0
Facilitating access to entertainment, information and utility during a journey
1
Facilitating access to
INFORMATION
Maps flow
1.1 Journey information
1.1.1
Access maps & navigation
1.1.2
Use AR mode during navigation
1.1.3
View ETA
1.2 System information
1.2.1
Check connectivity
1.2.2
View notifications
1.2.3
Access help
1.3 Misc. information
1.3.1
Access news
1.3.2
Access weather
1.3.3
View time and date
2
Facilitating access to
ENTERTAINMENT
2.1 Playing media
2.1.1
Play music
2.1.2
Play videos
2.1.3
Play movies
2.2 Memory clippings
2.2.1
Record moments
2.2.2
Save to device
2.2.3
Manage and view the recordings
3
Facilitating access to
UTILITIES
3.1 Accessibility
3.1.1
Activate voice control
3.1.2
Adjust text size
3.1.3
Enable read out aloud
3.1.4
Choose light/dark mode
3.1.5
Adjust brightness
3.1.6
Enable closed captions
3.2 Controls and settings
3.2.1
Manage routines
3.2.2
Control AC
3.2.3
Adjust lighting
3.2.4
Adjust sound
3.2.5
Accessibility settings
3.2.6
On/off settings
3.2.7
Adjust volume controls
3.2.8
Manage privacy settings
3.3 Privacy and safety
3.3.1
Create & manage profiles
3.3.2
User modes
3.3.3
Enable SOS
4
Facilitating access to
APPS
4.1 Games
4.1.1
Browse game library
4.1.2
Select & launch game
4.2 Video calls
4.2.1
Access video call apps
4.2.2
Initiate video call
4.2.3
Manage video call settings
4.3 Movies
4.3.1
Browse movie app library
4.3.2
Select & play movie
4.4 Access apps
4.4.1
Open app market
4.4.2
Search for apps
4.4.3
Browse apps by category
4.4.4
Download and install apps
4.4.5
Manage installed apps
Apps (4) is also reached indirectly from Information, Entertainment and Utilities.
Hierarchical task analysis of the whole system, with the Maps flow (1.1) highlighted
Error found by SHERPA
Severity
Fix
Memory Clippings started recording on app open
Medium
Added an explicit Start Recording button
A sleeping passenger could be recorded for hours
High
Added a 10-minute inactivity auto-stop
Users couldn’t tell which profile mode they were in
High
Added a persistent profile indicator
Full-screen maps had no obvious exit
High
Added persistent close and minimise buttons
Then 8 participants used both versions with think-aloud, our 21-item AVENUEQ questionnaire and time-on-task.
Metric (AVENUEQ, n=8)
V1
V2
Change
Overall experience
3.00
4.40
+47%
Task straightforwardness
3.15
4.65
+48%
Mental effort (lower is better)
3.25
2.15
−34%
Net satisfaction score
48.5
69.4
+43%
THE HEADLINE NUMBER: 52% FASTER
Using the Keystroke-Level Model, we modelled four frequent tasks step by step in V1 and V2: changing user mode, playing or controlling media, switching apps, and toggling Bluetooth or Wi-Fi.
Task
V1
V2
Reduction
Total across 4 tasks
67.9 s
31.75 s
−52%
V2 addressed the issues we found when testing V1.
Final Videos, Audio and Media player screens
WHAT I’D DO DIFFERENTLY
Test with numbers earlier: a simple Likert score by week 6 would have shown which screens needed rework before I built them in high fidelity.
Plan for time zones: synchronous meetings across time zones slowed our decisions. Async reviews would have helped.
Interview a driver: drivers control the journey our users are on. One conversation would likely have surfaced ideas we missed.
Saying no to a feature is a design decision, not a failure to deliver.
The lesson I took from prioritising with Kano and moving the AR button into the map
LET’S TALK.
I’m looking for product and UX design roles in Mumbai, remote, or where relocation makes sense. I reply within a day.
© 2026 Hiral Mamaniya
Designed and built in Framer
All work
CASE STUDY · MSc HCI · IN-CAR UX
AVENUE
How do we make a 4-hour car journey feel like 40 minutes for someone who isn’t driving?
PROBLEM
Rear-seat passengers have little control over their own journey: hard-to-read screens, voice commands that fail, and no access to air controls.
MY ROLE
UX Designer in a team of 6. I owned the context-of-use analysis and sketched and prototyped 4 core screens.
METHODS
5 interviews, Kano model, HTA, SHERPA, KLM, think-aloud testing with 8 people.
TIMELINE & TOOLS
13 weeks · Figma, Miro
52%
shorter task time across 4 key tasks (KLM-modelled)
48.5 → 69.4
net satisfaction, V1 to V2 (n=8)
8 of 8
participants rated V2 higher
6
potential errors caught before testing (SHERPA)
Open Figma prototype
The problem
Research
Context of use
Prioritisation
Design
Evaluation
Results
Reflection
THE PROBLEM
Rear-seat passengers are the forgotten users of the car. The driver gets navigation, climate and entertainment within arm’s reach. The person three feet behind them gets boredom, motion sickness, and a screen they have to ask someone else to control.
Our brief was open-ended: design an in-car rear-seat infotainment system. My team and I pushed back on that framing. Building another screen wasn’t the problem worth solving; the passenger experience was.
CONSTRAINTS
13 weeks, team of 6, Figma prototypes rather than real hardware
Users spanning kids, working professionals and elderly passengers, with conflicting needs
A moving vehicle: motion sickness, glare, awkward seating angles
A team split across time zones over the Easter break
WHAT 5 INTERVIEWS TOLD US
We interviewed 5 rear-seat passengers aged 24 to 58, about 30 minutes each, focused on the whole journey and not just the screen.
#
Pain point
Mentioned by
1
Hard to read screens in a moving car
3 of 5
2
Voice commands fail and need repeating
3 of 5
3
In-car UI doesn’t behave like a phone
4 of 5
4
Icons hard to find; navigation feels clunky
2 of 5
5
Motion sickness, no rear access to air controls
1 of 5 (but severe)
THE INSIGHT THAT SHAPED THE PRODUCT
Pain point 5 came from one participant, but it was the most visceral story we heard. It’s why rear passengers got their own climate, lighting and sound controls, even though the brief said “infotainment”.
Empathy map from our 5 interviews: what passengers think and feel, see, hear, say and do, plus their pains and gains. Swipe sideways to explore, or tap the map to open it full size.
DESIGNING FOR A MOVING BOX
I owned the context-of-use analysis. Standard frameworks assume a stationary user, so our analysis focused on four risks specific to a moving vehicle.
Motion sickness: led to an adaptive refresh rate and a motion-content filter while the car moves.
Glare and lighting: led to an anti-reflective screen, adjustable brightness and dark mode.
Shared space: led to a headphone jack, volume control and sharing with co-passengers.
Interruptions: led to offline media and a recently accessed section, so passengers can pick up where they left off.
Each factor was traced to a requirement and to the method we would use to evaluate it, so nothing in the spec was untestable.
See all 17 factors
Task frequencies
IMPACT ON UX
Quick and efficient task completion
ASSOCIATED REQUIREMENT
Shortcuts for high-frequency tasks
EVALUATION METHOD
Usability testing
Task durations
IMPACT ON UX
Minimise user fatigue and frustration
ASSOCIATED REQUIREMENT
Quick actions for regular tasks
EVALUATION METHOD
Usability testing
Task flexibility
IMPACT ON UX
Customisable and flexible task performance
ASSOCIATED REQUIREMENT
Support for multiple controls
EVALUATION METHOD
Usability testing
Task dependencies
IMPACT ON UX
Ensure functionality and feature availability
ASSOCIATED REQUIREMENT
Offline media and functionality
EVALUATION METHOD
User testing, questionnaires
Physical & cognitive demands
IMPACT ON UX
Accommodate varying user abilities
ASSOCIATED REQUIREMENT
Multi-modal delivery
EVALUATION METHOD
Task load analysis
Task error risks
IMPACT ON UX
Minimise confusion and frustration
ASSOCIATED REQUIREMENT
Privacy protection measures, error recovery
EVALUATION METHOD
Usability testing
Group working
IMPACT ON UX
Support multi-user interactions
ASSOCIATED REQUIREMENT
Multiplayer capabilities, user profiles
EVALUATION METHOD
User observation
Assistance
IMPACT ON UX
Enhance ease of use and satisfaction
ASSOCIATED REQUIREMENT
Voice instructions, tooltips
EVALUATION METHOD
Questionnaires
Interruptions
IMPACT ON UX
Minimise negative impact on interactions
ASSOCIATED REQUIREMENT
Quick physical controls
EVALUATION METHOD
Usability testing
Communications
IMPACT ON UX
Seamless integration of networked communications
ASSOCIATED REQUIREMENT
Video calls, microphone, speakers
EVALUATION METHOD
Usability testing
Discretion
IMPACT ON UX
Provide alternatives for user interactions
ASSOCIATED REQUIREMENT
Barge-in functionality, home button
EVALUATION METHOD
Usability testing
Visual environment
IMPACT ON UX
Ensure legibility and readability
ASSOCIATED REQUIREMENT
Adjustable brightness, dark/light mode
EVALUATION METHOD
Usability testing
Auditory environment
IMPACT ON UX
Maintain audio quality and privacy
ASSOCIATED REQUIREMENT
Volume control, headphone jack
EVALUATION METHOD
User testing
Space constraints
IMPACT ON UX
Maximise usability within available space
ASSOCIATED REQUIREMENT
Prioritise physical controls
EVALUATION METHOD
Ergonomic testing
User posture
IMPACT ON UX
Accommodate different user postures
ASSOCIATED REQUIREMENT
Physical controls, voice UI options
EVALUATION METHOD
User testing
Physical location
IMPACT ON UX
Ensure comfort, visibility and ease of use
ASSOCIATED REQUIREMENT
Screen mobility, glare reduction
EVALUATION METHOD
Ergonomic testing
PRIORITISING WITH KANO
We used the Kano model to sort our requirements into Must-Haves, Performance and Delighters, so we had a real prioritisation conversation instead of agreeing to build everything. We wrote each requirement as a Volere card.
Memory Clippings, which lets passengers record moments from the journey, became one of the most distinctive features of the final system.
Our requirements, written as Volere cards (hover to pause)
FROM PAPER SKETCHES TO PROTOTYPE
I sketched and prototyped the Home screen, Videos library, Audio library and Media player.
Early sketches of the Videos, Audio and Media player screens
KEY DESIGN DECISIONS
Collapsible sidebar: collapsing the fixed sidebar to a thin icon rail kept it discoverable and freed up space for the main content.
AR toggle moved into the map: a permanent AR button for a feature used rarely was wasting the bottom bar.
Semi-circular temperature slider: temperature feels like a range with a comfortable middle, not a line.
TESTING IN TWO PHASES
Before bringing users in, we ran HTA and SHERPA to catch errors at the design stage. HTA showed that starting Maps in AR mode put extra steps between users and their directions, so we made the normal map the default and AR a toggle.
HIERARCHICAL TASK ANALYSIS
The Maps flow, from the full analysis
0
Facilitating access to entertainment, information and utility during a journey
1
Facilitating access to
INFORMATION
Maps flow
1.1 Journey information
1.1.1
Access maps & navigation
1.1.2
Use AR mode during navigation
1.1.3
View ETA
The Maps flow (1.1), the part of the task analysis that changed the design
See the full task analysis
HIERARCHICAL TASK ANALYSIS
Whole system, 4 goals
0
Facilitating access to entertainment, information and utility during a journey
1
Facilitating access to
INFORMATION
Maps flow
1.1 Journey information
1.1.1
Access maps & navigation
1.1.2
Use AR mode during navigation
1.1.3
View ETA
1.2 System information
1.2.1
Check connectivity
1.2.2
View notifications
1.2.3
Access help
1.3 Misc. information
1.3.1
Access news
1.3.2
Access weather
1.3.3
View time and date
2
Facilitating access to
ENTERTAINMENT
2.1 Playing media
2.1.1
Play music
2.1.2
Play videos
2.1.3
Play movies
2.2 Memory clippings
2.2.1
Record moments
2.2.2
Save to device
2.2.3
Manage and view the recordings
3
Facilitating access to
UTILITIES
3.1 Accessibility
3.1.1
Activate voice control
3.1.2
Adjust text size
3.1.3
Enable read out aloud
3.1.4
Choose light/dark mode
3.1.5
Adjust brightness
3.1.6
Enable closed captions
3.2 Controls and settings
3.2.1
Manage routines
3.2.2
Control AC
3.2.3
Adjust lighting
3.2.4
Adjust sound
3.2.5
Accessibility settings
3.2.6
On/off settings
3.2.7
Adjust volume controls
3.2.8
Manage privacy settings
3.3 Privacy and safety
3.3.1
Create & manage profiles
3.3.2
User modes
3.3.3
Enable SOS
4
Facilitating access to
APPS
4.1 Games
4.1.1
Browse game library
4.1.2
Select & launch game
4.2 Video calls
4.2.1
Access video call apps
4.2.2
Initiate video call
4.2.3
Manage video call settings
4.3 Movies
4.3.1
Browse movie app library
4.3.2
Select & play movie
4.4 Access apps
4.4.1
Open app market
4.4.2
Search for apps
4.4.3
Browse apps by category
4.4.4
Download and install apps
4.4.5
Manage installed apps
Apps (4) is also reached indirectly from Information, Entertainment and Utilities.
Hierarchical task analysis of the whole system, with the Maps flow (1.1) highlighted
Error found by SHERPA
Severity
Fix
Memory Clippings started recording on app open
Medium
Added an explicit Start Recording button
A sleeping passenger could be recorded for hours
High
Added a 10-minute inactivity auto-stop
Users couldn’t tell which profile mode they were in
High
Added a persistent profile indicator
Full-screen maps had no obvious exit
High
Added persistent close and minimise buttons
Then 8 participants used both versions with think-aloud, our 21-item AVENUEQ questionnaire and time-on-task.
Overall experience
V1
3.00
V2
4.40
CHANGE
+47%
Task straightforwardness
V1
3.15
V2
4.65
CHANGE
+48%
Mental effort (lower is better)
V1
3.25
V2
2.15
CHANGE
−34%
Net satisfaction score
V1
48.5
V2
69.4
CHANGE
+43%
THE HEADLINE NUMBER: 52% FASTER
Using the Keystroke-Level Model, we modelled four frequent tasks step by step in V1 and V2: changing user mode, playing or controlling media, switching apps, and toggling Bluetooth or Wi-Fi.
Total across 4 tasks
V1
67.9 s
V2
31.75 s
REDUCTION
−52%
V2 addressed the issues we found when testing V1.
Final Videos, Audio and Media player screens
WHAT I’D DO DIFFERENTLY
Test with numbers earlier: a simple Likert score by week 6 would have shown which screens needed rework before I built them in high fidelity.
Plan for time zones: synchronous meetings across time zones slowed our decisions. Async reviews would have helped.
Interview a driver: drivers control the journey our users are on. One conversation would likely have surfaced ideas we missed.
Saying no to a feature is a design decision, not a failure to deliver.
The lesson I took from prioritising with Kano and moving the AR button into the map
LET’S TALK.
I’m looking for product and UX design roles in Mumbai, remote, or where relocation makes sense. I reply within a day.
© 2026 Hiral Mamaniya
Designed and built in Framer