Since I started working as the designer here at Rogue Amoeba in 2015, I’ve contributed to several major updates. However, our new soundboard app Farrago is the first Rogue Amoeba app I’ve designed from the ground up.¹ The design process for a new application is very involved, with countless discussions, hours of research, and even plenty of guesswork. A long sequence of hundreds (or even thousands) of little choices is required, with each decision impacting choices made later on. Ultimately, designing a new app feels more akin to pruning a bonsai tree than to simply drawing a picture. The design lives and grows in ways you can’t always predict.

Planning for Farrago began in 2016² with a simple pitch: “We want to provide users with a fast way to play short audio clips”. Building on that, we prepared a rough list of features the app would require, including basic playback, looping, volume control, and much more. With that, we began to flesh out what the app would look like, and how it would work. Farrago went through many iterations to get to the version we shipped late last month. I thought it would be interesting to share a look at a few different parts of our design process.

Early Sketches

From its very first mock-up, Farrago focused on easily arrangeable tiles. The rigidity of other grid-based interfaces was something we wanted to avoid. While many things changed from my initial sketches, there’s still a clear resemblance to the Farrago we shipped almost 2 years later.

The earliest sketch of Farrago I could find. The top bar and tiles were present from day one. The idea of sets on the bottom was abandoned not too much later (phew!).

Early on, we also decided we wanted to split the app into two modes: a nonlinear mode shown as a grid, and a sequential mode shown as a list. To quickly work out a basic transition between the grid and list views, I used Keynote and its indispensable Magic Move transition. This ultra-fast tool provides a quick sense of how an idea will work (or fail).

The five-second movie above shows the first mockup of the transition between grid and list views. We eventually went one step further, making the tiles follow arced paths that don’t overlap as much while transitioning.

Tile Troubles

Farrago’s UI is built around tiles, with each tile containing a single audio file to be played, along with many controls and settings for playback. My initial planning had each tile’s face containing multiple click zones to enable different functions. These early drafts show different click areas for playback, ducking, scrubbing, and editing settings.

Assorted sketches of sound tiles, with controls on the tiles itself.

A good amount of time was spent tweaking the layout of the tile face, but the ideas were all excessively busy. These sketches were fussy, filled with too many click areas and tiny icons. The design went in circles, as I repeatedly tried to cram the functionality I wanted on the tile’s face. We wound up stuck on how this critical aspect of the design would work.

There were a lot of conflicting sketches like this. We couldn’t decide how to proceed.

Ultimately, we realized tiles with multiple click areas were a dead end. Getting there, however, actually required us to reevaluate some of our base assumptions for the app.

User Interviews Cut Through the Clutter

Despite a key element of the app being up in the air, work was progressing in many other areas. Eventually, I knew we needed to figure out a way to solve the problem of how tiles would look. To break out of my rut, I decided to bring in outside viewpoints.

I reached out to my social network here in Montreal, and sought out the sort of people who might use a soundboard app — podcasters, radio folks, theatre techs, and more. I bribed several of them with free lunches, during which I showed them mockups and got their responses.

The feedback I got was immediate and consistent: Prospective users didn’t want to rely on a mouse or trackpad to play clips at all! They wanted to use their Mac’s physical keyboard to play sounds. Though I’d been focused on providing access to many controls right on the tile face, it turned out that mouse-based controls should be secondary.

This pivotal insight gave us a clear path forward, and in fact, it now forms the basis of how we expect Farrago to be used by most people. At this point, we decided the tiles would be mapped directly to the keyboard, and this would be the primary way to trigger sounds. Rather than being cluttered with on-face controls, each tile would consist of one large click area. A simple click anywhere selects the tile, while a double-click provides an alternate method of triggering playback.

The final tile design is all one big click area.

This change led us to move many secondary controls into our Inspector area. In that location, they’re still easy enough to reach, without being obtrusive.

The inspector in its final form.

Close(r) to Complete

