Product design for organic growth

Remember this quote from Alan Kay - “Simple things should be simple, and complex things should be possible”. If your product is complicated for people who need simple things, the learning curve will be too steep and people won’t begin to use it. If you don’t allow the flexibility for expert users, they will move elsewhere when they run into the limits of what you offer, and expert users are what drive organic adoption because people listen to them.

So, how to satisfy both? Let’s break down the steps:

  • Generate a user persona for your ‘bulk user’. Largest in quantity, although probably not in the amount of feedback they give. This is your bread-and-butter user, they need a basic feature set.

  • Generate the requirements this persona would have, or would have most of the time. (insight: advanced users spend most of their time here too)

  • Optimize the UI ruthlessly for these workflows. Minimize clicks and screen changes, set defaults, pre-populate fields. Define what your inputs and outputs are, and provide that service with absolute minimum effort. Add an ugly red button that says “click me first”, and then click that button for them so they don’t have to. Optimize for minimum-time-spent to achieve the tasks the very first time someone uses it.

  • Generate user persona for ‘advanced user’. This user wants to do ‘cool’ things, really pushing the tool you are building to the limits.

  • Generate requirements for this user. Think of the things they would want to do, and think of classes of things they would want to do. You can’t be exhaustive here, they could want to do anything, but try to throw in as much as you can.

  • Break down the requirements and figure out how they could be solved with just a few composable components. Try to have as few, simple, orthoganol, components as possible, but let them be combined in weird and wonderful ways that let the users invent new things you haven’t designed up front. Be inspired by things like spreadsheet macros and Lego - your design shouldn’t be dictating what the user should do, but instead should provide building blocks to let them do whatever they want. The user persona is an expert in using these things, whatever it is you come up with.

  • From these fundamental components figure out a way to provide the new capabilities while not impacting the workflow of the ‘simple path’ user. If possible re-implement the simple user path in terms of these new tools (under the hood) to reduce maintenance costs and dogfood the ‘expert tools’. Your development team is the ideal ‘expert user’ so listen to their feedback!

Voila! Most of the time your tool is now super easy and intuitive to use. For the edge cases where more is needed, you’ve provided escape hatches that advanced users can access, letting them stay with your tool for a larger part of their workflow. Now, when a beginner asks their expert friend “What do you use?", they’ll recommend your product, not only because they use it but because the beginner can use it. Morover, when the beginner tries it, they’ll find it easy and intuitive, and when they too become expert they can stick with it.

Once you have some traction, if you find that certain advanced workflows are heavily used, you can easily add ‘shortcuts’ for them, since the backend is all there already. Advanced users like things to be easy for them too!

Disclaimer: this post grossly simplifies the situation. Following this script probably won’t work for you without other aspects contributing to your success as well.