יום חמישי, 24 בספטמבר 2015

From Sound User Interface to Hardware Design



The other day I went to meet a long-time-no-see client of mine.  Their product is on the market for a while now, and they are collecting feedback for the next version.  For the most part, the feedback is great – users can handle the machine easily and get the work done efficiently and effectively.  Yet, there are glitches wherever sounds play a significant role.  The feedback here is consistent and persistent: the sounds are annoying, and the speech (where applied) is not clear.

After a short discussion, we the identified following:
  1. Alert sounds were generated arbitrarily by developers to comply with the specific industry standards.
  2. The environment, as far as other alerts, background noise, the machine itself and its speaker, were not taken into account nor tested.
  3. The speech that is being used was just “downloaded from the internet” with no special adjustments to the environment and to the context of use.
What needs to be done:
  1. Sound User Interface needs to be taken seriously.  That is, especially where at least some of the interaction is being done while the user can’t look at the system’s Visual User Interface, due to their task.
  2. Sounds need to be generated (with the help of a professional sound technician) while considering the environment, background noise, and the given hardware.
  3. Sound design, as all UX design, needs to be based on conventions in order to be easily recognized and learnable.
  4. Sound need to be tested within the right context and carefully adjusted.
The client wrote their homework and we moved to discuss the most annoying sound that kept getting bad feedback.  That’s the sound that the system plays when the user hits both pedals together.  The system is programmed to “no function” in that case and the sound needs to communicate that fact – the user will have to reposition their leg to the desired pedal.  Of course, if this is the given state of affairs, the alert sound needs to be designed according to the guidelines above.  But hey, wait a minute!  Aren’t we supposed to leave our desks and check the context of use?  How come such a mishap of hitting the two pedals is even possible?
It took a short while, but we managed to get up and find that pedal set.  Now, notice how similar these pedals are, plus there isn’t any barrier in between them.  It seems like the annoying sound is not the problem here. The root cause is the fact that this pedal set is ill-designed!



What needs to be done:
  • Hardware should be designed while considering our ability to process tactile and haptic feedback – that’s the feedback that we get though the nerves in our musculoskeletal system.
In this example, the two pedals can get a different shape, a different size, a different angle and a different texture.
  • Hardware should be designed in order to block misuse.
In this example, just a simple physical barrier in between the pedals can function as a dual hit blocker.  It shouldn’t even need to be higher than the initial level of the pedals.

Recap

  1. Sound User Interface needs to be taken seriously and to be designed and tested while carefully considering hardware and environmental factors.
  2. In many systems the hardware plays a significant part in the user experience.  Although most of the UX designers do not have industrial design skills, they should strive to fully understand the whole context of use, and to help with defining the requirements for the industrial design.