Product Designer



Podcats: A passion project

Podcats is a passion project to help people find new podcasts to listen to. As a total podcast addict, I found that I was often burning through my podcasts too quickly and had nothing to listen to. Podcats seeks to solve that problem by creating a digital community where people can recommend pocasts together. Podcats was made in collaboration with Niels de Hoog.


The problem

For those who aren’t aware, podcasts are basically a radio show, tailored to your interests, delivered straight to your phone every week (or month, or day..). If you can think of a subject, there is probably a podcast about it. Anyone can make a podcast, and podcasts often develop loyal (rabid) followings, as listeners develop a “best friend you’ve never actually spoken to” personal relationship with the creators.

iTunes, the main podcast place where podcasts live, does provide a top list of interesting podcasts, but this list generally remains unchanged for months/years at a time with the big production podcast players. Popular podcasts remain popular, new guys don’t even stand a chance. Podcast listeners generally have a list of their favourites, but it’s difficult to discover new podcasts outside of your bubble.

Furthermore, the discoverability of new podcasts through iTunes is wedged somewhere between ‘abysmal’ and ‘completely useless’. Think of all of the amazing stuff you aren’t hearing!



When I was but a baby podcast listener, I found my podcasts via iTunes like the rest of the noobs. After professing my newfound love for podcasts to friends, I soon had a long list of requests pouring in that were even better than what I found on iTunes. I realised that there was an inexhaustible amount of podcasts floating out there in the abyss. Unfortunately for me, I do have an exhaustible amount of friends.

Thus, Podcats was born. Podcats is in essence, a way for anyone to say “hey, I like this podcast, you might too”.


After the bud of an idea was there, it was up to Niels and I to decide what was feasible. Seasoned app developers as we were, we still had full time jobs and social lives to contend with. We tried to decipher what was the minimum viable product could be. We wanted to build an app with enough features to captivate users, but not so many features that we’d have to work on it for a hundred years before it was finished. The core of the idea was the ability to recommend podcasts to each other, and everything else was secondary. So at it’s core, the app had to:

  • Display recommendations from other people
  • Accept recommendations to display

A tried and tested application of this mechanic is Reddit/Hacker News/Product Hunt: a user can submit something, and all other users get one vote on whether or not it’s good. What that results in is a list of content that the community finds interesting. Perfect for our concept! I’m a strong proponent of not reinventing the wheel, so we happily stole this mechanic for Podcats. The Reddit mechanic did add one more must have feature:

  • The ability (but not obligation) to log in

Why a login? Users can only have vote, so we need to be able to track if you’ve already voted or not. We could do this based on device (though Apple is admittedly not a fan of that practice), but it seemed to have more longevity to create a login: it opens the door to new features in a future release, and doesn’t punish the user for changing devices.

After we had established clearly what the app must do, it was time for me to get those ideas on (digital) paper:


Interaction design

I generally start my interaction design process on paper so that I can quickly get ideas on out of my head. What that looks like are not the beautiful interfaces sketches of Dribbble, but rather, the rantings of a crazy person. Speed takes precedence over beauty in this stage.

I try to sketch out the most obvious ideas first, just to get it out of the way.


After the obvious ideas, I try to think something completely different (i.e. what if this interface was gesture only, no buttons allowed? or: what if this app had no typography in it?) These small exercises force me to think of unconventional ways of laying out the interface and prevent the designs from becoming stale. I almost never use them in full as an interaction, but the often lead to little elements the make it into the final designs.

I also try to think of the worst possible solutions, as an though exercise. When making something intentionally bad, you need to be aware why it wouldn’t work. So in inverse way, you are considering the users needs. It’s quite obvious, but it often leads to new insights or at least serve to support the other interaction designs.

When everything is physical, it’s simple to move things around, (literally) rip pieces of one idea and paste them on another, or quickly make notes here or there. From there it’s edit, edit, edit. I try to distill all of the sketches into something that could be functional app on paper. After a few iterations of solving the most obvious issues, I make a digital first draft interaction design to more easily communicate it with other people.



