ISV Kaizen

I have an idea which I would share. It’s a raw concept but I’m sure that you can polish it and use somehow in your business.

Remember the installers that show slides with software features and benefits during the installation process. I’m sure that some of your applications also have such processes when a long operation performs and user simply has to be watching the progress bar for several minutes.
Why not to show a user something else during this period of time? E.g. you may show a tip of the day, news (e.g. RSS feed), link to your site/blog, a marketing slogan, or even a banner.

How it differs from adware:
1. You don’t bother your user while he actually works.
2. You display the a plug only while the user is bored and awaiting for the end of long process.
3. You may display not only ad, but also something interesting and valuable for user.

Installers have been using this technique for a long time and I wonder if other types of applications can use this trick also. I think this technique may be used in applications that deal with huge data processing, conversion routines, model rendering, compilation, etc., i.e. where there are routines taking up to several minutes. Why to waste those minutes?

There are many situations when you have an application but there is no help file with it, and you have no time to write complete documentation yourself. At the same time you have no budget to hire a professional technical writer who can do this tedious work for you. The situations come up fairly often and the cost-effective approach is best.

Read our new white papers: Writing Cost-Effective Documentation for Software Systems

One of the purposes of continuous software improvement is finding and eliminating the barriers that get in the way of users when they’re working with your software. Let’s name the most typical barriers that make your software less user friendly.

Confirmation message boxes
The most annoying things in software programs are message boxes. The message boxes force users to make decisions which they don’t want to make: delete or save, continue or stop, accept or decline, etc. Revamp your program to ask users less questions. As an alternative, it’s better to provide Undo\Rollback\History function in your software.

Status alerts
If you use message boxes for status notifications like ‘Completed’, ‘Done’, ‘Stopped’ or ‘Error’ then you may consider making a log window or a status bar that will display these messages without forcing a user each time to click message box OK button.

Ambiguity in user interface
If user doesn’t know what to do after he has launched your software then it’s another barrier. Check if in your software there are enough prompts, hints and signs that would help a user to understand what he must do to complete his task in your program. A user must simply follow your logical directions to receive the required results. Don’t make him to think much.

Initial settings
Sometimes the software application asks a user to make some initial settings before he can continue working with the program. This is a barrier also. Again, ask less questions. Try to preconfigure your software for most typical situations. Don’t make user to think about if he needs to check this option or not. Assume this yourself and don’t bother him.
For instance, if your software requires another software or third-party libraries to be installed on user PC then don’t claim from user to specify the locations of those libraries. Make your program to silently find the prerequisites on user PC and silently keep the locations in the program settings.

Software restart or computer reboot
Personally, I hate when a program tells that I must reboot my PC before the changes will take effect. I have a dozen of applications running and I don’t want to close and later to restore them all just to try another utility. I usually choose ‘I will reboot my PC later’ and may then even forget about the new installed software. This is a serious barrier between the program and a user like me.

Well, I’ve briefly mentioned just the most common examples of barriers that must be removed from any software or at least their presence must be minimized. I hope I’ll return to this topic in future and will expand this list. You are welcome to post your examples in the comments.

Kaizen is all about continuous improvement. I’d like to acquaint you with a tactics that I use to find out what else may be improved in our Dr.Explain software and other our products. Besides feedback from users, which is very important of course, I use a trick that I call ‘A Saturday Newbie’. The tactics is rather simple but very effective.

Once a week, usually on Saturday, I remove our software, Dr.Explain, from my computer completely, i.e. program files, registry entries, and installed files. Then I go to the product’s website and from this moment I try to act as a surfer who has absolutely no idea what is the Dr.Explain software. I read the software description on the web site, explore samples, online help, and use cases, read reviews and testimonies. I ask myself: “Do I need this?”, “Will it work on my PC or Laptop under my OS?”, “How much does it cost?”, and other important questions. I look for the answers on the site. If I fail to easily find the answers on the website then I tell myself: “Dennis, this must be fixed asap!”

