Redesigning iDrive
One of my early design experiences was leading a team of graduate students (myself, Ricardo Prada, and Mohammed Rahman) in the redesign of an automotive telematics system. BMW’s iDrive (1.0) was intended to integrate hundreds of functions and make them accessible to the driver or passenger.
Unfortunately, iDrive used a display the size of an index card to communicate these functions, with a large circular knob to issue commands (this included anything from changing the radio station to adjusting the suspension). Couple this with a relatively opaque interface, and iDrive was set to be a challenge for any user. Critics described the iDrive interface as “making you take your eyes off the road just long enough to plow into a solid object”.
This brought up two interesting questions for our design team –
- When hardware redesigns are out of the question, how can redesigning the interface reduce usability issues?
- When a display is so feature-rich that task analysis seems unfeasible, how can designers analyze user requirements to provide a solution?
Our answers to these questions, along with the resulting design and analysis, were reported in a 2005 issue of User Experience Magazine. For a preliminary draft of the article, click here. For more information on the analyses and design, see below.
Using Work Domain Analysis
The initial iDrive system contained over 700 functions; the number of available functions made a detailed task analysis of each task unfeasible for a project with a limited timeline. Focusing on strict task analysis for such a highly integrated system might also lead our team to potentially miss relationships between functions if each function were analyzed individually. Such an approach could easily create situations in which optimizing the interface for one task might make performing another task more difficult.
An alternate approach would be using analyses that examine the constraints of the system – including the abstract goals for which the system was designed. By understanding the boundaries of the system, we can better understand how to optimize a display, and what critical information must be displayed to the operator.
To do this, we used work domain analysis – a subset of cognitive work analysis used to define the basic constraints of a work domain. This approach focuses on the complexity of the work environment, and how the overall goals of the system affect how tasks are performed. Work domain analysis uses two analysis techniques – an abstraction-decomposition space (ADS) and an abstraction hierarchy (AH). The ADS for the iDrive was used to describe the various components of the system (developed through card sort methodology), which were decomposed across levels of abstraction as well as the subsystems involved in the design. This analysis allows us to condense a great variety of seemingly unrelated functions into a form that shows how one interface could address controlling a variety of functions. An example ADS is presented above.
While an abstraction-decomposition space such as the one shown above breaks downs the whole into its parts, it does not classify the functional relationships (means-end relationships) between different subsystems. For this, we used an abstraction hierarchy (AH). The AH shows how high level, abstract functions may be supported by low level physical functions. For our purposes, we used the AH to help indicate how the same physical system can support multiple higher level functions. An example AH is provided in the paper below.
Publications