What factors make you decide on using some software tool? Usefulness? Price? Good support? That’s for sure.
Have you ever registered for some service, spent some time on it and then canceled your account? How many gigabytes of installers or source code have youdownloaded and never continued to use? If I’m not an exception here then I believe you have answered yes to the first question and many to the second.
An interesting factor that is rarely considered : the relation between time spent on learning some tool to the benefits you will get from it.
The following observations I want to share were made for tools supporting some form of monitoring but I realize that they can be equally applied to most other software projects.
DISCLAIMER: Different people use tools in different ways so it is impossible to make exact comparison of tools from a specific domain. But I think it is possible and valuable to predict and make some general comparisons and observations.
As I mentioned earlier there are two variables that are considered here.
a) Time of learning some tool/service
b) Extra value this tool gives you
If we use a as the x-axis and b as the y-axis we can get an interesting plot called “the learning curve”
There are some interesting observations and examples when we try to plot those variables on one plot ( value in function of learning time).
The ideal situation is represented by curve A. This is the situation when a user sees the tool for the first time and they know how to use it and (what is really important) that using this tool gives them a lot of value. I think modern search engines are close to this ideal example. Usually people want to find something quickly and the famous google with its one textbox and one button does it quite fast.
The worst case scenario is presented bycurve Z. I think a good, general example of this curve is when a user doesn’t even want to start to use some service because it’s to high a level of complexity. This is very common in the monitoring world. I think this is main reason why small companies don’t care about monitoring of their infrastructure or services – it’s too complex a process, which can be handled by a specialized team in big companies. So they leave this even before it takes off.
Somewhere between A and Z are more common real situations (B). There is one rule here,the closer you get to A the better it is for you.
Curve L is also interesting .This can be the representation of tool that has limited capabilities by its nature (max level is set relatively low when compared to other tools on the market) but it is quite easy to use. This can be a cron mailto solution for monitoring of scheduled tasks – it is not customizable, has limited notification options, can be applied to cron only, etc. but it takes seconds to configure and some people take advantage of it. So this is the case for A, where you require a little of your tool from the whole spectrum of possibilities that are offered by your competitors.
Some modification of Z is X. It is the situation where a user started to learn your tools but quits after some time because of the too high complexity, bad documentation or some other reason This can be even worse than Z because the user has spent some time on your tool and ended with nothing so they are unsatisfied and more than likely will never return to you. You can imagine that there is probably some threshold of value that should be reached before some time has passed. If this threshold is not reached than the user quits your service.
This is just a brief thought, I think that this could lead to some nice observations when applied to some specific domains. This subject was buzzing in my mind thanks to some design sessions we had during the AlertGrid development. I realize that most of the time we fought with the problem ‘where do we put the curve called AlertGrid on this shape’ which meant what impact on the number of satisfied users has the complexity of our tool.
We didn’t want to go directly for A. This is hard road in this domain. You can think of an endless list of integration plugins to monitor something with all possible notification options (high value). It is impossible to achieve a short learning time for an unlimited number of plugins.
We did want to provide a lot of satisfaction even from the beginning of the work with AlertGrid – get rid of the X problem. A very important concept we added to AlertGrid is ithe nteractive tutorial which allows you to proceed through all AlertGrid steps in 5 minutes or so.
We were impressed by L. Low learning time is quite obvious but also we wanted to change the ‘features limit’ reason from ‘features below expectation’ to ‘really helpful feature set’.
Where do we end? We will see:)