I don’t use Facebook much anymore so I just saw the new privacy settings prompt when I logged in today.

Redesigning something as increasingly complex and widely used as Facebook is never going to be easy. People are going to complain. I’ve always felt bad for the slamming Facebook takes on UI design but unfortunately I’m about to pile on.

Here is the default screen for Facebook privacy settings

OK, pretty straightforward except what are my “Old Settings”? I setup my Facebook account a few years ago I have no clue what those settings are.

I looked at this screen for a minute or two and then by accident my mouse hovered over the radio button and it revealed what the old setting was.

[Note: sorry I didn't grab a screen cap at the time and now I can't get to this view again. ]

Why would you put a rollover on a selected radio button? I have no reason for my mouse to go near a selected radio button since there is no action I can do on that form widget.

Their account view of Privacy Settings reveals this info quite elegantly. Not sure why they wouldn’t use this for the initial prompt screen?

I’ve noticed a few new services that have replaced the traditional registration form (email/password) with email as an alternative sign-up method.

TripIt, a travel service that creates a single, readable online itinerary from your flight, hotel or rental confirmation is the first site I noticed doing this. To register, a user simply forwards a hotel, flight or rental confirmation email to plans@tripit.com. The site automatically registers you and replies with a confirmation and link to your new itinerary. Brilliant. (Note: TripIt also provides the classic registration form as well).

What’s important about this is that they’re reducing a psychological barrier to entry. Most people using Flickr, Facebook, LinkedIn, Gmail, etc. feel signing up for yet another online service is an annoyance. After a while, another registration form can feel like a burden. Email-based registration avoids this barrier by rolling registration and the way you interact with the service into one action. For example, the same way you use TripIt is the same way you sign up, by forwarding emails to plans@tripit.com.

Of course, form-less registration doesn’t fit for every solution. While flushing out the IA for ImageSpark, our home-brewed creative inspiration tool, we decided upon the classic email/password registration. The reason being that the core interaction with the site isn’t done through email but rather integrated browser and desktop upload tools; For ImageSpark, there was no gain in baking in an email-based registration. (Although we hope this won’t stop people from using it.)

A service like Posterous however, which uses email to create and update a blog, is built on avoiding forms at all costs. It makes sense than that your first email registers you and initiates your first blog post, all in one.

I’m pretty sure we’ll see form-less registration grow into a design pattern as new services emerge. And I’m looking forward to using it, so long as the situation is right.

I’m a third of the way through Steve Mulder and Ziv Yaar’s insightful guide to to creating personas, The User is Always Right. As part of that process the authors provide concrete examples and rules for conducting user research for the initial phase of design for web.

I’m finding that so far, along with some great nuggets of insight, a good portion of Mulder and Yaar’s process refreshingly mirror our own here.

“…Traditional usability testing often isn’t as helpful for creating personas…When you give specific tasks to users, the test becomes about the user goals you have chosen instead of the users’ unique goals.”

One example of that is the caution the authors’ express when using usability tests as a means of qualitative research for persona development. In trying to understand users’ goals to ultimately craft the best experience, traditional usability testing tells us successes or failures of a given task at hand. Rather than uncovering what we don’t know, this type of research usually tests what we suppose is right or wrong with what exists versus informing what needs to exist.

That being said, user testing is effective when the conditions are right. Field, ethnographic and quantitative research are other means of research that provide great insights in our experience and that Mulder and Yaar speak to at length in the book.

If you’re interested, the pitfalls of user testing is something T+L have always been cautious of and something David has spoken about in detail more recently.

I’m looking forward to finishing the book and providing more feedback as to how it compares and contrasts to our process here.

Here’s a quick update for day 1 of CanUX 2008, Banff Alberta.

Luke Wroblewski kicked things off with what turned out to be a lively discussion of web form design—no small feat considering it was 9 in the morning! His talk covered some of the topics in his new book, so no need to get into the nuts and bolts here. A few things that stuck out:

• Web forms are this lynchpin in interaction design, but often don’t get the respect they deserve. And there’s really no excuse: there are a lot of evidence-based best practices to draw on.
• “Inside-out thinking”: Luke referenced this concept several times, and I think it pretty succinctly and accurately describes the mindset that drives a lot of bad design. Inside-out thinking happens when we stop empathizing with the user… 
• Beyond the form: before they can experience any functionality, most web apps force users to complete lengthy registration processes and whatnot. Drawing on sites like Geni for inspiration, Luke talked about integrating and embedding this stuff into a few lightweight, constructive actions that allow users to understand and feel accomplished in the site from the get-go.

