UX Case Study: Designing an Audio Editing App (explained with Don Norman’s vocabulary)
I am going to walk you through some of the design considerations I took when designing an audio editing app. I will use the UX vocabulary Don Norman introduced in his book The Design of Everyday Things to make things a tad bit more scientific (and interesting). If you are unfamiliar with his book, hopefully this article will give you a sneak peak into his ideas.
The goal of this project was to create audio editing software with collaborative functionality. As with most software that requires a large number of features, key issues undoubtedly were:
a) space management.
b) proper indication of what the user can do at a given moment; in Norman terms: signifiers signaling the app’s affordances.
Signifiers are cues (visual or other) that tell the user what something can do. If you want a good example of a signifier, look at your keyboard. The elevated nature of the keys signals to the user that these keys are, in fact, pressable. Surprise, surprise, they are.
Affordances are what an object can actually do. A mug can hold tea, a table can hold papers, a printer can print.
First steps
One of the first steps necessary in creating a prototype of the design was to decide which features were essential. Space is limited, so some features need to be prominent and others need to be stowed one or more clicks away. My decisions began with a simple question asked from the user’s perspective:
How do I get one of my audio files to playback?
This task should be immediately clear even to first-time users.
When the user first starts a project, only three tracks will be created in order to make room for blank space that reads Drop audio tracks here (Figure 1).
Figure 1.
Though a more experienced user may know that she can simply drop one of her files onto any of the three tracks, this option both tells the user that the app supports drag/drop capability and indicates to the user that dropping an audio track on that very spot will do something. It is not totally clear what, exactly, but it will do something.
Immediate feedback is given to the user when she first drags an audio file over the tracks area.
Feedback, in Norman terms, is exactly what the name suggests. When the user performs an action, the system responds with visual, aural, or some other form of feedback to help guide the user about the effects of her actions. For instance, clicking on a button and hearing a loud and obnoxious beep indicates to the user that that action is forbidden.
In this case, dragging over the Drop audio track here (figure 2a) or one of the tracks (figure 2b) will change the track’s color to a lighter grey.
2a.
2b.
The user takes a gamble and releases the mouse (figure 3).
Figure 3.
The user clicks play and the tracker becomes visible on the screen. As the playback tracker moves, the user becomes aware of what point in time the app playback functionality is currently reproducing (figure 4).
Figure 4.
So there you have it. Good UX methodologies have helped guide the user to use fairly complex feature. Inadvertently, the user has also gained a basic system image of how the app is actually working.
System image is the user’s idea of how an app or technological device actually works. In our case, the user most likely understands that dropping an audio file will register the audio file and its current time placement. Clicking play triggers the playback machine to starting moving in time, and, when its current-time value matches that of the audio file’s, begins playing the track.
What’s so great about a system image?
People, conscious or not, will try to formulate a system image of how a device works. It becomes useful when the user is troubleshooting. What if the user wants the playback to stop? If that user is aware that the play button triggers the playback machine to move forward in time and play the audio files back, she will most likely know that hitting the reverse operation stop will stop the machine.
Users that can fix their own problems are happy users.