How to Apply User Data to a Redesign.
"We believe implicitly that the scientist is one type, the artist a radically different one. In fact, the scientific and artistic personalities overlap more than they differ." – David Gelernter
I've been meaning to review both Spolsky's book Joel on Software and 37signals' e-book Getting Real for a little while now. They cover many of the same topics – software development, software-centric project management, and design techniques, among others – and agree philosophically on many points. I found, in particular, that their shared support for prototyping GUI elements early on appealed to my personal approach, as well as my educational background.
They certainly don't agree on everything, though, and I had some trouble reconciling their opposing arguments. Their most obvious point of contention, and the biggest hang-up for me after reading both sides, was with regards to the amount of design and architectural work that should be done up-front. In short, whether or not to have a functional specification before work on the program begins.
(What's a functional specification?)
Spolsky argues that a functional spec is necessary for three major reasons. First, its creation forces the developers and customers to define the scope of the software up-front, thereby theoretically eliminating feature creep and allowing everyone involved – including the customer – to approve the final product before any development effort is expended. In this way, there are no surprises and no time wasted writing software that ends up doing either too much, or too little. Also, he argues that a functional spec's presence from the get-go should reduce time spent communicating changes later on, which results in less total time spent and fewer errors made. And finally, a functional spec would facilitate the up-front creation of an accurate schedule.
37signals largely argues the opposite, in the aptly-titled chapter "There's Nothing Functional About A Functional Spec." Briefly, they believe that functional specifications "force you to make the most important decisions when you have the least information." The spec often ends up being altered later on anyhow, so there's little reason to spend all the time drafting and agreeing up-front when prototyping could already have begun. Furthermore, specifying in detail how the application should work before it exists disallows the inevitable changes which must be made when the customers actually get to use it. 37signals believes that instead of writing a spec, one should "write a one page story about what the app needs to do. Use plain language and make it quick. If it takes more than a page to explain it, it's too complex."
To be fair, the companies create different types of software -- Spolsky's Fog Creek creates feature-rich web and desktop software, whereas 37signals' apps are entirely web-based and purposely minimal. Both companies have had their share of success, although one could argue the latter company has become more of an overall phenomenon. But regardless of the type and size of software under development, the arguments hold water. Both methods have clearly been proven to work, and in similar situations.
Where's this going? Well, I found this disagreement interesting because it implies a much more fundamental argument: whether or not to listen to user input during the design phase. More nicely phrased:
"I think the most important reason for having a spec is that it puts the decision-making authority in the hands of the correct people - the users. Without a spec, the developers will either have to pester the users every time they try to develop a new feature, or (more likely) they will make decisions and assumptions on their own about what the users would prefer." – Jesse Smith
37signals is pretty against involving users up-front, arguing that they, the developers, know what users want just as much as the users themselves do; this argument is of course a rephrasing of the old saw, "Users don't know what they want." (Which is, incidentally, true.) This argument starts to lose potency when the users are dissimilar to the developers, though, and when developers create software for people different from themselves (say, zookeepers), they really need to stop reading books and get a professional HCI / UCD guy.
As a theoretically professional HCI / UCD guy, I believe I have lately figured out how to reconcile the functional-spec disagreement in my own work. It's a pretty hard problem, and not one I propose a solution to lightly.
A traditional HCI / UCD approach to user-centered redesign is thus:
- Gather data about the users, via contextualized interview techniques.
- Model the users' mental states, processes, and flow, in order to understand the users.
- ???
- Redesign.
At school we often found ourselves hitting a wall at step 3. How does my understanding of individual users allow me to actually create a better design? I know that people can't find the Print command, but that doesn't tell me what to do. With a corpus of user-centric data, the leap to a new approach is usually painful and sometimes magical. We often ended up using affinity diagrams, which are something of a cop-out. In my humble opinion, affinity diagrams substitute groupthink for process and inspiration.
The Spolsky / 37signals disagreement over the value of functional specs provided me a solution: write a minimal, one-sentence functional spec from the user's point of view. As either a developer, customer, or UCD researcher, your understanding of the user's wants, needs, and beliefs come out in that one sentence, and you end up making any incorrect beliefs or assumptions explicit. Ask your mental model of the user, "What is this application supposed to do?", and write down the answer. If you're working in a group, have everyone write down their own answer. Then, compare. Any misgivings, misunderstandings, or false assumptions will surface immediately.
Since a one-sentence functional spec is focused in intent but blurry on the details, it doesn't force features to be decided upon immediately. Instead, the overall purpose of the application reveals itself. And, once a one-sentence spec is created, it can be written on post-its and taped to monitors. I've found that once the one-sentence spec exists, it becomes something of an oracle, shooting down most feature-creep ideas pretty easily and guiding the overall direction of development.
It works for me, anyway. Here's an example: "Vocabulicious is a new, free word game for Windows and Mac OS X."
posted by avixe @ 2:46 PM
2 Comments:
I sort of see it as an attempt to address, at an early stage, the inevitable user question: "Why do I care?" It's almost like this one sentence should be the first sentence on your website or press release, or whatever. It makes total sense that that should drive design decisions.
There's a lot of talk about user goals in HCI. In fact, the whole point of all those initial methods is to extract user goals from people's descriptions of their current tasks. An interesting thing about your approach is that the user-centered one sentence should actually connect very strongly to the designer/developer's goals.
In other words, "Vocabulicious is a new, free word game for Windows and Mac OS X," should be an exciting statement for both the users and the creators.
Now I have something to design to, *and* a reason for designing it.
--
As a side note: do you think one sentence is really the magic length, or does it just have to be short?
I don't know that one sentence is necessarily magical, but when it comes to sticking it up on monitors or, presumably, powerpoint slides, it certainly makes it less work (and more impactful) for the reader to keep it at one sentence. The key, though, is to summarize to the point where details can't be mentioned; the Getting Real approach of the one-page design doc still seemed too long and involved to me.
I agree completely that the purpose of the up-front contextual methods is to extract the user's goals from his or her activities, but I've found that a list of goals does not inherently drive design direction to the extent that a single, to-the-point statement does. It's tough to decide against a list of goals; it's much easier to decide against a single one. (At least, for small teams.)
Not sure if you were alluding to this or not, but in fact that sentence did end up as the first sentence on the Vocabulicious web site. It just seemed to fit well there.
Post a Comment
<< Home