My first go at Product Design
How passive learning is different from doing the work
I’ve been reading about Product Design for over a year now. “Learning” from other people’s mistakes trying to be as prepare as possible for when it’s my turn to create one. Nonetheless, it only helped me identify my own mistakes after I made them. Rookie mistakes. There’s no way around them, I learned.
The following is not meant to keep anyone from making this mistakes, but to encourage everyone to just start doing the work no matter how unprepared you might feel.
As a background: I’m a UX Designer learning Product Design and this is a personal project. I’m working as a team with the best developer I know.
The challenge: How to use the new Dribbble API version to expand on the value the users get from the platform?
This is the story of how Playbbboard was created. How it evolve from an app for everyone in Dribbble, to a selected audience who responded to the value proposition. Here’s a few lessons that shaped the end product.
Only users validate the value of the product
Even though I’ve read countless articles about focusing on the right audience and how important feedback from users is, I still started the project with a broad audience thinking that Dribbble users with invites were a small enough sample.
It wasn’t until I reached out to potential users that I realized that the idea wasn’t for everyone, but for just the right few. Designers working on the computer would not need to upload shots from the iPhone. However, designers and illustrators who produce analogue shots (like illustrations, logo design sketches, hand-drawn lettering) and most likely take pictures of their work with their phones, would appreciate being able to upload them right from their device.
Having narrowed the profile to users who start their design process away from the computer, I was able to reach out to an specific group of them with a value proposition.
I went back to Dribbble, searched for players who often share analogue shots of their work and reached out to them. The result was a response rate of 62% from which every user can see themselves trying the app as part of their workflow.
Designing the user-flow before prioritizing features
I jumped right into the user-flow to be able to start the conversation about development. I basically took into consideration everything that the Dribbble API would allow the app to do, instead of thinking about what the users might need a Dribbble iOS app for.
Having a user-flow without an objective cost us several iterations until we realized the only feature we needed to build: uploading from the iPhone.
Just to give you an idea of how this can affect the outcome:
The first version of the user-flow had 26 screens.
The final version? 13 screens.
A few other factors to take into account:
- Releasing the app as a full featured Dribbble client would have made it compete with all the great apps already on the App Store.
- Dribbble browsing apps target a different audience whom would be confuse with (and would not need) the uploading feature.
- We needed to test the assumption of users seeing value in uploading their shots from their iPhone.
Not checking technical constraints
Because the app seemed simple enough at the beginning (even with an user-flow of 26 screens.. ha!), I went ahead and designed the screens for all features. As we started building the app, we realized a few holes in the Dribbble API that does not allow us to completely replicate the upload process that takes place on the Dribbble page.
Looking back, a quick hand-drawn sketch of the user-flow and a technical check on the API would have saved us an incredible amount of time.
From start to finish
After many iterations and lessons learned, the app statement went from: “Dribbble app for players to upload their shots from their iPhones”.
“Dribbble app for illustrators, logo designers and letterers to upload their analogue shots from their iPhones”.