At this point, my mockups really started to resemble the Farrago 1.0 we eventually shipped. The keyboard-focused interaction model seems clear to us in hindsight, but it took a serious amount of work to arrive there. The outside feedback we solicited was invaluable in helping us move forward.

A mock-up from spring 2017 that pretty closely matches the final design.

Zooming in on this mockup will show you the ridiculous placeholder names nobody was ever meant to see, such as “Onions” and “Fudge”. Ugh. You’ll also see the code name under which Farrago was developed: Iron Beetle.

The above mock is similar to our final product, though we still made many smaller adjustments and tweaks after this. The value of outside feedback continued to be proven during our private beta period as well, as testers forced us to reconsider more of our assumptions, and make changes based on real-world usage.

While our design was getting pretty close to what we eventually shipped, actually getting it all coded and tested would take many more months of work. From this point though, the design work was more about making things look nice, as well as solving smaller functional nitpicks.

Farrago’s Icon

After the design was largely complete, I took some time to work on nailing down Farrago’s app icon. While the design of the actual application is crucial for long-term use, the application’s icon is often the very first thing people see, and we all know how much first impressions count . Ideally, the icon should be distinctive and pleasing to look at, while also conveying something about the software itself. Farrago’s icon went in several different directions before arriving at its final form.

Most of the iterations riffed on the general idea of tiles and playback in some form. Here’s an assortment of different sketches I toyed with:

Very early rough sketches done on paper or iPad.

A key part of my design philosophy is to put designs in place as soon as I can. I created icons from these early hand-draw sketches, so we could use them in early builds of Farrago. This way, we could see how well they worked in places like the Dock.

One of the very rough hand-drawn drafts actually being used in the app.

Later designs began to look a lot more like what we eventually shipped. The final icon design started out purple, temporarily took a sidetrack into a rainbow neon phase, and ultimately returned to our toned-down final purple shade.

The design on the left looks pretty similar to the finished icon, while the design on the right shows a temporary experimentation with neon colours.

Icon design is less scientific than application design. While feedback on icon designs is useful, in the end it makes sense to just go with what feels best. After numerous iterations, we landed on the final Farrago icon. It’s not too flashy, but its distinct shape and colour make it easy to differentiate.

The final icon design is quite a bit more subdued than its livelier neon predecessor.

A Team Effort

I led the design for Farrago, but I was very lucky to be able to work with fantastic teammates. No designer wants to hear that their design is “impossible” to implement, particularly when the developer actually means it’s merely “impractical”, or even just “difficult”. Farrago’s lead developer Grant never once backed down from hard problems I threw at him. In fact, he frequently went the extra mile to make the Farrago interface really shine.

To show just one example, we could have only allowed dragging tiles into open spots on the grid. Instead, tiles dynamically rearrange themselves when needed, to make space.

As a result, you can do ridiculous stuff like dragging 15 tiles at once, and it just works:

In addition to Grant’s great work, Rogue Amoeba co-founders Quentin and Paul did everything they could to help the project succeed. They served as the final decision makers on the app, but they also gave us the time and space needed to complete the project, while keeping distractions to a minimum. Working as an ad-hoc team of four, with one designer, one developer, and two “editors”, proved quite successful.

Beyond 1.0

After many months of work, Farrago shipped to the world on January 24th, 2018. We’re very happy with the 1.0 version of Farrago, but we also look forward to making it even better. At this point, the design process will be more externally influenced. More and more people are using the app in real situations and giving us great feedback.

Over time, we’ll gather more data and discern trends in how the app is used, and how it can be improved. I’m looking forward to the next iterations of Farrago’s design. For now, we hope you’ll check out the first version of our new soundboard app, and keep an eye out for updates as well!

Footnotes:

1. In an amusing coincidence, this is not the first app I’ve worked on with the name “Farrago”. That distinction belongs to a now-defunct augmented reality app. ↩︎

