Dev Diary #3— Lessons learned from building Ambie 2.0

Daniel
5 min readJul 30, 2021

Four weeks after the launch of Ambie 2.0, it’s time to reflect on how we got here and the challenges that had to be overcome.

Before diving in, though, I want to celebrate the outstanding reception for Ambie 2.0. Here are some numbers since launch:

  • Monthly active users — up 100%
  • Number of sounds played daily — up 300%
  • Over 6000 hours of playback
  • Global rating of 4.8 stars out of 5

On top of the numbers, here are some testimonials

I’m humbled by how much people are enjoying the app. From its code to its UI, users appreciate the quality of this major update. But it took some growing pains to get here.

Lesson #1 — Discovering Ambie’s core purpose

It seems odd to use “discover” to describe this, but it’s precisely the growing pain I went though. After releasing v1 of Ambie, my mission was simply to play white noise and nature sounds. The app was effectively a lifeless “sound board.” It was simply a tool to play a sound. But as I iterated on newer versions, I discovered that Ambie had a more purposeful mission: to help you focus, sleep, or meditate. This was the app’s raison d’être.

Once I formalized this, it helped guide features for Ambie 2.0. For instance, for v1.5, I added fancy animations to help Ambie’s UX pop. My rationale was Ambie needed to look good in order for people to use the app. But this did not align with Ambie’s purpose. Fancy animations were nice to have, but they weren’t going to increase downloads and retain users. People want to use Ambie to focus, sleep, or meditate. Thus, I made the gallery of sounds more prominent in v2.0. I also made it simpler and clearer for users to mix and match up to 3 sounds. Combined, these two areas drive users to play more sound combinations that meet their needs.

Discovering Ambie’s core purpose allowed me to build more useful features. And this discovery skill is one that I am still honing today. The faster you identify a product’s purpose, the faster you can build features to effectively serve your customers.

Lesson #2 — Understanding Ambie is a content-driven app

Ambie is a content-driven app. This means that people use Ambie based on the content it has. In this case, the content are white noise and nature sound tracks. Other content-driven apps are Instagram, YouTube, etc. In contrast, an app like Nightingale is developer tool. It’s main focus is performing operations to help you get a job done. It’s a productivity-driven app, similar to apps like Microsoft Word. It seems obvious to read these statements now, but it took me months to wrap my head around this. More importantly, who cares what type of app Ambie is? Well, like in Lesson #1, this identifies what features to build.

Ambie is driven by content, that means we need to put the content front and centre. This is another reason why Ambie 2.0 refocuses the UI on your gallery of sounds. In previous versions, the focus was more on what sounds are playing. In fact, the “now playing” information used to take up more space than the gallery of sounds. Imagine if YouTube used less than 50% of the website’s space to show its lists of videos. This is an ineffective use of space. So in Ambie 2.0, the gallery has more space to shine.

Additionally, since Ambie is driven by content, the content acquisition UX needed to improvement. In previous versions, downloading sounds from the online catalogue was a sequential process. Ambie only downloaded sounds one by one. Further, there was no indication what percentage of the sound has been downloaded. This was a poor UX for content acquisition. For Ambie 2.0, I built support for parallel downloads and for download indicators. Immediately, customers appreciated this change so they can download new sounds faster.

Lesson #3 — Focus on the fundamentals

In a previous blog post, I wrote that I built useless features in Nightingale that were eventually removed from the code. This was because those features were tangential to the app’s core purpose. Well, once again, I made the same mistake.

Ambie v1.5 introduced the ability for users to upload sounds. Sounds great, right? But no one uploaded anything. One person out of Ambie’s thousands of customers selected a sound file from their file system, but they never clicked the “upload” button. After 2 months of building a scalable backend service and building the UI, not a single customer uploaded a sound. What a huge waste of time…

What went wrong? Clearly, I didn’t read a blog post talking about the same lessons as #1 and #2 above. But in all seriousness, I had tunnel vision. I had this crazy idea that in order to get more people to use Ambie, I need more sounds. And one way to get more sounds is to allows users to upload theirs. But the problem was that the people listening to sounds on Ambie were very unlikely to also be ambient sound creators. The sound-upload feature was targeted at a completely different customer, not for Ambie’s existing customers.

It was a costly engineering mistake. But I learned a lot from this. In fact, it was this mistake that led to my realizations for Lessons #1 and #2. Uploading sounds is outside the scope of Ambie’s core mission. Perhaps I can make a new web-based portal for uploading sounds. That portal’s would have a different mission: to allow ambient sound creators to deliver their sounds to all Ambie users. But the app itself didn’t share this mission, and thus I should never have built the sound upload feature into it.

In conclusion

Here are the lessons in distilled form:

  1. Discover your app’s core mission. Then ensure all your features directly support that mission.
  2. Understand what type of app you have. Then ensure you have a smooth UX for your app’s focus. If you have a content-driven app, let the content shine. If you have a productivity app, remove distractions and make it easy for users to get their work done.
  3. Focus on the fundamentals. Ensure you are building features that support your mission, your app type, and your customer. Features that deviate from the fundamentals should be lower priority or may require a different product altogether.

I hope you can learn from my mistakes. I know I’ll take this and make my future apps even better.

If you’re interested, download Ambie fromhere: https://www.microsoft.com/en-us/p/ambie-white-noise/9p07xnm5chp0.

Until next time,

Daniel

--

--

Daniel

I’m a software engineer at Microsoft, and I build Windows apps. I created Nightingale REST client. My stories are personal & not Microsoft’s.