New Car/Interfaces
I increased my fleet of automobiles from zero to one today. On the drive home I got lost. I got lost because of some failure on the part of my car/phone to tell me important information. My car has Microsoft Sync installed, and the salesman showed me how to pair my iPhone with the car before I left the parking lot. I was not sure of the way back, so I tried to get Siri to direct me. Siri was happy to look up the route, but she did not say the directions out loud. She also could not comprehend that I wanted to add KFC as an intermediate stop on my journey, and then continue home. I lost about a half-hour, and by the time I got home the food was cold and my girlfriend was leaving for work on an empty stomach.
As an engineer, I am privy to the fact that you do not always get to implement every feature that you want to implement. I also realize that sometimes a designer does not think of a feature that appears obvious to the end user. I am not mad at Ford, Microsoft, or Apple for not mentioning mid-drive that if my iPhone is on silent I will still hear Siri as she figures out what I want, but I will not be able to hear her give me directions.
Ok, I might be a little mad at these companies, but this situation does illustrate an important obligation that I must fulfill in my own projects. A user should not have to struggle to understand their devices. There are many ways a user can struggle, and I will list a few here off the top of my head:
The user does not understand the limitations of their device.
The user does not understand how to use their device properly because the interface is not intuitive.
The user does not understand why the device is useful.
These and other gaps in user/device understanding can lead to what those who understand a technology can refer to as PEBKAC errors. True to my youthful optimism, I posit that if the above misunderstandings do not exist then the user will not experience PEBKAC errors. By contrast I believe that if a device, app, or anything else does not satisfy these three bullets then they probably will not have loyal users.
For my physiological feedback project these requirements manifest themselves in specific ways. I cannot, for example, read a pulse off of a person's finger. A gamer needs their fingers to play the game. I can get a terrific pulse off of my finger, but the trade off of immobilizing that finger ruins the entire device. I can not develop a device that intrudes on the power of a game to immerse the player in the story/world. That would destroy it's true purpose: to immerse the player more thoroughly.