2. The idea of a soundboard app from Rogue Amoeba was actually several years old at this point. Prior to my joining Rogue Amoeba, development was done on a soundboard plugin for Audio Hijack called QuickSounds. This work never made it past the early stages of development. In fact, I didn’t see it until after Farrago shipped!

   QuickSounds in all its glory, circa 2011

   While this app didn’t influence my own thinking directly, years of folks at Rogue Amoeba mulling the idea undoubtedly helped our final product. ↩︎

We unveiled Audio Hijack 3 to the world last month, but it was almost six years earlier that I downloaded Audio Hijack Pro for the first time. I was doing contract work for Rogue Amoeba in September of 2009, hoping to get hired full-time (spoiler alert: I got the job!), so I wanted to familiarize myself with their full software lineup.

“Awesome,” I thought. “I’m going to love this application, and I’ll really be able to use it to its full extent, thanks to those audio recording classes I took in college. See, Mom, Film Production was a sensible major!”

That first launch was intimidating, though. I could tell immediately that Audio Hijack Pro was a sophisticated piece of software…but I had no idea where to begin. The manual was a huge help, of course, but I still felt like I was up against a steep learning curve. I wasn’t alone in that feeling. Audio Hijack had long provided users with an incredibly powerful, but often challenging, solution to their needs.

Co-founders Paul and Quentin knew there had to be a better way to present Audio Hijack’s wide range of capabilities, and they’d been kicking around ideas on how to improve the design and experience for quite some time before I joined the discussion. Visually designing a software application that revolves around something inherently non-visual—like sound—is daunting. The immediate impulse is to lean on idioms and affordances from existing audio hardware (as our charming and easy-to-use Piezo does). The more complex a task becomes, however, the less convenient it is to refer to these real-world devices, which themselves can have steep learning curves and be a chore to use.

Software like Propellerheads’ powerful-but-complex Reason is based on analog devices
[Photo credit: possan]

Saying Yes to Nodes

Quentin was the first person to suggest a node-based design approach for Audio Hijack 3. He and Paul both liked the idea of starting with the audio source you wanted to capture, hooking it up to various effects, and ending with a recording file node.

My initial response was something along the lines of “absolutely not”. Having used the node-based applications Quartz Composer and Shake, I imagined Audio Hijack users dealing with a hairy web of randomly-placed, text-heavy rectangles connected by fiddly, intersecting lines and a general sense of chaos.

The complex interface of Quartz Composer

Even if this style of interface made the application more flexible and powerful, this was not my idea of an improvement. Fortunately for all involved, my protests were ignored. “We’re doing nodes,” Paul said. “We’ll just have to make nodes easier to use.”

And so we worked our way through many different designs. We eventually settled on four basic types of blocks which would automatically snap together when dragged to a grid. The blocks themselves went through many iterations, with various methods for connecting and showing the flow of audio. We finally arrived at the idea of blocks auto-connecting via “pipes”, which would then show a live spectrogram as audio moved through the pipeline from left to right. Here are some early mock-ups showing that evolution. (I’m just as appalled by Past Christa’s design choices as you are, I assure you, but in her defense, these were closer to wireframes than true mock-ups.)

A very early Audio Hijack concept design (Oof!)

We also spent quite a lot of time on the button which initiates audio capture. While Audio Hijack Pro had differentiated between capturing (“hijacking”) audio and recording it, we eventually settled on a single button for Audio Hijack 3 to activate the entire pipeline. Adjacent text in the LCD details what’s happening in the grid.

A later Audio Hijack design with a rectangular “Run” button
and 50% zanier color scheme

The blocks above are color-coded by block type. While this helped differentiate between various blocks at a glance, it was decided to be overwhelmingly colorful and a bit too whimsical, so we shelved the idea. Perhaps it will find its way back into a future version of the app, though!

After many more iterations, we got to our shipping design, seen below:

Audio Hijack 3.0, as she shipped

A Unified Home, A Stand-Alone Audio Grid

