Course notes: Improving the first run experience

03 Jul 2013

Kalzumeus is a software company run by Patrick McKenzie which, as one of its several operations, provides training for selling software. One of the many goodies you get when you sign up to Kalzumeus's email list is a short course on improving the first run experience of the software you sell.

As the course outlines, improving the first run experience of your software is important because it means less wasted spending in acquiring customers in the first place. Having a poor first experience with software can mean the potential customer never returns. If, on the other hand, you can acquire a visitor to your website and then keep them engaged by demonstrating value it makes a subsequent sale much more likely.

Here are some short notes I took while watching the course. I thought writing up the notes would both help me internalise their message plus help others understand the material.

I'll include my own personal interpretation notes, including how these ideas apply to bliss and OneMusicAPI, in this formatting.

The course is divided into three main parts:

1. Why first run experience is important
2. Anti-patterns for first run experience
3. Writing product tours

Why first run experience is important

The nature of a person's first experience with your software dictates whether they will come back to your software and use it again. If the cost they perceive in adopting your software (either financial, time or effort) is greater than the value they perceive they can extract from the software then they are less likely to continue using it.

This means that everything you spend (again, financial, intellectual and effort expenditure) is put at risk if your prospects don't derive an early impression of good value. This means:

1. Engineering of new features
2. Paid advertising to drive visitors to your site
3. SEO effort to acquire more customers
4. Server administration costs to support the prospects

... could be in vain.

So essentially, by improving first run experience and thereby conversion rates, you are saving a lot of money.

Makes sense. There's little attempt to do this in either bliss or OneMusicAPI right now. There are written tutorials, and in-app help for bliss, but we could go a lot further. Indeed, a popular idea on the bliss ideas forum suggests users are crying out for more assistance!

Anti-patterns for first run experience

There are a few anti-patterns that Patrick touches on in the course.

Don't start with a "blank page"

Microsoft Word can get away with this, but for everyone else it's a bad idea. It's important you convey value early. When the prospect first uses your software, populate the user interface with example content. Better still if this content is related to the user or the problem/use case that the user is attempting to solve.

This reminds me of the blank slate UI pattern.

Don't lose the 'scent'

Scent is a marketing term to describe the connection between different parts of the sales funnel. For instance, conveying the same message, branding and discounts in both the advert, landing page and fulfillment pages provides a good, consistent scent.

This can be taken a level further with software. The problem a user is attempting to solve can be induced from the search terms and landing page that the user has visited. Then, the solution itself can be tailored to provide immediate value.

Patrick gives the example of, when searching for "american presidents bingo cards", providing obvious affordances to populate a bingo card with American president names immediately, rather than a blank bing page in which the prospect must fill in the names themselves.

I can see how this could be fairly straightforward with SaaS products, but implementing this for bliss (which is downloadable software) would be more difficult. How would the software, downloaded and installed separate to the user's experience with the sales website, know what problem the user wanted to solve. One could imagine some sort of correlation identifiers, but it soon gets messy.

This would be easier for OneMusicAPI. If someone searched for "cover art API" and landed on a OneMusicAPI landing page we could tailor the tutorial for that case.

Don't make people think

At all points in your software's first run experience there are opportunities to make your prospect have to think too hard. Microsoft Word is an extreme example of this; open Word on the default blank page and there must be over one hundred different affordances that the user can click.

Better to be far more guided. Don't offer too many options, instead tell the user what to click, or guide them towards it. This means they are far less overwhelmed with your software and they will find learning about it, and thus learning the value it provides, much easier.

This is especially bad for OneMusicAPI right now. There are big disconnects between sign up, activation via email and then working out what you're supposed to do next.

Writing product tours

The final part of the course discusses product tours. Product tours, while not trivial to implement, have given Patrick excellent return-on-engineering-investment.

A tour is a guided walkthrough of user experience with your software. It is intended to expose the value of the software. We should avoid making people think, the tours should tell the user what to type or click. Ideally there should be no choices and no decisions for the user to make.

For bliss, it's fairly straightforward to consider how tours could work. The user could be directed through the user interface, accomplishing common goals. I guess the changes would not actually be 'sticky' and therefore not write to music files.

It's a little harder to conceive a tour for OneMusicAPI, as there's no UI component. Instead, the closest I can think of is something like a guided tutorial in using the API. Firebase's tutorial is an excellent example of this.