Teardown this App

Hoop’s product team spends a lot of time using other company’s apps. We’re looking for ideas, inspiration, and for insights into how other teams have solved ubiquitous, niggling UX problems. If we find an app we’re really impressed with we’ll do a full teardown:

  • Capture every screen in Photos
  • Share the screens with the team on Dropbox
  • Knit all the screens together
  • Annotate and scribble on print-outs

This isn’t particularly revolutionary. I’m confident that the same tactics are employed by product teams and design agencies the world over. Discovering how other teams have solved the problems you face is one of the keys to quickly moving forward in a fast-paced industry. (If you’re interested in learning about the masters of the teardown, read about how the auto industry does it in Wired.)

The auto industry are the masters of the teardown

In the process of making Hoop, we’ve solved various interesting challenges. So while the idea of someone tearing it to pieces — critiquing all the design, cherry-picking the best bits for their own — sounds pretty awful on the surface … if it helps them overcome their own challenges, I’m all for it.

And we can even take this a step further.

From now on, with every update of the Hoop app, we’re going to publish a high-resolution image of every screen, and every major interaction, on the app. We’re calling it a build file.

We’d love it if others joined us. Whether you make an app, a website, or a piece of desktop software, we’re calling on product teams elsewhere to publish their build files too.

“But this will just lead to rampant copying?!”

This is a natural fear. But the truth is if you make a popular app this is already happening anyway. Just take a look at the excellent User Onboard from Samuel Hulick. We believe that it’s better to be contributing to a community whose aim is to help everyone make better products, than to worry about someone with no creativity beating you at your own job.

What’s more, the rigour of publishing these files is a great habit for your team to get into. You’ll notice areas that need improvement, create meaningful naming conventions and hierarchies, and you’ll engage others in a public critique of your work.

So, here on Medium, with every update to Hoop, we’re going to publish our build file along with the usual release notes.

We’re showing you ours … we’d love it if you showed everybody yours.

Build File


Thanks to Benji Lanyado, Jonathan Petrides, Lawrence Brown, Alexander Edge, Daniel Howells and Utku Can for reading an early draft of this post.

Show your support

Clapping shows how much you appreciated Daniel Bower’s story.