Let go, and let users.

How Pinterest wouldn’t let me build something for their users. So I built it anyway.

Tim Diacon


Let me start by saying I think Pinterest is great. As a tool to discover, collect and share creative ideas, it does exactly what it sets out to do; and it does it really well.

I am the Design Director of a digital product and service design studio. I’m passionate about building tools that help people get things done. I’m always on the look-out for how we can use technology to support our creative process. However, there are times when we just have to step out of the digital and into the physical. It happens a lot. It happens in every creative discipline I’ve come across. Fashion designers, branding specialists, architects, product designers; there are times when we all ‘print’. Whether it’s to surround ourselves with inspiration in the places we work, or as part of a collaborative process. The need to physically pick up, hold or point at a printed image just can’t be replaced by technology.

Pinterest is a great example of technology doing what it does best for the user. The web is a great place to discover, collect and share inspiration and Pinterest have built a fantastic tool that builds on these affordances. But Pinterest has to understand its role in the wider creative process. As we move beyond the collection of images into discussion around or analysis of material, Pinterest fails. At this stage we print. We print images and we pin them to boards. We gather round these boards in teams. We discuss what we see. We rearrange the images. We sort them, rank them, cluster them. All of these things we can do easily because we have printed them.

And do you know what we don’t want to print? We don’t want to print an exact view of our Pinterest board as we see it in the browser window. We don’t want to print a sheet of thumbnail images in a four by three grid. Surely what we want when we print from Pinterest is obvious? We want one pinned image on one page. Preferably as big as possible — filling the page, even, if that’s not too much to ask?

Pinterest’s print view doesn’t seem fit for purpose

Frustrated by the difficulty in printing Pins in this way, I did a quick google search assuming this was a problem someone had already solved. To my surprise however I couldn’t find a good solution. This made me curious. Why had no one solved this?

A quick look at the Pinterest api revealed it should be fairly straight-forward to create an app which would allow me to print each Pin on a single sheet of paper. It also revealed however a process where apps have to be submitted and approved before being available to anyone beyond your nominated test group. Would Pinterest accept an app which made printing Pins a better user experience? I couldn’t see why not.

The usage policy for their api states “Our goal is to help people discover, save and do things that inspire them”. It goes on to elaborate on these three key themes of Discover, Save and Do.

Let people do more with the stuff they’ve already discovered and saved on Pinterest by giving them ways to bring Pins to life.

Great. Printing a Pin seems like a pretty clear example of bringing it to life and so I went ahead and put together an MVP to test the concept and submitted it for approval. Several weeks passed and finally I received the following message:

Unfortunately, we couldn’t approve your app because it stores or modifies images.

My awesome MVP!

This was a little unexpected as the app was clearly doing neither of these things. The images were being served from their source url with absolutely no modification at all. So I asked Pinterest to clarify the situation:

It looks like your app description does not align with our API Policy. We consider printing our Pins as saving and storing images.

What?! They consider printing their Pins as saving and storing images? I assume they know I can print from any page on the internet, and not just through the app I submitted? Technically they would have to reject every browser based app submitted for also “saving and storing images”.

As far as I was concerned, the tool I had created was 100% inline with the spirit of enabling users to do more with their Pins. Pinterest’s response to this however I felt clearly wasn’t driven by a genuine desire to provide the best possible experience for it’s users. Why create an api, supposedly for the benefit of your users only then to tightly control access to that api with an approval process which clearly doesn’t have their interests in mind. I decided if Pinterest wouldn’t help me create this tool for their users, I’d do it on my own, with a little help from our in house genius Mulhoon.

We’ve been using Google Chrome Browser Extensions a lot in our studio recently as a fast way to prototype ideas. By developing my own Chrome Extension I was able to provide the functionality I was looking to create directly within the Pinterest page. Ironically being rejected access to Pinterest’s api resulted in me creating a better solution with a more tightly integrated user experience.

Printerest — available now in the Chrome Web Store :-)

I sent the extension out to a few friends and colleagues to see if anyone else found it vaguely useful. The responses I received confirmed my suspicion that I’m not the only person who finds printing from Pinterest a ball-ache.

“Ah this is awesome! I know loads of people that would use this all the time!”

The extension is fairly basic right now defaulting to printing each Pin as large as possible on a single sheet of paper. I’ve had a bunch of great suggestions for other features which I plan to add over time.

My experience with Pinterest and their api has made me reflect on some general principles which I think would be good to take into consideration if you’re a tech company thinking of creating an api for your users.

Trust your community.

Asking developers to create and submit apps without knowing if they are going to be approved requires a big leap of faith on the part of the developer and shows very little trust from the api author.

Rule a small number of specific things out. Everything else is in.

Be clear about what you don’t want people to do with your api and embrace everything else. You might be both surprised and delighted with what people create.

Know your strengths, acknowledge your limits.

The Medium api is a great example of this. Medium understands that their editor isn’t what makes them special, it’s the network of readers and writers using the platform. They understand that not everyone who would like to publish on Medium will want to do their writing on Medium and are happy for their api to facilitate this.


If you’re going to publish an api and expect people to build tools that benefit you by providing great experiences for your users then you need to help. Good documentation isn’t enough. You need to engage with your new community of developers, provide help, listen to feedback and evolve the api together.

Don’t try to play God.

There are some things you just cannot control. If your users want something badly enough, they’ll make it happen. If this is in spite of your efforts, then you have no control. You might not even be invited to take part.

Now go print some Pins! But think about the trees before you do it 🌲🌲🌲