Working Agile: The Pocket Method
Wednesday night instead of going home I was one of 15 lucky creatives chosen to participate in a workshop hosted by AIGA SF, Pocket, and Google Ventures. It was a last minute acceptance, since I had completely forgotten that I even applied to be a part of it, but I said “what the heck” and decided to go. I’m so glad I did.
The workshop took us through a truncated view of an agile 5 day sprint adopted by many startups including Pocket. The three people that presented this method were Daniel Burka from Google Ventures Nikki Will and Diego Mendes from Pocket.
I’m not going to go over everything I learned here, because it’s just too much to cover but I will break down the days and then add what really stood out to me as valuable.
It’s no surprise that this 5 day sprint method is designed to get quick feedback from user testing and is centered around the mantra “learn early, learn often”.
Day one: “Unpacking the Problem”
Insight number one: Get everyone to weigh in and agree on the actual problem.
Start off by gathering the right people for this discussion. It’s not just the designers that need to weigh in, but business development people, stake holders, customer service reps, developers, product managers, sales, etc. This is the time when you bring in people who will have good insights into the pain points and challenges that you want to solve.
Insight number two: Turn problems into “How Might We’s”
After everyone had a chance to think of problems, they reframed the problems into questions starting with “How might we”. Put them up on sticky notes and put them all over the wall.
“How Might We…. help customers find what they are looking for faster on the website”.
Insight number three: Have everyone vote silently on the biggest pain points
Using a silent voting system cuts down on a lot of time spent trying to convince people to move in one direction or the other. We used small dot stickers, but you can also just make marks on the sticky notes with markers. The goal is to see a trend in where the group agrees the biggest problems are.
Day Two: Sketch
What I really liked about this section was that we didn’t just start sketching right away. We actually started with taking notes of everything we had learned about the problem, about the user, about the competitors and analagous products. The notes turned into mind maps and slowly we worked our way up to story boards, which basically was the user flow.
Day Three: Story Board
Insight number four: consider every entry point.
I really liked how they used their story boards because they started from the beginning and explained all the places that someone might enter the site or the app download page.
For example: If a user googled a keyword that took them to the product page of your site. From there they would have to choose which download they needed (ios/android/windows etc) and then proceed to the appropriate store (app store/ google play etc). They would then have to download the app and register to use it.
Another example could be they were on facebook and saw a paid ad in their feed. They clicked on the link and decided to try the app.
All of these entry points are as equally important to make sure no one drops off or is sent to the wrong place.
Day Four: Prototype
This is it. The day when you take everything you’ve learned, all your sketches, and you flesh out the experience.
Insight number five: Choose medium fidelity
I thought that making black and white wireframe prototypes would be good enough so that people could focus on the flow and not about subjective things like color and fonts, but the folks at Pocket and Google Ventures said that if you get up to high enough level of fidelity, the user will actually use the app and make valuable comments instead of thinking of it as a prototype.
Diego also mentioned that you don’t need to use any fancy software to make your prototypes and that their product of choice is keynote.
Day Five: User Study
I had always heard that you should get your product in front of as many people as possible and it didn’t really matter who, but Brian said in his experience, that’s really not the best way to go. I should probably mention that this call for testers was probably put out on day one.
Insight number six: Write a screener survey and recruit testers from craigslist
Getting people who fit your audience will get you better results. Once you have 5 good candidates for the user study, schedule them to come in on that 5th day and offer up some sort of payment. $100 in Amazon or visa gift cards seems to be pretty standard.
Doing user studies is all about asking the right questions. Explaining upfront that you need the user to verbally describe what they are doing and thinking will best help you make the experience better. For more tips on what questions to ask and how to conduct user testing studies, you can visit some of these fine links:
Do it all over again
Once you’ve collected your insights from your user testing, take that back to the drawing board and re-fine and reiterate your product and do the whole thing over again.
To re-iterate, the goal is to get good data fast, so that you can pivot and make good design decisions that will lead to a successful product. You can learn more about this sprint method at Google Ventures
Thanks again to AIGA-SF for partnering up to make this event happen. Thanks to Diego, Brian, and Nikki for spending their after hours teaching us about their process and sharing the pocket space with us.