Started 2021-04-12
Making things easy is hard
Many people have said it before me but making things easy is hard. I read a long time ago that many experts are particularly bad at explaining things to other people that are not experts. I believe the same is true when someone gets to a certain level of comfort using a product. Once you become proficient in something muscle memory takes over and it's easy to forget how hard it was to get there. You may be able to do it quickly but others are going to take a long time to get there.
How do we make things easier?
The process that I go through to learn something new is the same process I go through to figure out how to make something easier. It's quite simple in the beginning:
#1 - Start using the product without reading the documentation
I know, I know. Many people will say this is the wrong way to go. I'll agree that for safety critical things this is a mistake. Don't go buy a chainsaw if you've never used one before and just "wing it".
However, in modern software there are designers making user interfaces that should be considering the user experience and making it as easy and fool proof as possible. If I can't pick up a new product and do anything with it without reading the docs you have a serious barrier to entry. Customers will appreciate and be invested in your product a lot more the faster they can get started. The docs should be available for more advanced usage.
#2 - When you read the documentation, skim it
Once you get to the point where you have to read the documentation, or when you're trying to do a guided exercise (workshop, tutorial, etc) you should be skimming it. Often times I find that there are critical gems in documentation that are easy to miss. Many customers will be rushing to get started with your product and won't read every single word.
If something is in the documentation that is critical then make sure nobody can miss it. If a customer skims the documentation, their setup fails, and then someone points out to them that there's a single sentence in a 6,000 word document that fixes the issue they're not going to be excited. You're also blowing your support team's time on something that could've been fixed by some bold text or a call out box.
#3 - Document every single step that is required to set something up, no matter how small
I did this for a project and realized that it took 26 steps to get set up. It's easy to get in the mindset that the steps are minor and only take a few seconds each but for the customer it is a death by 1,000 cuts.
Ask yourself:
- Are all the steps necessary? Could some of them be done ahead of time to cover 80% or more of use cases? If product A, requires product B, then maybe just spin up product B for the customer automatically (but let them know it is happening, of course).
- Is there a way to automate some of the steps? Ask the customer what they want to do and do some of the setup for them. A checklist where they can select the features they want could then be used to build a script to run those steps for them.
- Does the customer understand why all of these steps are necessary? If a customer gets lost in boilerplate, it's a bad experience. But avoid explaining everything up front because...
- Does a new customer really care about all of these steps? This goes back to the first point of 80% or more of use cases. If the customer is forced to read through a ton of documentation to understand some tiny edge case they'll lose interest quickly unless that edge case is relevant. Find a way to determine that upfront so you don't end up punishing everyone.
What are some of the barriers to making things easier?
- Mindset
- Resources
- Customer demand