My colleague Alex Faaborg wrote an excellent blog post (in response to my last post in response to Ivanka Magic’s post) about some of the limitations of the contextual design process and designing using personas. I fully agree with most of what he writes, and wanted to draw attention to some of his points to present a more complete picture.

Contextual Design isn’t a Hammer, the World isn’t only Nails

Contextual design isn’t a blunt tool that can be blindly applied to any design problem. It’s an extremely structured, formal process that is best used when approaching a complex design task with highly diversified users. A task it was ideal for, for instance, was my thesis project in which my team designed a mobile device for Nasa engineers to report and diagnose problems. We were working in a complex space and for very specific users, where the very structure of workflow of tasks had to be redesigned before solutions could be considered. By following the contextual design process nearly to the letter, my team was able to explicitly shift our focus first to the user and the user’s space, then to the user’s workflow, then to the workflow within a system, and finally to design solutions that corrected the problems the user faced.

Every problem truly has its own “context,” and choosing an appropriate design process to fit the task at hand is an important challenge in user experience design. This process, even for simpler design tasks, should resemble at its core contextual design and the specifically the scientific method. It should begin by identifying the problem. It should progress to a phase of research and investigation into users and user needs. It should enter an iterative design phase, in which ideas are tried out, tossed aside when shown not to work, and improved upon. It should be subjected to user testing, and the subsequent data should inform the design.

I do disagree that studying users in-depth is less useful when designing for a larger audience. It’s true that the most you could say about what Ubuntu users have in common is that they are humans who use Ubuntu, and they certainly aren’t as similar as the relatively few Nasa engineers I was designing for. But all users have some similarities that they’ll apply to tasks. For instance, in general humans can learn, humans try to understand new tasks by leveraging what they know about other tasks, humans like to not be bothered, humans like to feel respected, humans like to feel in control, etc. Human similarities means that giving a few humans a task will allow the designer to draw inferences about what other humans will do in similar circumstances. User testing is basically this: extrapolating from a few people in a specific context what others in the same context will do. It’s valuable information, and something I think we should be doing much more user testing in open source.

Personas can be Useful for Shared Language and Understanding in a Design Team

Faaborg brings up personas (not the lightweight Firefox theme, but the notion of creating a small set of hypothetical users who embody the attributes of users you are designing for) as an idea that’s not useful when designing a product as universal as an operating system or browser. The usefulness of personas in user experience design is a bit of a hot button issue. Personally, I have found them to be useful, but only in response to user data and within a design team. Faaborg mentions that Microsoft created “aspirational” personas – the hypothetical user they were designing for who they wanted to create. I can see why this could be useful in marketing, but in user experience I believe you should design for the users you have and not the ones you want. Personas are useful if, when you did that user testing, certain participants with similar backgrounds behaved in similar ways. For instance, in Firefox, certain users perform all browser operations with their mouse. Other users, especially ones who consider themselves tech-saavy, tend to use key commands. We’re designing a browser for both of these groups, so giving them explicit names and characteristics can help create a shared language for a design teams to think of these groups in. It’s not the only way to approach data, but it’s one clear method of giving a lot of data and shared understanding an explicit label so it can be described without citing or explaining the shared understanding.  Also, we do this naturally by saying things like “my mom couldn’t do this,” “my grandpa won’t get it,” “the Linux guys’ll be mad.” Why not be explicit about user groups, give them names, and in the process be nicer to your poor old mother?

Ubuntu Buttons: Redesign them if There’s Cause to, Mmkay?

Faaborg’s advice on what to focus on for the actual task of redesigning Ubuntu’s windows is dead on. What I hope the Ubuntu team will focus on are issues like visual language that explains the task, natural mapping, target size and shape (will these controls be blocked by other windows? are they hard to hit? is it easy to hit the wrong one if you’re in a hurry?). I hope they will identify user-centered reasons that the buttons should be designed rather than changing them because they’re old or it seems like time for change. And, of course, I hope they’ll test their design with users and explain their rationale.