Feb 2007 Contents
Old Dogs, New Tricks
By Fred Sampson
Fred Sampson is an information developer at the IBM Silicon Valley Lab, where he helps user experience designers create self-documenting user interfaces. Fred is a member of UPA, a senior member of the Society for Technical Communication, past president of the Silicon Valley Community of STC, and current Vice-President for Finance of ACM SIGCHI.
Now well into the twenty-first century, usability professionals and user experience designers might well expect that the value of their work would be well-embedded into the process of software development.
Not from my perspective.
Despite being firmly ensconced within the biggest of technology firms, the user experience team still struggles to make its influence felt beyond designing icons and selecting UI colors. I still hear development teams talk of UCD as the person who pretties-up the interface, not the process that makes their product usable. Usability testing is still an afterthought at the end of the process, not integral to the design process.
Too often, I hear developers ask if UCD has been involved in a design, when what they really mean is “have we asked UCD to fix the GUI?” They forget that the user’s interactions with the product include every touch-point, including instructions input on the command line, process and error logs, even the experience of waiting for something to happen without knowing if the process has stalled. Staring at a blue screen is an interaction, so you’d best design it to be rare and avoidable.
The situation becomes worse in so-called agile development processes, such as extreme programming (XP), scrum, and iterative development. I find myself repeatedly reminding software development teams that it’s not an iteration if you only do it once! I don’t believe that iterative development should mean designing as you go, nor does agility require throwing out user-centered design in the quest for rapid delivery.
A conversation with two user experience design managers yielded this observation:
Since when does adopting a new development or project management style grant permission to abandon time-tested design and usability techniques? Does iterative development mean teams can abandon sensible planning, and simply dump whatever comes to mind into the product without examining the total experience?
Concurrently, developers too often see information developers as the salvation to poor design. How do we break the habit of demanding that ID (Information Design) "thoroughly document" a feature that could be adequately explained with a few hints in the UI? Writing around a bad design won't fix It. Wizards should be self-documenting; if you have to write help for a wizard, something's wrong. Just when I think we're all on the same page, the new age of design is here, and the value of embedded user-assistance is obvious, along comes a new development team hell-bent on rending my fantasy to pieces.
Sadly, I sometimes see my development team as populated with prime candidates for the reeducation gulag, to be sent away incommunicado until they can return, enlightened.
Is there an answer to the problem lurking in that last sentence? Is there hope to educate developers to think like users, to set aside their prejudices (“It works for me, so it must be usable.“)?
As a member of the advisory board for a University of California Extension technical communication program, I’m thinking that the education solution might actually be valid and feasible. The program includes a “writing for engineers” course, that teaches software developers and others how to write valid English sentences, to avoid passive verbs, along with a dose of remedial grammar, to make their communications readable by non-developers.
What if we could offer a course or two on usability, on thinking like a user, on design thinking, on the user-centered design process? And encourage participation through employer incentives. A cynic might say that you can’t teach old dogs new tricks (but you can shoot ‘em!); I say let’s offer to train the old, and young, dogs some new tricks painlessly.
An old high-school friend of mine, armed with an English major, got a job in a large company training engineers and scientists in basic humanities, giving them the liberal arts education they missed in engineering school. Could we apply the same idea to sneak some usability sensibility into software developers?
I’m sure it’s been done somewhere already, and I just haven’t done the research to find the reports. Shame on me. UPA voice gave me this space to discuss something important to me, and right now I’d like to have my developers on the same page of the usability book, moving forward together to solve users’ needs. Perhaps the nice folks at UPA would give you some space to describe your successes. Just ask; our bark is worse than our bite.
|Contact the Voice|