However lately, I've realized that there's information in that-there calculation that could direct us to make better software, that actually makes more money in the long run by having lower ongoing costs. The big bolt came when I took a niggly support question from one of our support engineers, and was prompted to ask "How often do users ask about this sort of thing?". The answer in this particular case was "lots".
So, this led to me considering a few things about how we can make software that reduces the support load, and secondly, how to financially evaluate a design that does so.
Firstly, designing software that generates fewer support calls is a topic that has deserved much discussion for many years: writing more intuitive, easy to use, simpler software is obviously the key here, but there are still supporting tactics (no pun intended). The most common of these is of course good documentation and software help. If F1 works on everything and always takes the user to good information, then that's a massive start. Wizard-like behavior in apps is also great, as it is both tutor and workhorse, actually teaching the user what to do next as it goes. Often, after a period of using wizard based methods, users can then progress to using all of the interface features without the need for lengthy calls to a helpline or expensive tutoring (for them or the software vendor if they choose to do it for free).
I've also found myself drawn to nicely designed "start pages" in some apps - for instance Visual Studio - or - as in many other apps - the simple tip of the day or week. (My absolute favourite being in Google Sketchup: "don't run with scissors".) Specifically, the types of content I really want to start using in such tools are:
- Last used documents: it's right in front of you and doesn't demand using any menus
- FAQs: they are often loaded up from a feed, so are dynamic content, rather than installed content
- Training material such as how-to documents and case studies (also dynamic, rather than installed)
- Tips and suggestions for use (again, dynamic rather than installed)
What draws me to these is the fact that they are potentially tools I can hand over to our support engineers to manage their own workload. If a certain question comes through 20 times in the first week of a new release, they update the FAQs on the feed and they load up automatically the next time everyone starts up. If that stops only a quarter of the people that might have called next week to read it and not need to, thats probably a whole man-day of support time saved. The key here is dynamic content, rather than installed help, as that requires you waiting for everyone to install the latest patch to get the benefit.
There were two points here: how to manage the ongoing costs by design and how to actually evaluate their impact. Well, calculating the impact on ROI is no easier than calculating the ROI on a piece of software normally would, but if you can get a rough handle on the support and training cost and make a dent in it, then that's money back. And it's money back year on year (however at a diminishing rate if you're being good boys and girls and discounting your cash flow). Ignore me if I'm wrong though, but I'm pretty sure that we incur a higher proportion of support costs soon after release, so any support saving is a saving right at the time when positive cash flow makes the greatest difference to ROI.
Unlike investment in features and design, support reducing effort probably has a "positive offset" effect on ROI, rather than the potentially multiplicative effect of great design and function (as it gives your company the edge to sell more). This means that it's probably second on the list to the last essential feature, but I'd argue that it has a direct impact on user experience, so shouldn't be written off simply as "polish" that doesn't really make a difference.
No comments:
Post a Comment