I’m sorry that I’ve neglected this blog so much the past couple of weeks. I will give excuses promptly, and then I will immediately follow that with another post that you will hopefully find of value :-)

So I was fairly sick this week and that really killed my output. It’s hard to pursue what you love when you don’t even feel alive. Turns out a lot of my friends got sick around the same time, so I image that something is going around. The irony (tragic, according to Meriam-Webster) was that last week was also when we had decided to demo our customer’s product.

And that is a great segue into what this post is about: how we do demos for our customers.

We do a loose form of agile development at my company, mostly due to the lack of much organization or planning as a whole. In general I think this is a good thing. On the project I am working on we are trying to do something closer to SCRUM. We haven’t quite mastered it yet, but we are doing iterations and demos for our customers and Neil and I meet every day to talk about progress. I am not quite organized enough at this point to keep up with a burndown chart and I keep forgetting to even do anything with the bug tracker. We are getting there nonetheless.

The point of my digression there is that we do these demos for the customers, but instead of just showing them all of our features we try to take it a step further. Features are great, but if the program is hard to use it doesn’t matter.

So what we do is set up a GoToMeeting session, I explain how we are in the project timeline to make the guys with the money happy, and then we give control to whoever will be using the feature we have completed. We give them a few directives but no directions, or at least as few as possible.

Usually they figure stuff out, but it is interesting to see what they try, and that gives us a good idea of how they think. For example, yesterday we were demoing a user system with groups. The way you would add/remove groups from a user was to drag the groups from/to a couple of grids. Seems simple enough. But the user tried to drag available groups onto the user data instead of into the user’s groups.

So when I get the chance I will make it so that that works too. The other interesting thing is the following conventional wisdom: users don’t read directions. I know that’s true, but every now and then you think, “hey, this is something that’s not perfectly obvious, so let’s put a but of text in there to make it clear.” We put something like six words in this panel, and they were at 25pt font. Guess what? Even though they were on the panel that they explained, the user didn’t read them. I may or may not leave the words there, with the knowledge that they currently just clutter up the page.

There are numerous reasons to do demos this way. They give the customers a sound mind that everything isn’t just faked. We can see what we are doing wrong from a design perspective. The customer can raise objections about possible misunderstandings we may have had. And with a user base as small as we have, we are also training them in the new application piecemeal.

And it looks like I may have to put off that other post as I have a hot date now :-)

Have a great weekend, and stick to your requirements!

Posted Sat, Mar 28, 2009

Receive Blog Posts in Your Email