I originally wanted all of Audio Hijack to exist within one window, with tabs for Audio Capture, Schedule, and Recordings. I quickly realized that this was just too complex, cramming far too much into one place.

A concept combining the audio grid with other sections of the app

Instead, we created a unified Home window, with tabs for Sessions, Recordings, and Schedules. The Home window provides a place to work on tasks related to all Sessions, while each individual Session opens in its own window for active use.

The Home window’s Recordings tab

IT LIVES!

Another huge component of the design was the use of subtle animation throughout the application. Audio Hijack 3 feels responsive and alive, thanks to the way the blocks pop and grow as you drag them from the Library, how they slide and snap together, and even the way they jump off the grid when deleted. Lead developer Grant was able to breathe life into every interaction within Audio Hijack, and the overall effect is delightful.

Deleting and un-deleting audio blocks in the grid

Streamlining Common Tasks with the Template Chooser

Even after all our work on the node-based design, we knew that jumping into a completely overhauled Audio Hijack interface might be confusing for veteran and new users alike. Thus, Templates were a key feature of the app from the outset, with the aim of making it as simple as possible for users to get to their task. As a bonus, Templates also serve to suggest additional uses for Audio Hijack.

Left: An early concept for Templates; Right: Templates in Audio Hijack 3

Capturing Sound in an Icon

A wholly re-imagined application, Audio Hijack needed a re-imagined icon, too. I tried to conjure ideas that would illustrate the concept of “capturing audio”, and even returned to an old Piezo idea of catching a sound wave in a net (which several people have said looks like a ham at first glance).

A few sketches of icon ideas

We settled on a “jar of sound” concept, like something from a sci-fi laboratory. We still had more work to do, though.

Some versions of the “jar of sound” idea

We worked through many variations, starting with a sound wave and landing on representing sound as a sort of glowing ether in a stoppered glass jar. Of course, a glowing ether isn’t immediately recognizable as sound, so the jar needed a label. After a few iterations, we arrived at the bar-type spectrogram:

Audio Hijack’s final icon design

The Long and Winding Road

Because Rogue Amoeba is a small team, we’re continuously working on all of our applications. This massive update to Audio Hijack has been literally years in the making. In 2014, we made a major push to finally finish it and send it out into the world. Just a couple of weeks into the new year, we finally accomplished our goal.

The reception for Audio Hijack 3 has been the most positive I’ve experienced in over five years of making software with Rogue Amoeba. It’s been incredibly gratifying to hear from satisfied users. The path to Audio Hijack 3 was long, and at times it resembled a nest of interconnected Quartz Composer nodes. Ultimately though, it was a fantastic journey to make our flagship product visually intuitive and, with any luck, fun!

Powerful and flexible enough for all kinds of tasks, Audio Hijack Pro has been the go-to application for audio recording and manipulation on the Mac for years. But with its power comes complexity, and we’ve long wanted to give people a streamlined way to record any audio on their Mac. More recently, we also wanted to test the waters of the Mac App Store. And so the idea for Piezo was born — we decided to make audio recording on the Mac simple and fun for everyone.

Grant had just joined our team, and Piezo was the first project we worked on together. It was also the first app I designed from the ground up here at Rogue Amoeba. Exciting! So here’s a rundown of how it progressed, from the early sketches to the final shipping product.

The very first interface was a work of programmer art, humble but functional. After coding up the application’s backend and getting things working in a basic state, Grant gave the GUI a working first pass:

Grant’s Primordial Piezo

As you can see, the title bar hints at Piezo’s origins. But “Simple Audio Hijack” was just a placeholder name, keeping the seat warm until the day our friendly support technician Chris suggested we call it “Piezo.” Anyway, that’s what the app looked like the very first time I used it. After playing with this tech demo a bit, the team got together and hashed out the scope and functionality for the true version 1.0.

