TL;DR
If the information architecture (IA) allows it (and arguably, it should), then design the primary functions of the product to be a set of grouped controls accessible at the top-most level of interaction.
Why is a Flatter IA Better?
- It’s easier to find what you need.
- It helps users learn a device more quickly.
- You need a strong mental model so your device can get out of the way of creativity.
The instruments we keep coming back to are often the ones that were easiest to learn, or that otherwise enable our creativity to flow quickly, without getting bogged down by menu-diving or complex setup requirements. One of the earliest parts of the process of using an electronic instrument is to access the primary functions and easily navigate between them.
Some Examples
Hardware Sampler
If you’re building a sampler, your primary functions might be a sample recorder, two sample editors, a sequencer and a mixer. That’s 5 total buttons. Put them together in a place that is very easy to reach. Ideally, place them in a logical order, according to their operations in which they might be used to create a sing: Sample Recorder → Sample Editor 1 → Sample Editor 2 → Sequencer → Mixer.
No controls should be more prominent than these, because these controls will be utilized the most (as users move throughout their process), and these controls are responsible for the mental model of the device, so letting them be prominent builds that model. (Don’t forget that there are many ways other than size to make a control prominent.)
Reverb AUV3 Plugin
To purposefully move to a very different example, take a reverb AUV3 plugin. If you’re building that, then your primary features might be a preset selector and an editor. You’d display those two controls very prominently, but not necessarily the same, since they affect each other directly. You may employ, for example, a skeuomorphic design to indicate that you’re currently editing the selected preset.
While the control for, say, the mix might be a knob-style design and the preset controller might be a dropdown or tab, you should be able to visually and cognitively ‘weigh’ these controls against each other, and the preset should be far more prominent than the mixer. (One old trick I used to use is to take a screenshot of the interface and pull into an image editor, flip it upside down and blur it until I can’t read any text at all—then try to determine the hierarchy of controls. It should be possible with 100% accuracy.)
But I Don’t Have Room!
The most common practical obstacle to this one-button-per-function design is space. As in physical real-estate (on the device itself, it’s display, or a software interface.) There are multiple approaches to resolve this, and this is what I would suggest, in the following order:
1. Re-examine your Feature List or Roadmap
Does your sampler really need a synth engine? Is that really what your users need? The most common cause of obscure menu-diving and Twister-style key combos is feature bloat. Don’t let your product fall victim to enshittification or The Build Trap. The best way to combat this is to develop a deep and lasting understanding of how users actually use these products—as opposed to what they say they want (those are two different things).
Much of the time you’ll find that you’re saving tons of time and money by sharpening the proverbial axe until you’re 1,000% sure that the sampler needs a synth engine. Only then should you build. Organizations sometimes fail because they’re not really in-tune with the needs of their users, and they spend huge amounts of resources developing features and products that aren’t actually in-demand.
2. Re-examine your Information Architecture
I know you’ve already done this, but now you need your IA to work harder. Your needs have changed.
I’m Adding a Software Feature to Released Hardware
This is a slightly different beast. First, I’ll refer back to Re-examine your Feature List. Otherwise, let’s talk about adding features to hardware that’s already in the wild. There are a few angles from which to tackle this topic:
A. Does it Naturally Fall Into an Existing Function?
Sometimes a feature can slot in nicely alongside an existing function. For example, if you’re adding a master reverb effect to a device that already has a master delay… easy. Put it next to the master delay.
When Polyend added the first synth engine to their Tracker sampler, they put the synth engine’s instrument parameters in the same place where the sample playback controls would have otherwise been. This took advantage of the existing mental models so that users didn’t have to learn a weird key-combo or new area of the device.
Pull your attention back up to your existing features overview and examine whether there’s an area this new feature might naturally relate to. That might be the right spot for it.
B. Did you Design the Hardware to Accommodate Future Additions?
If your hardware device has a small display and every button is already labeled, then your device hasn’t been designed to easily evolve over time. The implications of this are not trivial; it’s going to be difficult to add features without causing large amounts of cognitive load. And cognitive load is what causes music technology to be abandoned for simpler, more intuitive alternatives.
If, however, your device has a large display, hardware controls that relate to on-screen content, and a solid IA to start with, then you’re probably not going to struggle very much with adding features.
The trick, in that situation, is to maintain the interaction paradigms that already exist when adding new features. (Again, beware of enshittification and The Build Trap.)
Cross posted on our Medium publication Form & Fader: https://medium.com/form-fader/one-button-per-function-in-music-technology-38b4381135dc