After the initial acquaintance with the product overview on the website I proceed to the download section (if I’ve decided that I need this product ) and try to download and install the demo version. So, I check if the download link is easy to find and if it works.

Now, the most interesting part begins. After the installation, which should be completed smoothly, I run the application and try to figure out how this pile of buttons, menus and controls can make my life better.

What should be my first step? Which button to press first? How to start a new project? Is there a sample? I ask myself a dozen of questions. If the answers aren’t obvious then I say: “Hmm, guys, you must make this more clear if you want my money.” Seriously, I try to forget that I’m a developer of this software and try to find a hint for my first action. Is there such hints in your product? This may be a wizard’s window, a pop-up ‘Click me!’ balloon, or even a simple ‘Start’ button (You know what I mean).
The same rule must work for all my further actions. After each step in the program I look for another clue: “What’s next?”. If I have no idea what to do next after a certain step I make a record in our To-Do list to make the transition from ‘Step M’ to ‘Step N’ more intuitive and transparent.

The main purpose of ‘A Saturday Newbie’ tactics is not finding bugs, but finding barriers that get in the way of a user when he tries to solve a certain problem with our software. Every time a user launches our software, Dr.Explain, he has a different purpose. Same here. Every time I act differently. Sometimes I act as if I need to create a new help file from scratch. Sometimes - as if I want to open an existing project made in the previous version of the program and to export it into CHM or HTML. Sometimes - as if I need to merge several existing projects. I play as many parts as I may realize. BTW, analyzing user feedback helps find out how people use the program.

Just a simple example, the Dr.Explain requires the Microsoft HTML Help Workshop to be installed on user computer for compiling CHM files. In the early versions we forced users to manually specify the path to the Microsoft HTML Help Workshop folder before enabling CHM file creation. That was a true barrier. Currently, Dr.Explain automatically detects the path to the Microsoft HTML Help Workshop on user computer and doesn’t bother users with this question anymore. The barrier was eliminated. During every testing session I find more new barriers that none of the developers or testers has seen before. Forget everything that you know about your application. Forget that you are a developer of this software and, I’m sure, you will also find many barriers in your program.

To reach the maximum effect you must not only play different parts but play them on different stages as well. Change your environment for every testing session. Use different OS versions, screen resolutions, hardware environments, and user privileges. Run your software both in registered and unregistered modes, and with all possible licenses (Free, Regular, Professional, etc.). Each environment modification may cause new barriers for your software users. You must find those barriers and eliminate them to make your software really easy to use and intuitive. I hope that ‘A Saturday Newbie’ approach will help you to do this.

There are many software products that have a project-oriented concept. In other words they allow creating, editing, and managing projects or documents. The examples of the project-oriented programs are various text and media editors, database systems, spreadsheets, programming tools, setup builders, knowledge bases, and a lot of other applications. I’d like to gift you an idea about how to make project-oriented programs more user friendly and easier for getting started.

If you are an experienced developer and if your product has a long history then likely you have been using the approach I’d like to tell about. As for me, I came to this feature only in the second year of the Dr.Explain’s life. So, I think there are ISVs who also might be interested in my suggestion.

The idea is quite simple. Create a sample project or a sample document in your program and install it together with your program on the user computer. On the first launch of your application, suggest a user to open this sample project. For most people it’s easier to modify an existing thing to see how it works rather than to create it from the scratch themselves. Having a sample document in your software will help new users learn you product and get started quickly.

Try to include all the key features in the sample project to immediately show the wonders your application works. If your application is too complex and may be used in different ways then it’s better to create several sample projects or documents for most typical practices.

We started distributing the sample project with a new version of Dr.Explain 2.5.93 released in March 2007. Before we did this we periodically received user messages with requests to send them the project from which we had compiled the Dr.Explain’s own help file. People wanted to know how it’s done. With the sample, they could reproduce some of our techniques in their own projects. Now, new users see the sample project in recent document list when they launch Dr.Explain for the first time and they can play with it to evaluate the program. This works great for us.

Is there a place for sample projects in your software?