The concept of user centered design usually sounds good to people, but what does it really mean? How do you build a product starting from user needs then working ahead from there? I’d like to demonstrate an example of this as it applies to creating a purpose built electronic device for myself.
I’ll warn you up front: this discussion and its back story requires that I detour from time to time into the arcane land of electronic musical instruments and music software. Bear with me; I’ll try to keep the detours brief and relevant.
A few years ago I became interested in the idea of constructing a customized MIDI controller to use with a piece of software called Live, made by a German company called Ableton. Live is more or less an audio playground; it’s purpose is to give musicians and DJs a great deal of real-time control over music production and playback, and it offers very granular control of music events and special effects. Ordinarily this software is controlled with a mouse and keyboard, but my thought was to build a more intuitive and more musical interface for it.
While researching the various ways I could build this device, I discovered several products made by Doepfer. Doepfer (also a German company) produces a number of electronic musical instruments and related technology, including these interface cards which enable the do-it-yourself hobbyist to connect switches and potentiometers to a circuit board to control musical instruments and software via the MIDI standard (MIDI is short for Musical Instrument Digital Interface). What’s interesting about the Doepfer product is that there are literally thousands of different electronic devices that can be attached and converted to MIDI data, so the sky’s the limit in terms of building a device that exactly meets your needs.
So now I had an idea and a technology that could enable it. The next step would be the user interface design. I approached this project using a fairly basic user-centered approach, which was to:
- Define the user goals
- Determine high probability use cases
- Design an interface that would best serve the key goals and use cases
- Develop a prototype
- Test and refine
- Build
As I’ve mentioned I already had a user goal: control MIDI events using something other than a keyboard and mouse. The next step was to determine how I’d be using the software; in other words determine the highest probability use cases for the controller I would be building.
Of course I knew right away I’d need a way to start and stop the music. There were other related functions to consider, such as telling Ableton Live when to begin repeating a segment of music, and when to stop repeating. There was also a need to tell the software when to switch over to a new section of music (known as “launching” in Live parlance). All these functions had one thing in common: they were all part of the basic “transport” controls of the software the term comes from the “transport” controls of a tape deck, like fast forward and rewind (you do remember tape decks, don’t you?).
Since the transport is essentially the gas pedal and brakes of the software, I decided it needed to be very prominent in the interface, and that the most important functions needed to have shapes that would be easy and quick to identify. I also wanted the transport controls to be visible in the dark, in case I ever wanted to use the controller on a dark stage. So for this part of the interface I sourced oversized backlit buttons designed for arcade games and slot machines. For the “Stop” function I used a large square button with a red lens. For “Play” a big green triangle. For “Previous” and “Next” loop functions two blue triangles, oriented pointing up and down.
The next highest probability use case I identified was the need to adjust what are known as continuous controllers. Put simply, continuous controller data is a type of MIDI information that is used to change things like the volume of a sound or the amount of an effect – in other words, parameters that aren’t just on or off, but have a lot of “in between” settings. I wanted to be able to control many different parameters at once, so multiple dials and joysticks were called for (I like joysticks on musical instruments and feel that most electronic instrument makers don’t make enough use of them). I decided that I wanted the instrument to have a minimum of 10 continuous controllers – 7 joysticks and 3 rotary dials. Finding these parts was difficult but I eventually sourced them from a large electronics distributor in Sweden.
Other elements of the UI were chosen with the same basic methodology: if there was a high probability user need, it was translated directly into a physical function on the front panel.
Once I’d addressed what I considered to be the most vital needs for the device and matched the need to an interface element, I began creating a panel layout in Photoshop. This process took a fair bit of time, since I knew upfront that some items needed to be physically located in a specific space – for example, I wanted “Stop” and “Play” buttons at the top right. After many iterations I finally ended up with the panel design you see here:
…and here. It’s admittedly not beautiful (that wasn’t part of the spec!) but it certainly isn’t frightfully bad either. It does exactly what it needs to – brings the most necessary control functions right to the user’s hands and into logical places within the user’s field of vision.
Chess board photo credit: Fr Antunes. Creative Commons licensed.
Related posts: