Mahindra Infotainment System

1. Mahindra Infotainment System Heuristic Evaluation v1.0 Maya Studios July 6, 2010

2. Details • Evaluation is solely based on the wireframes provided and not in the entirety of the system which includes remote control, key bank, steering wheel buttons and touch input • It has been analyzed in accordance with Jacob Nielsen’s heuristic evaluationwhich is a bit skewed towards web interfaces. However, subsequent reviews will be more specific to the system in question.

3. 1. Visibility of System status • Intent: The system should always keep users informed about what is going on, through appropriate feedback within reasonable time. • Comments: The interaction flows in many functionalities are new to the user. Functionalities like Bluetooth music, phone operations is lacking a clear feedback on actions taken and an understanding on how the state of the system changes. • Suggestions: an Info option on all stages might be helpful. Other options like status bar, system diagrams, transitions can be considered.

4. 2. Match between system and the real world • Intent: The system should speak the users' language, with words, phrases and concepts familiar to the user, rather than system-oriented terms. Follow real-world conventions, making information appear in a natural and logical order. • Comments: The present system speaks a system-oriented language. The user follows a mechanical set of steps to achieve his tasks. A user is expected to try and understand various methods to achieve his tasks. The system provides new features in an environment where user is busy with primary task of driving a vehicle. Here, connect to real world will be helpful in minimizing the learning curve of the system and increasing the effective usage of the system. The tasks like "pairing with a device" "RVC camera" will require clear language. A clear match will facilitate gaze free control of the system from steering wheel, remote etc. • Suggestions: Few metaphors can be explored to design interaction model. Once the user understands the metaphor, he will be able to connect to the system. Other HCI systems providing similar functionalities can be researched upon.

5. 3. User control and freedom • Intent: Users often choose system functions by mistake and will need a clearly marked "emergency exit" to leave the unwanted state without having to go through an extended dialogue. Support undo and redo. • Comments: Present system provides easy exit options through various hard button controls. Unwanted state can be easily exited using buttons from switch bank, remote, steering wheel controls. However, and undo/redo or history of actions is not yet a part of the system • Suggestions: Possibility of undo/redo and specially reset settings can be considered to help user in case of an unwanted setting change. System profiles can also be thought upon.

6. 4. Consistency and Standards • Intent: Users should not have to wonder whether different words, situations, or actions mean the same thing. Follow platform conventions. • Comments: Terminology of the present system is weak in this regard. The "select phone” , "pair with AHU" , "quit" and others can be replaced with more appropriate terms. Conventions in this regard can also be considered for the volume button. Whether it can be used as a scroll, and in what situations. Although the infotainment systems are evolving and hence platform conventions are not yet in place. • Suggestions: Providing consistence and strict terminology. Usage of visual elements to convey the meanings of various functionalities on display. Also, options to provide the interface in various languages can be considered.

7. 5. Error Prevention • Intent: Even better than good error messages is a careful design which prevents a problem from occurring in the first place. Either eliminate error-prone conditions or check for them and present users with a confirmation option before they commit to the action. • Comments: The present system does not accommodate secondary confirmation on actions. Permanent actions like “delete device”, “delete all” are one touch operations. • Suggestions: The commit action might make the interaction lengthier, but in driving situations, it will provide context and time for a user to understand the actions.

8. 6. Recognition than recall • Intent: Minimize the user's memory load by making objects, actions, and options visible. The user should not have to remember information from one part of the dialogue to another. Instructions for use of the system should be visible or easily retrievable whenever appropriate. • Comments: The system provides all the required controls for a functionality on same UI. However, several use cases like playing music from BT when no device is paired, or pairing only as phone device/audio device required user to remember this information. • Suggestions: The system can be subtly divided to accommodate primary tasks on the same UI while secondary tasks/settings can be provided in separate UI.

9. 7. Flexibility and efficiency of use • Intent: Accelerators -- unseen by the novice user -- may often speed up the interaction for the expert user such that the system can cater to both inexperienced and experienced users. Allow users to tailor frequent actions. • Comments: This intent is important for the infotainment system as its user will be a frequent user and would require to use the system while driving. Present system does not provide any modification or customization in the task flows. • Suggestions: Personalized shortcuts, favorites, hierarchy in subtasks based on usage can be considered. The system can also by default highlight the next probable action button so that user’s attention is diverted towards it.

10. 8. Aesthetic and minimalistic design • Intent: Dialogues should not contain information which is irrelevant or rarely needed. Every extra unit of information in a dialogue competes with the relevant units of information and diminishes their relative visibility. • Comments: The present system wireframes are simple and not-so crowded. In fact a few pop-ups provide lesser information than required. For eg the reason for error, possible solution etc are not mentioned. • Suggestions: Wireframe wise, the interface should be simple and direct. In a vehicle scenario a simple information layout on screen will be helpful. Visual design wise, a lot of style and flavor can be added on the simple interface. Spacial perception of the user will also be clear if consistency in layout is maintained.

11. 9. Help users recognize, diagnose and recover from errors • Intent: Error messages should be expressed in plain language (no codes), precisely indicate the problem, and constructively suggest a solution. • Comments: The pop ups presently are informing about the failure, it neither provides reason for error neither the solution to the problem. • Suggestions: The error pops can be more rich and expressive. Visual language can also be used to indicate gravity of error.

12. 10. Help Documentation • Intent: Even though it is better if the system can be used without documentation, it may be necessary to provide help and documentation. Any such information should be easy to search, focused on the user's task, list concrete steps to be carried out, and not be too large. • Comments: The present system doesn't accommodate help. Although a user manual is being planned. • Suggestions: Integrated help/suggestion tool can be considered. That will be a first in infotainment systems.

13. Thank You