Developers are Users, Three

Building Unique User Experiences for Developers

As promised, this is the continuation to my first post “Developers are Users, Too”. In that article, I outlined some lessons learned from my experiences building and marketing products for developers. Specifically, I discussed ideas on converting a wary visitor to your website into a trial user by:

1. Selling the Dream. Explain the value and benefits of your product, don’t just list the features of what you’ve made.
2. Anticipating the Questions. Know your users and their use cases. By being the product expert, you can provide the answers that users will be searching for when reviewing your product.
3. Designing with Purpose. Build APIs that are human-usable. Unless, of course, your users are drone-bots. Then build APIs for the drone-bots.

This follow-up post continues this theme and focuses on moving developers further into your product from trial users to engaged customers.

Since I ended the previous post reviewing best practices with API design, let’s start this one by discussing visual design.

4. Have an Opinion

Maybe it’s just me, but I hate having too many choices. It’s overwhelming and stressful. I can stand in the cereal aisle of the grocery store for hours, paralyzed with the fear that choosing Honey Nut Cheerios or Corn Flakes will create huge repercussions in my life.

My point here is that when building your product, don’t put your users through the same gauntlet that is the supermarket cereal aisle. Guide, lead, and nudge them to the goal you want them to achieve.

I’ll give you an example from our developer portal at PubNub. As with many other products, it was born out of necessity. The interface was built by developers for other developers which meant that we threw in the kitchen sink. Users had the freedom to determine the hierarchy between their applications and key sets, based on their particular business use case.

Sounds great, right? It lets our users do whatever they want, they have complete control over their account. However, what we found was that most users didn’t organize anything — some did not know they could and others were confused on why they would. A few developers started using our APIs instead of spending time trying to understand how to create new keys or applications through the UI. So we are working on fixing those user flows that right now.

Nudge users into how they should use your product because they aren’t going to be experts, nor should they have to be. Lead them into best practices and limit their options to make their lives easier.

5. Low Friction, High Stickiness

As potential evaluators become users of your product, simply get out of their way. Remove any and all barriers to get them coding and building. You want to ensure that your product is easy to use and understand so that they can start developing immediately.

Barriers may include a high product price, unreliable support options, or a lack of overall clarity. You may want to offer a free tier or evaluation period of your product to entice users. And offer additional avenues to your customer support channels for new users. At PubNub, we also created Quick Start guides with step-by-step instructions on how to send and receive messages on our network.

You may also want to spend extra time on your product documentation, as this is typically the first place developers visit for self-support. Ensure it is comprehensive (for example, all API calls should have solid reference material), searchable with easy-to-understand information hierarchy, and connected to other training materials (video tutorials, downloadable examples, and code snippets).

Later, once you have provided the help your users may need to build the foundation of their application, you can then provide additional advanced options, explain other key features, and have a deeper understanding of user behavior to make more habit-forming user experiences.

“Fogg Behavior Model” by BJ Fogg (behaviormodel.org) and “The Hook” by Nir Eyal (nirandfar.com)

6. Always be Analyzing

This is a modification of the sales pitch from Glengarry Glen Ross. Instead of “Always Be Closing”, as a product owner you should “Always Be Analyzing”.

Experiment, tweak, and measure. Not everything will work but if you’re open to trying new ideas, you’ll start understanding your users like never before. So build hypotheses and measurable tests for your product. Constantly experiment in order to try and prove yourself wrong. And override the metrics and results with gut decisions when that needs to happen. (I know that last sentence is a contradiction to all of the analysis I’m recommending, but what can I say? Life is full of contradictions.)

For qualitative analysis, you can talk to your current customers, conduct usability tests with potential customers, or join discussions on online fora such as Quora, Stack Overflow, Facebook, Twitter, Reddit. From a quantitative perspective, there is a lot you can measure. Build A/B tests, review the conversion rates of your user flows, conduct cohort analyses, watch click-through rates, track overall engagement, etc. For even more on conversion behavior, I always recommend Dave McClure’s Pirate Metrics.

Dave McClure’s Pirate Metrics (AARRR!)

Once again, focus on your user’s journey with your product. Have a clear point of view on how you want users to use your product, and reflect that in your design decisions. Remove barriers to trials and provide habit-forming experiences to help in your overall retention. And, of course, the Build-Measure-Learn process is a continuous cycle. Expect constant analysis and updates to your product.