5

I am working on a tiny hardware device which has a single LED that can be used to display errors (there are no other outputs). Actually it is a tri-color LED but the red color is dedicated to errors. Hopefully that is user-friendly.

The question is: there are many possible kinds of errors, how to indicate what kind has occurred, and what to do about it? Ideally this should be obvious without reading the manual, based on similarity to other small gadgets/cellphones/etc. At least it should be memorable enough that it would only require flipping through the manual briefly once.

The most common error is that the battery is almost-dead and the device needs to be recharged before being used. This error would be communicated whenever you try to use the device.

Another common error is that the device is not connected correctly to the things it needs to be connected to, and it needs to be re-plugged-in.

There are other (rare) errors which should prevent the device from being used without factory service. It should be clear to the user that this is a permanent/non-user-fixable situation, and they need to call support; and maybe indicate the detailed kind of error in this case (let's say there are ~15-20 possible kinds) in a way that is readily described over the phone so that we can get some information about failures from support calls.

Note: the device has a tri-color LED (all colors independently dimmable and blinkable) and three buttons; that's it as far as available UI :)

3
  • 1
    I guess the other problem with this is the you must also be able to describe the signal unambiguously in a manual
    – Ewan
    Commented Apr 26, 2015 at 13:12
  • 1
    Having users learn to understand your blinking light is a bad solution (all intelligent devices should have wifi) but I know you may not be able to change it so... Green = working, solid yellow = charge, blinking yellow = fixable error, red = won't function. This keeps things simple at a glance. I would look into having an app interpret the code - user videos flashing led with app and server software or people interpret the code and notify user in app.
    – moot
    Commented Apr 27, 2015 at 14:24
  • How many distinct errors in total do you need to account for?
    – DA01
    Commented Apr 27, 2015 at 15:59

6 Answers 6

6

Many computers use beep codes when they start up, as at that point, all that is available is the system board -- there may not even be a display unit.

A similar system could be used with blinking the LED in groups of flashes; use one flash per second for the most common (low battery), then a group of two flashes with a distinct gap between groups, and so on.

You may need to do some research into the largest number of flashes in a group which can be comfortably counted. It's probably five.

For an unrecoverable error, just show a steady red light. Or, if you already use a steady green light then to signal an error use a steady red light which flashes off briefly, perhaps every four seconds. Red/green colour-blind users will need to be able to distinguish the error condition.

In an unrecoverable error condition, a press on a button might cause a sequence of coloured flashes, say a number of yellow followed by a number of green followed by a number of red. This would allow a detailed error code to be indicated. With three colours and a maximum of five flashes and a minimum of one (to keep the group and colour-sequence intact), you have 65 possible codes. Even red/green colourblind users will be able to distinguish the different sequences, but you may need to do some research to determine which colour is likely to look brightest.

2
  • Could you use morse code ?
    – PhillipW
    Commented Apr 26, 2015 at 22:45
  • @PhillipW Could do, but that's far more difficult to interpret and relay over the phone to a service engineer than simply counting flashes of different colours. Commented Apr 27, 2015 at 9:06
5

Well personally, I think usability-wise, LEDs are among the worst to inform your users of a particular error.

Modes

Now to deal with that problem in the best possible manner. You have 3 clearly distinct modes (actually 4, 'off') to distinguish errors:

  • Fast flash
  • Slow flash
  • Solid

There are some in between (i.e. a slower phasing, alternating light) but those are less obvious and definitely not as memorable.

Recomended settings

In my opinion you should set it like this:

  • Fast: Connection problem
  • Slow: Battery low
  • Solid: All of the other issues

To elaborate on the 'solid' state, if you want to actually be able to differentiate the range of errors you could interrupt the solid state by blinking an x number of times. Of course, these have be documented in the manual.

Example:

solid - 1 blink - solid would mean x

solid - 2 blinks - solid would mean y

...

2
  • I like your idea, fast/slow/solid is certainly easy. "LEDs are among the worst to inform your users of a particular error" - what would you suggest? That design isn't totally set in stone, but there isn't room for an LCD, not even a really simple/tiny one. The Fitbit is downright roomy compared to what we're working with :)
    – Alex I
    Commented Apr 27, 2015 at 10:46
  • Well, I just meant that making it more user friendly is tricky, not impossible. Sometimes there just isn't an alternative, but going smaller almost always means you're going to sacrifice some semi-crucial UI elements. I do love a challenge though :)
    – Vince C
    Commented Apr 27, 2015 at 10:53
2

Very restrictive scenario, but if you're going to persist with such an interface the manual will need to clearly show the relating codes.

I would suggest two groups of flashes as such, with a maximum of 5 flashes per group, you can [almost] easily display 20+ errors.

I don't think I've made too many errors here, but you could tap out the codes to ensure they are recognisable.

Error Codes

1
  • 1
    +1 for solving the complex error reporting described in the question. There is no reasonable solution to both complex reporting and "Ideally this should be obvious without reading the manual". Pick one path or the other. Commented Apr 27, 2015 at 16:01
2

The difficulty is that you're trying to portray 2-dimensional information (type of error against the time it happens) using a single dimension (light on/off over time). As others have pointed out, if possible, find another way. WiFi and a web interface is probably a good one.

If you must use a single LED for multiple errors, I would suggest as follows:

  • A slow blink (1 second on, one off) for low battery. I can think of a few devices around my house which use this convention, albeit with the power light.
  • A fast blink (1/4 second) for connection issues which require immediate attention.
  • A short-on-long-off for a non-critical warning.

I would avoid an always on, because it'll be ambiguous: does on mean there's a problem, or everything's ok?

1

None of the answers used "dim" information. My suggestion:

Low battery - slowly dim in and out. Represents "sluggish performance" due to weak battery.

Re-plug - short blinks in rapid succession (4-6). Represents "something's wrong" signal.

Suport call - combine long/short/space blinks (like Darryl suggests) but only after some special button press (when asked by support person) for example long press of two or all three buttons.

0

You have basically three types of errors :

  • No battery

  • Not connected

  • Need assistance

The most common are the 2 firsts, the third part is well covered in other answers so I will let you refer to them.

You have 3 LEDs, let say they are green, orange and red.

A signal with the three appearing in loop (green->orange->red...) can be a low battery signal. It is easily memorized because of the battery convention : red for full, orange for low and red for critical.

Since all solutions recommend flashing led, a red led not flashing could be a connection issue.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.