There’s loads of cool technology out there, much of it being touted as making my life easier as a developer or computer user. Yet, often I ignore it, or play a little then abandon it as “too complicated”.
I’ve often mulled on what it takes for a product or a tool to take off. Let’s assume, for the discussion here, that the product is in some way compelling. You’re managing to get people interested in the tool, at least on the surface. What is required to enable more widespread adoption? How do you avoid people abandoning your tool before they’ve actually done something useful with it?
Recently, I’ve been thinking in terms of what I’m calling a product’s “Minimum Concept Count”. This could be defined as:
the minimum number of concepts a user is required to learn to effectively use the product.
In relation to our tool, a user will have a “Maximum Concept Count“. This could be defined as:
the maximum number of concepts a user is willing to learn before seeing success with the product
If our aim is to increase adoption, then we need to pay attention to a very simple formula. For any user, we are likely to succeed if:
product’s Minimum Concept Count < user’s Maximum Concept Count
Your Maximum Concept Count for a particular product depends on a number of factors. It will depend upon your level of interest in the product: If it could save you years of effort, then the number of concepts you are willing to learn will be high. The number of concepts will also depend upon the amount of effort it takes for you to absorb new concepts (the whole idea of Minimum Concept Count arose for me due to the fact that I don’t absorb concepts as fast as many of my colleagues do).
We can increase product adoption by explaining well the problem that our product solves: giving people the motivation to engage fully with the system until they are able achieve success with it. Or, we can target more capable users – that works in the early stages of a project, when the initial innovation happens, but it will harm widespread adoption in the long run.
More usefully though, when designing the system, is to think about ways in which we can reduce the number of concepts required to learn a system.
Let’s say to fully engage with a system, a user must learn ten concepts. How many of those are required to achieve any success at all? If all ten are required, the chance of the user getting the dopamine hit of success is reduced. If, however, we can adjust things so that they can achieve some success with just two concepts, they are much more likely to gain that dopamine hit, and effectively engage with the product. At that point: their level of engagement increases, and their Maximum Concept Count goes up. They are willing to learn more concepts, to achieve more with the tool. If carefully staged, we may well get them all the way to all ten concepts, and have a fully engaged user.
– o –
Let’s take Grafana Grizzly. I’d like to think that it is an extremely powerful tool that can be used to build dashboards for Grafana (and other things too). We will focus on Grafana dashboards here. To use it, we need the concept of “dashboard”, and of “Grafana”. Given the dashboards are represented in JSON, we need to understand “JSON”. So far, so good. However, Grizzly was born as a tool to render JSON from the programming language Jsonnet. Jsonnet is an incredibly powerful language for dynamic generation of configuration. However, for many people, learning a new programming language is a daunting task – one that will put them off engaging with a tool.
As a solution for this, we have recently added support for parsing YAML files, containing raw resource definitions. Users can maintain them however they like. Now, a user needs to understand “YAML”, which they probably already get, and can leave “Jsonnet” until later in their journey as a user.
For Grizzly, it is early days in this transition, but my expectation is that this addition will have vastly reduced its Minimum Concept Count, and thus will significantly impact its reach, and hopefully its adoption also.
