When I design a new software product for someone, typically with a team of experts, senior people familiar with the problem to be solved, the actual users of the software are rarely invited. As we lay out the target system, we’re working *for* someone, trying to guess how they work now, and how they might work in the future, using our new product. Usually it is several people, actually, different user roles who will perform different jobs.
We make a list of the things that they need to do for their jobs and make our best guess at how they will be able to do this in the future.
Now, place a bet, using your own money: On a scale from 1-100, how close would you expect to get in terms of getting the process correct?
I imagine you’d guess pretty low. Which is a reasonable approach, given you’re betting your own money. My guests, however, in my workshop, rarely consider how close this might be, and whether or not this might be a problem. Not that they’re foolish, or selfish, or inconsiderate. It is just that their attention is focused elsewhere, *on solving the big problem.*, and the workflow for a set of hypothetical users seems rather mundane in comparison.
Now, as much fun as it would be to spend time teaching my clients about the idiosyncracies of solution design, most don’t have the time or the interest. They want the job done, and done well. This is what they’re paying for, after all, not to listen to me pontificate.
Yet, we need a way to correct these shortcomings in our specifications, the fact that our use cases don’t fit the needs of the actual users. If we don’t, the product will come out lousy, and it will be blamed on us. And rightfully so.
So, how does one build use cases that match the true needs of the end users?
And how do we do this in a manner that is predictable, repeatable, one that we can have confidence in, when we tell our clients we’re going to do a good job?
Attentive readers might think back to my first comment, and suggest “Just invite the end users to the design workshop”. And in some scenarios, we might, but this is often not an option, for a variety of reasons. An alternative, having a subject matter expert (“SME” for short), is a much better fit, as they have likely performed this job in the past, or else manage a team of such users, so they have a greater awareness.
But this also consistently falls short of the mark.
“Why is that?” you might ask, hoping there is a conclusion to this dilemma.
Because it is really, *really*, difficult to imagine how you will do your job in the future, in a new system that doesn’t exist yet. I’m in my third decade of doing this, and I’m comfortable stating it as such. Even with a mockup, with functional wireframes, with whiteboards, etc., you will discover that you have gaps in your process that you didn’t anticipate.
Enter Agile Design.