We wanted the app to be obvious, convenient and fun. I knew from the beginning that I wanted it to have analog VU meters with bouncing needles, a clearly-labeled source selector, and a big, friendly record button. I also knew I did not want multiple buttons for simple recording options. A binary system was far preferable to the unnecessarily complicated array of options you see in, say, elevators in two-story buildings¹.

The First Piezo Wireframe

I laid out everything in descending order of importance in a simple wireframe. From the top, there’s the audio source and big friendly record button, then the recording settings, recording name, and time counter. The VU meters are at bottom, along with stripes on the lower right which would eventually be speaker lines. These were a nod to the fantastic Braun radios designed by Dieter Rams, like the RT-20 which ultimately inspired Piezo’s black front panel and wooden frame:

I love the RT-20’s simple face and contrasting wood and black plastic.
Photo courtesy of Teddy

After the initial wireframe was accepted, I started work on a more sophisticated rendering of the app. While searching for various examples of VU meters upon which to base my own, Grant suggested we move the meters to the top of the window, and I immediately agreed. It was such a simple and obvious idea; I had put them down below because it seemed the audio source and record button were the things to focus on, but looking at analog devices, I saw that the meters were consistently the most prominent feature. With the flow of the app shifted slightly, I also moved some other things around and began to play (haphazardly) with textures:

So now we had something that looked like Piezo. Of course, cringing looking at this now, some problems immediately stand out to me:

The iterations continued, and I played with adding the wood frame and changing the color of the hours and minutes portion of the time counter:

This was closer, but this walnut texture was no good, coloring the “Hours:Minutes” section of the counter wasn’t working, and the rough texture I gave the plastic was all wrong. Next:

After a bit more fiddling with colors, textures and overall brightness, I was happy enough with this to ship it. Looking at it now, there are so many things I’d like to improve. I’d love to take another crack at the plastic texture, and I’d widen the counter (the numbers are just slightly off-center, due to differences in how OS X and Photoshop render text²). I also want to work with Grant on improving the settings popover, to better integrate it with the rest of the app. The great thing about software is that it’s never really finished, so I can keep tweaking these pixels for future updates.

I had to stop somewhere, though, and it was time to move on to the icon. I sketched some ideas and used a high-tech scanner (i.e. my iPhone’s camera) to pass them on to Paul, Quentin and Grant:

I still like the net-catching-soundwave idea on the left. With all of the audio capturing we do, I just might get to use it for another app some day, so don’t go stealing it. The middle one is a reference to the name “Piezo” (which comes from piezoelectricity) as well as Superman’s Fortress of Solitude. We decided the one on the right was the best for Piezo, though, and I set to work on it.

Umm…nope. Nuh-uh. These were definitely not good. This was a problem, because while we all liked the concept, for use on Mac OS X, the icon needed to approximately fit into a square, making the face way too tall (regardless of whether I emphasized the VU meter or the record button). Oy vey! I went back to the reference images I had originally collected, and realized what it needed:

A handle!

The handle made all the difference. It totally solved the height problem while keeping the icon square. Success! After a few more tweaks, the final version looked like this:

With icon and interface finalized (for now!), we continued to test and tweak the app until it was ready for release.

So there it is, the process from programmer cut-and-paste art to a final, shipping app. Piezo was a super fun project, and I look forward to continuing to improve it – I have tons of ideas for it. For now though, I hope you’ve enjoyed this tour through the evolution of Piezo, and I can’t wait to show you our next project. Soon!

Until then, check out Piezo now!

Footnotes:

1. If a building has only two floors, an elevator only ever has one travel option (to the floor opposite the current one), so why even bring the numbers “1” and “2” into it? Not to mention that the “Close” button never responds, “Open” is pointless – ARGH!

In Alice’s world, “the books would be nothing but pictures,” and in mine, elevators in two-story buildings would have no buttons at all. When passengers stepped in, the doors would close, the elevator would move to the opposite floor, and the doors would again open. I can see a case for keeping the button marked “Alarm”. Maybe. ↩

2. Why doesn’t Photoshop use OS X’s font-rendering? Who knows! ↩