Next up: Swim Lanes, a cool method for visually documenting design inspiration and requirements all at once.

Photo credit: mastermaq

The team at Clearleft launched a new application called Silverback. Essentially, it’s user testing software that allows you to capture screen actions as well as audio and video of participants.

There’s a free trial, or you can just check out the video demo to get a sense of it’s capabilities. Pretty slick.

I can imagine they had some challenges with this application. Not because of the complexities involved in designing or building it, but because doing something outside of your core business practice takes serious commitment (they’re an experience design firm, not a software developer). No doubt the two have similarities but It mustn’t have been easy leaving paying jobs on the table. I applaud them for making the leap – it’s a great idea and a solid execution.

We’ve gone down these roads roads before with little success. Our PVR report was well received but when we tried to actually build it we couldn’t commit the resources to it. We did it a second time with Paruba. Again, long term commitment was an issue. We’re actually about to venture into it again, albeit with a different approach. Hopefully with the same success as Clearleft.

Expanding the horizons and expanding the parameters,
Expanding the rhymes of sucker MC amateurs

~ The Beastie Boys, The Sounds of Science, 1989

I’ve always thought it’d be cool to be a scientist—a real scientist, with the lab coat and the beakers and whatnot. You could win friends and influence people (and pwn enemies) anytime, anywhere.

Sometimes I get the impression that I share this secret ambition with web and UI designers at large. After all, making design decisions that are “only” based in a team’s collective experience, thoughtfulness, observation, trial and error, etc. leaves those decisions open to critique. But grounding/couching your work in some sort of rigorous-sounding, quantifiable, testable result: that’s science…you can’t beat that!

Now, don’t get me wrong. Testing your design in appropriate ways can be invaluable (I’ll talk more about this in another post). But I really take issue with the idea that User Testing, per se, leads to great design. I’ve seen just the opposite happen.

I think this is the case because we’re trying to appropriate a tool that loses its power and actually becomes counter-productive when used outside of the context it was designed for. We’re borrowing from the experimental design paradigm in cognitive science, which is a scholarly discipline closely related to the applied field of HCI. But have you ever seen an actual experiment in cog sci? When I performed and ran a few of these back in school, they usually worked something like this:

• Sit someone down in front of a computer in a small room (maybe there’s a video camera or some kind of monitoring equipment set up)
• Have them stare at a dot in the middle of the computer monitor and hit A, B, or C as soon as they recognize some sort of visual stimuli presented to the screen
• Record the timing and number of errors
• Repeat the experiment with a bunch of different people, changing up one of two “explanatory variables” that you’ve guessed will have an impact on performance.
• Run statistical analyses on the results and use these to draw conclusions.

Now this kind of experiment is obviously very narrowly focused in its scope, and necessarily so. There are a bunch of reasons why, but the two main ones are these: reliability and validity. For an experiment to be reliable means that repeating it over and over again yields the same result. For an experiment to be valid means that it gives cogent answers (even if they’re only partial answers) to the questions you asked in the first place.

Interactive experiences like websites are complex phenomena. They don’t naturally lend themselves to the kind of experimental protocol described above because user performance varies greatly from person to person and from session to session. There are so many potentially confounding variables in play that reliability suffers. (The model experiment above tries to eliminate this problem by paring down the user’s task to a few basic actions.) You’re measuring 10th order effects and it becomes nearly impossible to establish causal connections between design characteristics and user performance.

If we do streamline things so that we’re just measuring one or two explanatory variables vs. 50 (say, by temporarily removing elements from the design), the experiment becomes more reliable, but less valid. That is to say, the results—while repeatable—can’t really be generalized to answer the type of questions that we want to ask in the first place (questions like ‘is this design easy to understand and use’), because we’re not truly testing the design.

Sometimes usability researchers will employ something called a “talk aloud protocol” to try and tap into the cognitive processes underlying user performance in a given scenario. This involves asking users who are testing a given design to explain what’s going through their heads as they move through some sort of task flow.

Again, I have real problems with this pseudo scientific approach to evidence-based design. For one, the act of talking about what you’re doing changes the nature of that experience. But more importantly, most people can’t accurately report on why they do what they do—that’s why there are such a fields of inquiry as cognitive science and psychology in the first place!

I don’t want to be overly cynical here, but do want to caution usability professionals and interaction designers in general: user testing can be helpful, but also misleading. It can also be a powerful political gambit or rhetorical expedient. If you’re going to test something, make sure you’re asking the right kinds of questions. User testing can be used to tune or optimize design, but cannot and should not substitute for creativity or thoughtful trial and error.