Car entertainment systems often integrate several methods of delivery of audio content (such as radio, CD and tape). We present two prototypes of new designs for car entertainment systems. The two prototypes we developed focus on the placement of primary controls for the user. One has many of the controls on the steering wheel, while the other has all of them in the traditional center console position. Our paper prototypes test basic user interaction with these designs.
We made paper mock-ups of our prototypes to gauge basic interaction for our design; the results of paper prototype testing would allow us to check whether our prototypes are headed in the right direction, and would indicate areas for improvement. The primary concerns for us were ease of use, learning curve, and functionality. We observed users as we asked them to perform open-ended tasks and talk through their thinking. We used these observations to map out how they thought about our prototypes. By analyzing our mapping and observations we were able to find flaws and strengths of the prototypes.
We tested two paper prototypes.
The 'Green' prototype had steering wheel controls and a computer display.
The computer display was intended to provide a larger display that would make the current sound status easily observable, and to allow integration with cell phones. The display was part of the car's complete computer (a la the Toyota Prius computer), and showed the 'audio' screen while the audio system was on. On the 'audio' screen there was a volume indicator, and an information display that showed the current mode. CD mode, radio mode, auxiliary mode, and phone mode were implemented. Auxiliary mode allowed the user to play sound through an auxiliary device that could be plugged into a headphone-jack on the computer. Phone mode displayed the identity of callers, and would allow for phone calls to be patched through the car sound system.
The 'Yellow' prototype had elements of a traditional sound system combined with a touch-screen for equalization and the ability to integrate an external iPod.
The goals of 'Yellow' were to improve safety and ease-of-use. Traditional controls allowed the user to change stations/tracks/cds/playlists/modes, adjust volume, and select presets. Large, graphical 'mode' buttons were intended to make mode switches intuitive and easy. A rotating knob was used for both volume control and power on/power off. A non-traditional component was an iPod dock into which the user could slide his iPod; when the iPod was placed in the dock it would begin charging and playing over the sound system. The user could then control the iPod with the radio controls.
The touch-screen allowed the user to control equalization by displaying both sliders for treble and bass, and a top-down sketch of the car with a sound-source location that could be moved by the user. The purpose of the touch-screen was to make equalization settings more accessible by giving the user an intuitive mapping.
We interviewed four undergraduate-age subjects individually. Three were male, one was female. We selected these subjects because they represented our demographic (college-age students or graduates who drive).
For our first two subjects, we allowed them to experiment with the interfaces with no pre-determined tasks. We did this to get quick feedback on our prototypes and then refined our prototypes.
For the next two interviews we prepared a script (included in appendices) that was read to each interview subject. The script briefed the subjects, and gave them sequential tasks. The second interview subject was given a few minutes before starting the tasks to experiment with the interfaces.
The tasks were:
For tasks involving volume we examined if the user was able to figure out controls easily and if they received adequate feedback. For switching between radio stations we looked at which controls the user tried to use first, and whether they were able to figure out how to move between stations. For plugging in external devices we looked at how easily the user was able to figure out how to plug devices into the sound system, and if they received adequate feedback. For using external devices we looked at whether the users controlled playback by using the external device or the sound system, and whether they were able to do everything they wanted to with the sound system controls. For switching modes, we looked at whether users could find a way to change modes, and then whether they could easily switch between modes. For muting sound we looked at whether users used 'mute' buttons or 'play/stop' buttons. For receiving calls, we looked at whether users initially controlled calls through their cell phones, and how they declined and answered calls. For adjusting sound equalization we looked at whether users were able to find the equalization controls, and how easily they could understand the controls.
In our user tests, we looked for moments in which the user was unsure as to how to proceed. We took note when users responded to a task with an incorrect action and wrote why they had chosen that option over others. We then observed what actions they attempted until coming up with the correct action. We noticed that users found alternate ways to complete a task, and we recorded their methods.
We also looked for moments in which interaction with the prototype required the user to look directly at it and away from the road, as this would indicate undesirable safety issues and one of the goals of the project is to allow the user to interact while staying concentrated on driving. Moments of user hesitation were also marked, as they indicated that the prototype didn't have an intuitive interface.
After the tests we asked users to comment on what they liked and disliked, and logged their comments. We then prioritized all the noticed design flaws in terms of severity as related to the users ability to concentrate on driving.
We saw that often times the users had a difficult time getting used to new ideas, such as steering wheel controls for those who have not used them before. In all cases, the users had to look at the control interface more than we had anticipated. When first interacting with the prototype, most users hesitated and searched through all the buttons to find the correct one rather than pressing probable buttons until they found the desired button. As expected, users relied on their previous experiences when relating to our interface; for example, those who were used to pressing a volume knob to control on/off functions did the same with our prototype. Users had pretty clear conceptions of what they liked and disliked, and their comments were similar. Most told us that the generic “change” button was confusing, that the function of the presets was clear but that they would not mind those buttons having additional functionality in other modes, and that if we were going to control the iPod through the stereo system that we should emulate the iPod’s interface as closely as possible. Many were confused by the cell phone functions on the prototype that supports cell phones, and they also mentioned the need for a clear specifically marked “eject” button for both the iPod and the CD.
Test subjects were confused by multiple or very involved displays, and we often noticed them taking a long time to read through the options on the screen before deciding how to carry on with the desired action.
The user comments at the end of each test were very helpful, so here is a list of the main ideas and suggestion our users provided:
The primary results we got from these experiments referred to physical placement and functionality of buttons. Since buttons are our primary source of interaction with the system, extensive knowledge of user interaction with them will prove to be extremely valuable. We heard over and over that the controls should be as simple as possible in two different dimensions. The controls should be simple to physically manipulate. Complicated twisting, bending and turning should not be necessary. Buttons that have obvious functions and knobs that turn simply are preferable. Also the functions of the buttons should be simple. Having multiple functions per button without explicitly calling them out makes the system far more complex and harder to figure out. After realizing this, we started discussing how to call out multiple vs single function controls either through different colors, shapes, sizes or labels. These results will likely prove to be very valuable for our future designs.
Another good series of results that we got concerned the displays for our designs. We heard from several users that the displays should be uniform and clean. The less information displayed the better. The users wanted something they could easily glance down at while driving without too much distraction from the primary task of driving. Our initial designs attempted to convey a lot of information at once to the user and seemed to only result in confusion. This also happened when the users looked at how we had labeled certain controls. Having the word "mode" in several contexts and several general purpose "up" buttons lead to confusion over what did what. We need to be more careful in how we choose our labels and the lexicon we ask the user to learn.
A big focus of our system was also in the connection of external devices. Since we are designing primarily for undergraduate-aged students we wanted to allow them to use their primary sources of music while in the car. We attempted to duplicate the functionality of the external devices within our own design which lead to confusion and frustration. The users told us that they either wanted the exact same control scheme as their player used or just to use the player itself.
We also noticed in our initial designs through talking to our users that our hardware/software interaction was somewhat poorly thought out. Often in our tests our users would attempt a control and we would have to look at each other to decide what it should do. From these tests we have decided that we more clearly need to define what our controls do and how they do it. We feel that an iterative process of designing software and the looking at the hardware and then looking back at the software will be ideal for this. This also somewhat limited the data we could get from our users. Because our system was not completely defined there were certain interactions that simply did not exist. As we add these in and design them in the future it will be important to revisit the users and make sure our new ideas are usable and friendly.