I strongly, strongly, shout-it-from-the-mountain-tops believe in the importance of prototyping. Normally my old favourite is Pop, for it’s simplicity and how quickly I can test the basics on the device. More recently, I discovered prototyping in Keynote, which nearly as fast as Pop, but with the benefit of being able to prototype pretty complex animations with ease. For more high fidelity prototyping, I usually jump straight native iOS development. With such a small team, we didn’t focus that much on a step by step process or keeping things really formal when building Podcats. I made a first draft of an interaction design, showed it to Niels, we made some verbal agreements and he started building away. Pretty quickly, we saw the pain points in the interaction design and could just shout out some ideas. Niels would implement them, and then we’d see if it felt right.

Because of our informal process, the design and development process blurred together significantly. Sometimes it felt like this:


But it also felt good, there’s no sense in spending a week perfecting a design only to find out that it works terribly.


Visual design iterations

The first iterations of Podcats were SO BAD and I would love to put them on the internet for you to laugh at. Unfortunately, being new at Sketch, I had the habit (then) of just working in one art board and saving over it a hundred times thus I lost the earliest versions like an idiot. Only later in the process did I discover the magic of multiple art boards and so can only show you the last few iterations.

This first design isn’t -terrible- but it’s not great either. It lacks contrast and doesn’t have enough cohesion within the iconography. I don’t know where to look!!


The visual hierarchy becomes clearer by changing “popular/new” toggle into an element that has a strong contrast to the content. The rounded edges make it read more as a button and plays well off of the rounded iconography in the header. The arrows on the right are mean to represent stages of swiping right: to create a more calm screen, I thought to move the up voting out of the content. This idea was scrapped because up voting content was too central of feature to hide in a gesture.


When in doubt, add an unnecessary picture of Ira Glass into your design. It’s scientifically proven to improve designs by 1000%


The final design

We wanted Podcats to be a very minimalistic app that put a lot of focus on: 1. reading 2. encouraging users to vote on content

Focus on reading was solved by placing heavy contrast on text and allow there to be enough whitespace to not get overwhelmed by the large amounts of texts. Contrast was lowered for less important text.

I encourage users to vote by placing a large number right next to the content with a bright accent colour to draw the eye.


Testing 123

The app was a reality! We got the major kinks out, and it was time to put it in the hands of real living, breathing, people. After reaching out on Facebook, we got 39 people to check it out for us. We got great feedback about bugs, confusing parts of the app, and the parts people liked.


To give the feedback a bit more structure, we sent out a survey to our users. We kept it anonymous so people could be blunt with their feedback.


Niels and I collected all the feedback and categorised it into “must fix” and “will fix later”. After fixing the major issues, we had two more rounds of user feedback and were ready to release it to the whole wide world.



After many months and long nights, we were ready! After a few days it was approved by Apple and in the app store. We got a very positive response, even making it to the front page of hacker news and being featured on Product Hunt.



Podcats interaction design was made with Balsamiq and later Sketch. The visual design was done in Sketch.


Niels and I stayed in sync with Trello. We shared assets via Dropbox. Prototyping and development was done in XCode with a repo on Bitbucket. The testing and crash reporting was done in Crashlytics. User analytics was done with Countly.


That name, though

One of the most common questions about Podcats is the name. We started out with the name “9ears” after putting a few keywords through Bad Translator. After telling a few friends about our idea, my cat-loving friend Mendel suggested the play on words “Podcats”. It just stuck, and we started incorporating cat-related elements into the app, including our mascot, a happy blue cat.

Portrait 2@2x.png

Hindsight is 20/20

Making this app was a learning process. If I could do it all over again, I would certainly do a few things differently.

One of the most important lessons I learned was get things in people’s hands early and often. I have tendency to have an idea, go hide in a cave for a hundred years perfecting it, and only then sharing it with the world. I’ve since learned (and am working on) just getting things out in the world more often. User feedback is incredibly important and we missed it too much in the beginning stages.

In the future, I would probably create a website as soon as I had an idea, and promote the website to gauge people’s interest. If that was successful, I would start building, and with every stage, give something to the users. That way you avoid building something that no one is interested in and can remain flexible while building.

The consequences of this lack of foresight in Podcats were basically our assumption about the minimum viable product was not entirely correct. We just needed a bit more. People seem generally enthusiastic about the idea and seem to use and understand how to use that app, but are not sticking around. We’ve talked to our users about why and are already making plans for the next release to remedy this. In future releases, we’ll work in a more loose process and get the users involved more.