My job these days is to be sure that software does what people really want it to do. Now please bear with me here because this isn't technical and, besides, everyone already knows that software never does what we want and it's so frustrating for everyone.
Take Twitter for instance. What people really want Twitter to do is make us very popular among the masses. Kind of thumb peck your way to rock star status without even knowing how to play a guitar. But like so much other software, it just doesn't deliver. What actually happens is our kids and our old friends that we never see or talk to all follow our mindless tweets so they know we are still alive and that we still don't have anything interesting to say so there isn't even any point to giving us a call just to check in.
The real final effect of Twitter is to make the cell phone useless as a way of having any real social contact and make us all suckers to that added digital package the cell phone carriers charge us for. They don't charge us extra for talking but Twitter has made talking so, like, totally yesterday. Maybe Twitter is just a big cell phone plot to make us stop using the expensive voice bandwidth that comes with the service and charge us extra for the cheap text bandwidth. Its the same tricky con as bottled water. They've got us believing bottled water isn't tap water even when we know its just the same.
So trying to really figure out what we want software to do and how we use software could be really useful now that we spend a very considerable part of our day just trying to cope with it. One of the popular ways of doing this is to consider 'use cases' which is simply how people use software and what they hope to get out of it. Now I'll admit that use cases does sound about as empty as my tweet about checking the weather report on the Web, so an example might help here.
Take for instance the use case of getting some cash from an ATM. It turns out that this is the standard use case example that was used back in the '80s when the idea first emerged. The concept needs an actor, which is a human, a system which is the ATM and a goal which is grab the cash. Since it helps to have real people in mind along with a real system and a real goal, I'll use my wife as the actor in this example because I know what she does.
In this case, though, the actor (my wife) doesn't have an ATM or a debit card but she still has the goal of getting some cash before she goes to do lunch with important people. So she goes to the nearest ATM-like system which happens to be a small wad of cash I take out of my jeans pocket and dump on the dresser before I go to bed. This works out great for her. The actual steps she takes are 1) she rifles through the cash carefully pulling out the biggest bills and 2) she leaves me with the one's and small change.
However, like all software, there could be glitches in the system. Kind of unexpected things happen that the people that make software have to think about. For instance, maybe I didn't leave enough cash on the dresser or maybe I didn't empty my pockets so the cash will have to go through the laundry first. This kind of thing is called a 'scenario' in use case lingo and scenarios have to be taken into consideration.
In this scenario, the ATM-like system could include my wallet which the actor (Wifey) has to first find and then pillage. Here it is best to realize that actors aren't stupid and can figure out interactions that will achieve their goal even if the default pile of cash doesn't exist. Now to be fair to her, I must say that when she hits the real system jackpot (my wallet), she usually leaves a post-a-note something like, "What depression? I took a $20. I love you." So this scenario works fine, too.
At least it works for her but things could get complicated for me. Consider this next scenario which is where I become the 'actor' and want to 'use' the 'system' which is My Friend Joe, the espresso stand in the downtown quad. Again, in software parlance, this could be considered a 'critical path', or at least I consider it that way. It means that if I don't get a triple espresso right away, I could end up sleeping on the lawn instead of going for another maniacal run. It turns out that they won't take my plastic for the triple espresso and the last $20 isn't in my wallet. So has the 'use case' covered this scenario?
Again, actors aren't stupid and will find more ways to use the system if the system has been designed right. So I whip out my cell and start Twittering, suggesting that everyone following me up to this point immediately donate to the cause of developing even more pointless software – Pay By Twitter - by putting money into my PayPal account. If I'm not going to be a rock star or another Bill Gates, can I figure out a solution to this use case that will support this software cowboy when he's fresh out of coffee-powered brilliance? Surely everyone will want to cash in to the next big thing on the net by sending money now.
But are all my fans going to p(l)ay along? Again, actors aren't stupid except when they are use case designers on a caffeine panic.
