Lying on the grass listening to La Boheme reminded me of when I was young, lying on the grass listening to Godspell in Thomas A. Edison Park.
A couple months ago on a plane to Florida I noticed an attractive teenage girl sucking a pacifier. She also had a funky skin condition, so I attributed the sucking to a medical condition. Since then I’ve seen more teenagers with pacifiers, baby clothes, and now sucking thumbs. I can’t find any news reports, but the Internet tells me it either began in the East or with ravers.
Is it a need for comfort in uncertain times? A reaction to the New York City smoking-ban-in-public-places? Or just the latest trend? Next I expect drinking from baby bottles, carrying blankets, and wearing diapers.
Cooper moves from the Valley to SF.
Referenced in Krug’s Don’t Make Me Think (still a staggeringly good book) is Gloor’s Elements of Hypermedia Design, the new URL for which I just tracked down. It’s like a set of ancient scrolls in a clay vessel that a recent storm has revealed from the sand of the desert. You know there is truth here, but also superstition and strange technology, da Vincian inventions pieced together into something unfinished.
‘…do scenarios and personas actually help, or do they just create a warm illusion of user-centered design?‘
She spends some time illustrating how products can drive personas…
‘Want to make personal security and encryption a necessary feature for [our persona's] email application? Let’s just give her a secret life in which she’s rekindled a dormant college romance via email.’
But we know that’s not a problem with personas, that’s just people creating personas improperly (personas, unlike guns, don’t shoot unsuspecting children, it requires a designer to do that). Research drives personas, and personas drive design, and design leads to products. Reversing that is incorrect practice, not a flaw in the practice.
I’ve also seen a tendency to focus the scenario too much on how a persona uses the website to the exclusion of other activities. When Marshall writes, ‘Notice, for example, that people use other communication channels besides their computers‘ it reminds me that personas should capture how people arrived at the site, what other sites they’re looking at, and what they do when they leave.
We know that to do this work properly one needs empathy with the users. And yet, people are, as George Bernard Shaw observed, bloody apes. People, some of them, can be nasty, messy complainers and it’s easier to just not interact with them. And this is why user-centered design is such a hard sell, because business people don’t want to deal with their customers. It’s easier to keep them at arms length – or further – with surveys and other market research. Personas and scenarios too help us keep people at arms length. Of course, they assume we’ve done our contextual inquiry yada yada beforehand, but that shouldn’t stop with the personas. In the tradition of the best industrial design it doesn’t stop, designers are always working with users. Researching and testing is ingrained in the process, not separate steps in the project plan. Marshall says,
‘Don’t just use scenarios and personas. Pay attention. Observe. Reflect. We’re all out in the world we design for.‘
Which, to me, implies participatory design. It means working more closely with those bloody apes that drive us crazy. This is the hard work we have to do to arrive at a great product. It means I don’t believe personas can substitute for interacting with users during post-research project phases. I don’t know a lot about participatory design yet, but I think it’s time to learn.
Wow, go to eye magazine right now and try the ‘concept index’ nav at the top. It’s sumptuous, all those P-words, the fading roll-off colors, the parallel columns inviting your mouse to figure eights. That is doesn’t lead you anywhere is incidental.
Re-reading Tog’s First Principles I just noticed the online version has newer notes specifically adapting them to the web… ‘Present the illusion that users are always in the same place, with the work brought to them. This not only eliminates the need for maps and other navigational aids, it offers users a greater sense of mastery and autonomy. As with the inherent statelessness of the web (see Track State, above), our job is not to accept blindly what the architects have given us, but to add the layers of capability and protection that users want and need. That the web’s navigation is inherently invisible is a challenge, not an inevitability.‘
Dovetailing nicely in this vein of application-meets-Internet is Usability Heuristics for Rich Internet Applications a new B&A article by Jess McMullin and Grant Skinner.
I love the Internet. Love it. I love the little search box where I can type anything I like and it will immediately return something, anything. I love clicking buttons and making things happen. I love following links to see where they lead. I love crazed, shameless teenagers blogging for all to read what I wouldn’t dare to say out loud. I love stores with endless selections and receiving packages in the mail. I love geeky academics and their irrelevant, fascinating pursuit of minutia. I love academic geeks and their endless variation of the social software hack. I love designers high on their own esthetic powers of creation. I love the self-promotional emails from my elected officials. I love the Dad-assisted emails from Mom. I’ll even admit to clicking a banner ad or two and, shit, I’m occasionally humored by the relentless, inane spam.
I’m tired of feeling ashamed of my love. I love the Internet, there it is. Fuck it.
When asked for examples of designs that would facilitate the desired user experience he replied, ‘Somewhere between Google and Yahoo.’
O’Reilly’s new imprint, Headfirst, integrates information design in the layout. Interesting.
Dave Cronin’s new Cooper article, RUP & Goal-Directed Design: Toward a New Development Process is a great look at the intersection of conventional user-centered design practice and systems-focused processes. Although he focuses on the Rational Unified Process, the ideas can be applied to any big software development project, and is helpful in understanding and communicating with developers.
He also hits one of the practices that currently drives me insane, gathering requirements…
One problem in effectively defining high-level requirements up front is that many development organizations understand requirements as something to be “gathered.” This “gathering” activity often manifests itself as customers and users volleying “requirements” emails and phone calls to the help desk, salespeople, and engineers. Often, these are then translated into line items in requirements documents. There is little thought given to reconciling requirements from different sources, and this reconciliation is often done at construction time, which can have all sorts of dire consequences, ranging from confused developers (who rarely have enough information to make educated choices between two apparently reasonable requests) to a confused interface (that is not grounded in a coherent and cohesive product definition) to confused users (who wonder why a function they never use is front-and-center on the screen).
Learning more about RUP recently, I realize I had some of it thrust on me before. Back at Razorfish a friend sneakily introduced aspects of RUP into our usual process while planning Tolerance.org. While activities like rating risks can be done anytime, we broke up the sections of the site into use cases. For many websites this approach wouldn’t work, as sites often need to work as a coherent whole, with changes in one section effecting other sections. In our case the sections differed significantly by subject matter and audience, so it wasn’t too harmful. I’m about to embark on another such situation, we’ll see what happens.
Refactoring is the act of altering code without changing the functionality of the application. The primary use of refactoring is to make the code simpler and easier to understand.
Not too long ago I wished for Designers Without Borders, a SWAT team-like organization that would drop designers into third world countries and give them help with technology no one else could offer. Brainheart magazine reports (albeit not online) on something close to this, Geekcorps: A US-based, non-profit organization, we place international technical volunteers in developing nations. We contribute to local IT projects while transferring the technical skills needed to keep projects moving after our volunteers have returned home. Here’s your big chance to go help the Rwandans.