Posts Tagged ‘glossary’

The meaning of Life, or at least, of words

Wednesday, March 25th, 2009

Federico Fellini, the Italian film director said “A different language is a different vision of life.” I find this rule applies to spoken dialects, but also to the differences in the language used by engineers and that used by their customers or end-users. I have written previously about the usefulness of a glossary when working on user interface design, or any engineering project (http://www.embedded.com/columns/murphyslaw/53700319). If the team are careful about defining the terms the engineer’s use, it also affords them the opportunity to decide which terms should be visible to the user, that is the terms that appear on the user interface or in the user manual. The term ‘signal’ might have meaning in an engineering design document, but mean nothing to an end-user. On the other hand the term ‘message’ may have a well defined meaning, within the scope of the product, for both the engineer and user.

On one project we had a customer complain about certain features that they wanted to work during low-power mode. With a small bit of effort the engineers added some configuration flags to turn on some outputs that were normally off during low-power mode. The customer received the update, but was still not happy. More flags and features were enabled but still no success.

The reason we were failing to satisfy the customer is that we were interpreting the term ‘low-power’ in the way we had defined it internally within the team. The processor had a low power mode, where the main software loop was not running, and the processor only woke up occasionally. However the customer had no understanding of CPU cycles and the like, in fact the customer did not know or care that there was a processor in the product. To the customer, ‘low-power’ meant that the LEDs on the front of the box were not lit, so it looked like it had been turned ‘off’, in some sense.

We finally satisfied the customer by providing a button that turned off a set list of outputs and turning off the LEDs on the front panel. The LEDs remained off until there was some further interaction with the device. The device never actually entered ‘low-power’ mode (as the engineers interpreted it). This was fine as the outputs that consumed most of the current, were turned off. In terms of current consumption, the difference between the processor running its full loop or going to ‘low-power’ mode was negligible.

So the customer continued to call it ‘low-power mode’ whenever we turned the LEDs off. Ideally we should have come up with another term for it, since it was bound to lead to some confusion later. While you do not want to take a George Orwell style control of your customers thinking by dictating what words they are and are not allowed to use, resolving ambiguities will ease the path for everyone.

So the next time a customer uses a term that you engineers have very strictly defined, stop and think about whether that is the same definition that is in the customer’s head.