Most manufacturers have a relentlessly optimistic view of their products. I think you’d have to have that type of personality to get into the manufacturing business at all — but that’s a subject for another time. What interests me today is something simpler: the difference between how the manufacturer sees a product or a specific feature and how the end user sees it.
By the time a product (talking here about music technology, a subject that I’m fairly familiar with) reaches the market, the manufacturer has spent a year or two developing it. The manufacturer knows the product inside-out and upside-down. They can use it quickly, easily, and intuitively. Yet they may have strayed into disastrous design choices that will baffle or hobble the user.
Quite often, the manufacturer simply doesn’t see that a given feature is badly designed. Not only is it easy for them to use, but they made those particular design choices for reasons that seemed cogent and compelling to them at the time. Admitting to yourself that you made a mistake — not so easy. Add to the equation the sizeable emotional and financial commitments that you’ve made in developing your lovely new product, and trouble may be brewing.
One of my favorite examples comes from the very early days of MIDI-based software. Some manufacturer (it may have been Hybrid Arts) had released an editor/librarian program for the Yamaha DX7. In his review of this software in Keyboard, Dave Frederick raved about it. What I noticed, while peering over Dave’s shoulder, was that if you were editing a patch and wanted to save it to disk, ten separate keystrokes were required. You couldn’t just hit Ctrl-S, you had to navigate through several menus and pages to reach the Save page.
I was too new to the subject of software ergonomics to insist that Dave tone down his review — and in any event, that boat has long since left the harbor. The point is, the software was designed in a horribly obtuse way. Yet the manufacturer seemed to be entirely oblivious to that fact.
This subject came up in conversation last week because I’ve been writing an owner’s manual. I’m not going to say what the product is. On the whole, I think it’s a swell product at an attractive price, and it will probably do very well in the market. But the U.S. distributor (who hired me to do the manual) thanked me for pointing out issues that needed to be addressed in the design. He had brought up some of the same issues with the manufacturer, and he was happy that I was rattling their cage and encouraging them to tidy up a few non-trivial loose ends.
When writing a manual, I have to put myself in the end user’s shoes. I try to ask myself the questions the end user will ask, and then I make sure the manual answers them clearly. When I don’t know the answer and have to go back to the manufacturer and ask, that may be their first opportunity to get feedback from … well, not from an actual end user, but perhaps we could say from a virtual end user or a modeled end user.
I’ve seen this type of problem over and over in the music industry. Last year, for instance, I wrote a review of the C-Thru Axis. I’m interested in alternate keyboards, and I thought their hexagonal grid would be worth checking out. What I discovered was that the assignment of MIDI note numbers to the buttons in the grid was not user-programmable. They had chosen a note layout that they thought was optimal (a subject that is somewhat open to debate), and when you flipped out your credit card, what you got was the layout they thought was right for you.
They have since released a new, stripped-down model that has MIDI-assignable hex buttons. However, it lacks the other features of the Axis. I’m still baffled. Why didn’t they just upgrade the OS of the Axis so it would be more usable?
I’m not trying to single out C-Thru here. This type of thing is pretty darn common in the music industry. Even companies like Propellerhead, who put a lot of effort into designing a good user interface, can stumble from time to time. Yesterday I decided to put together a new tune in Propellerhead Reason. (Reason 5.0 is due out next week, and I’ll be reviewing it for Keyboard, so I wanted to get a head start.) I wanted to change the time signature after the intro. I couldn’t find a button for doing that in the user interface. Choose the pencil tool and click in the Transport track? Didn’t work.
The Help file was no help, so I dug down into the C: Program Files directory and found the manual. (Manual can’t be launched from the Help menu … that’s a separate issue.) Turns out there is no user interface button for activating the automation of time signatures. What you do is, you Option-click on the time signature field in the transport bar — that’s how you create a lane in the Transport track for inserting time signature changes. Once you’ve created the lane, the pencil tool works as expected.
This is not a laborious procedure; ten keystrokes are not required. But it’s sure well-hidden. It’s not visible in the UI at all.
The point is, I’m sure the folks at Propellerhead think they’ve implemented a simple, obvious way to add time signature changes. But their view from the inside is not necessarily the view that their end users will have. Again, not singling out Propellerhead for abuse here; I happen to like Reason a whole lot. I’m really just riffing on Robert Burns: “O would some power the giftie gie us to see ourselves as others see us.”