Wednesday, October 15, 2008

Getting to know your software

I've spend the last two days on a course for basic use of the software I'm going to improve. Seems like a waste of time? Read on.

Getting to know your software as a user
Developers of software are used to looking at software as a developer. There are very few times a developer looks at software as a user. What is the difference, I here you ask?

A user looks at software and sees what work is needed to reach his or her goals. The user values software based on how much work is needed to reach the goal and how much of it is tedious in the software.

A developer looks at software and thinks about the technology behind it and how much work it was to do this particular feature that he or she thinks is so great.

The fact of the matter is that a lot of the times, developers spend a lot of time building features that the user doesn't use very often. This sounds like it's frustrating for the developer, but he or she will hardly ever know this (thinking the lack of support calls is a testament to the greatness of the code and not to the lack of usage :-) ).

To improve this, playing around with your own software in a course can be very helpful. It's usually more productive than doing this at your usual desk, because of the distractions that are around. Also, a good trainer encourages you to work with the software and provide some practice examples.

Improving user awareness
The traditional way of improving on this would be to interview key users, but this is very unusual in a product development setting. Requirements and functional specifications are written by a department inside the company and developers just need to build according to these specifications.

So another way to get to know your users is to go to a user course of your own software.
This not only puts you in contact with some users, but it can also point out weaknesses in the functionality (or even technical issues, but then something is wrong in the testing process). A user course can do that trough the training material. Another thing to look for is explanations of the instructor. Ask yourself "why does this need explaining?".

And last but not least, questions of the users themselves are a valuable input. It may very well be that you would consider a screen perfectly intuitive, but your user may not understand it at all.

A basic user course a waist of time? I'd say no and encourage all developers to give this a try.

No comments:

Post a Comment