Weighing Defaults vs Discoverability

An anecdote:

Having lost sound in one ear of my earbuds, I dived into my stash of electronic odds-and-ends and snatched a new pair of cheap wired earbuds. I had, of course, Zoom meetings to attend.

A while back, I started picking up cheap earbuds here and there ad-hoc, having only one purchasing criteria: they must have an integrated mic for meetings and calls. So like any pair I’d owned since, they had a small bulge on the cord for the mic.

Like a normal user, I didn’t read the packaging beyond a quick scan for my one top-of-mind criteria: microphone.

Fast forward, after a day of using this new set, I was ready to toss them in the garbage. Why? I had trouble hearing my colleagues very well – they sounded so unusually quiet. Turns out I had more than one criterion, an even more basic one: hearing. I fiddled with my normal troubleshooting steps I’d had for previous similar earbud sets: make sure it’s plugged in firmly, the volume was up on my MacBook, and the volume was up in my application.

It wasn’t until day two… and sort of by accident… that I noticed this set had a volume slider on the cord where I assumed only the mic lived. Only laziness had kept me from tossing this brand new set before that revelation.

The Moral of the Story

This may sound like a typical case of PEBCAK – problem exists between chair and keyboard – and yeah, checking the device for extra controls along with my troubleshooting steps would have solved this, but the point is, I had an “extra” feature I didn’t expect that caused more damage than good because as a user I did not factor it into how I was supposed to interact with the device.

The device’s problem was not that it was too extra (the sound volume slider is pretty neat!), it was that I had no clue about this factor and it was impacting my experience getting my base criteria met.

Takeaways

  • Defaults should be set carefully and intentionally and weighed against discoverability. If you can achieve both, by all means, do that – but do not force a user to adjust defaults just to ensure they run through their options – default for the 80% use case scenario or risk user frustration.
  • If your new setting/option/feature does not need to impact the user, it should not. How important is it for me to know I can adjust volume versus avoid thinking my device is broken?
  • Think about how a change could negatively impact a current user, or a first-time-user experience. If the device default volume had been set at 100%, the problem would be averted.
  • Most users will take minimal (if any) troubleshooting steps, and if they are taking troubleshooting steps it is under the context of things they know, and may leave out pieces yet undiscovered. If they are troubleshooting, it is safe to assume they are also already frustrated.
  • A feature that is “standard” for you may be new to your user. Anything outside of very MVP maybe be something extra they haven’t seen before. Be sensitive to that to make it a win instead of a point of confusion.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.