“My contract is finished, so we need to crack on and get an app published in the App Store. The problem is that REDACTED which we started last year will take too long to finish, but I’ve had a great idea for a really simple app we can bash out in a week or two” — seasoned developer (me) to designer

It is classic; we developers know that we are terrible at estimating, and yet we still underestimate. By a long way. David Barnard wrote a great post back in 2012 about this, and really we can’t blame ourselves too much because not only is coding hard, design¹ is really hard.

“I was sitting at my drum kit trying to practice the songs my teacher has set me, and it was really annoying using the built-in music player on the iPhone” — bad but improving drummer (me again)

Now, with the launch of the new idea Soundproof in the next few weeks, we are more than three months in on what I hoped would be a very quick project. The reason for the large amount of time was that we can’t do things by halves, and we love to design.

This app is essentially a music player designed for specific use cases based around learning and the challenges that can present, for example: difficulty controlling the player with one hand or at arm’s length, seeing where you are in a track or knowing which track is about to start.

I had built a proof of concept in a couple of days, and this made us very enthusiastic, but of course we didn’t immediately appreciate the nuance of interaction that music players possess, nor the complications our specific use-case where we wanted to control what happens between tracks in a Setlist. It should just “do the right thing” but it can take a long time to think about what that right thing is.

An example of the nuance in music player UI is the behaviour when skipping tracks. As a user you don’t think about it but in our case at least, we decided that when the player is playing, track skip should change the track and immediately play it – as most people might expect. However when paused, the track skip buttons merely switch to the track without beginning to play. When you can “select” a track in a UI, skip does not always mean you want to play immediately.

Another very large time sink was the design of the UI for selecting tracks. We went through three completely different iterations of that UI. This was because we were still trying to establish the correct metaphors and functionality, and the iterative process whereby we twice threw away the full working UI we had created was very useful.

I’d still like to improve it further but what we have settled on is the best we can do for now. At some point you have to ship. One thing’s for sure, the default iOS UI for picking media is quite poor when multi-selecting, and offers insufficient feedback about your current selection. We also want to avoid excessive presentation of modal view controllers as this can really confuse users because you lose context with modal presentation on phone-size displays.

Ultimately, this is all testament to the fact that great design has to be iterative, and we don’t believe it is possible to build great apps from a design that was cast separately from development. The two inform each other, especially so if you want to make use of the platform’s idiomatic UI elements. This should be obvious

The irony is of course that this all took longer than it would have taken to finish REDACTED, our existing and more complex app. With hindsight I would have finished that first. However it does mean we will soon have two great apps in the store, and they both meet the criteria of meeting a real need that we know many people have.