Marker: Customer Development + Feature Design

Marker was an opportunity to work with a small team  consisting of founder, lead engineer, and myself leading a few designers. This project started like most good product designs should, a problem! To design a solution for this problem we started with the users, moving through prototyping, validation, and finally shipping the product! Our goal was to build out a new feature set in the course of a month to expand Marker's functionality and user base-- we succeeded and learned a lot in the process.

You can see, play, and use this feature now at:



The way it is now.

The way it is now.

The founders of Marker started it solve a problem many of their friends were having, keeping a personal and emotional list of experiences they've had. Yelp's become too commoditized. Evernote doesn't quite have the functionality to keep everything together. So they designed Marker-- "Marker is a delightful and simple way to share your local discoveries and build a personal guide inspired by friends." The next problem they wanted to tackle was asking friends for advice for traveling. We had our own experiences; think about who knows the area you're traveling to, send a bunch of e-mails, get a random result, struggle, but what was everyone else's experience? 



User Interviews round 1

The first round of interviews was effectively customer development. Before we could design prototypes, wireframes, or even sketches we had to understand how people were accomplishing this task today. When people travel, how do they find the places to visit? When they ask their friends for advice on where to go; who, how, and where do they do it? We did a series of 15 interviews to develop 4 personas that we thought fit into this feature. 

In addition to stories and behaviors, we developed scales for (3) key persona indicators-- Social sharing, experience type, and adventure levels. These metrics were used to put personas in context-- all of these behaviors are only significant in relationship to other people. 






Feature design

Now that we had the key personas detailed, we could start developing what the feature actually looked like. We knew people tweeted, Facebook'd, and e-mailed advice requests. Just about everyone had different preferences so we knew that we had to give the control to the user with smart defaults to make that process as frictionless as possible. 

We found that generally, the layout was an existing paradigm. We briefly considering innovating on this but ultimately decided we lacked objectionable reason for breaking the existing mental model. People expect a certain "share" screen, and while it may not be the best design possible, but people understand it and therefore we chose to follow this paradigm.

We found that the type of sharing was more important than how we presented them. Generally sharing options split between private and public. We found through our interviewing that users also split between those who considered themselves private sharers versus public sharers. We had a hypothesis that providing users with two explicit sharing paths, private and public, would maximize the funnel conversion.

We had a hypothesis that providing users with two explicit sharing paths, private and public, would maximize the funnel conversion.

We developed a prototype based on the following screens. This flow would allow users to develop more confidence in their ability to share based on their own preference. Private sharers were uncomfortable sharing to Facebook regardless of the sharing method, but given the correct channel they would share within Facebook.

Validation Interviews

We had prototypes developed, we thought they aligned with our persona interviews, but would they be effective? To answer this question we conducted additional user research and prototype testing. The business model of Marker aligned with certain personas more closely, so we chose users that aligned with those key personas to gain the most relevant interview input.

People often say that testing should be to prove your hypothesis wrong-- which is exactly what we did. The solution we designed proved to be too literal of an interpretation. Yes users were concerned about privacy. Yes users generally share privately or publicly. What we missed was that people don't label themselves private or public- they just share. People already have such an existing model around how they share that bring to lump it into a group is often times confusing. Users have a really strong idea of how and where they want to share, and they just want the easiest way to do it.

Users have a really strong idea of how and where they want to share, and they just want the easiest way to do it.

Live "prototype" + Conclusion

One of the largest constraints we had on this project was time. We had a month to ship, and at the end of the month we had to ship. Regardless of how many iteration cycles we have gone through or users we tested. We were lucky to have gotten through a round of validation and we confident to put the new feature up on Marker's site ( While the feature may not be perfectly designed, but it is viable and we are constantly tweaking based on feedback and testing. Being live and viable is infinitely more valuable than being shelved and perfect.

We ended up going with a relatively standard sharing option screen. It was what users expected and ultimately caused the least friction. We did explicitly add a Facebook message option-- a communication channel that many users preferred but rarely saw on share screens. This is a live prototype and you can see, play, and use it here: