in Uncategorized

Mindset, not process; Outcomes, not methods (What I would tell interaction design students, #2 in a series)

I had originally planned to speak in SVA’s Interaction Design lecture series yesterday, but had to cancel because I’m needed in the SF Bay Area. So, I thought I might blog the things I would have said

In school, and, well, in most companies, product design and development is approached as a process. The problem with this is that people stop being able to see the forest for the trees — they get so focused on following the process that they lose site of why they’re engaged in the process to begin with.

What’s more important than process is mindset. And when it comes to interaction design, that mindset is having empathy for and understanding your users, and creating something great for them. If you and your colleagues have the right mindset, you’ll likely do the right thing, because you won’t be satisfied until your users are pleased. At UX Week 2009, Aaron Forth, the VP of Product for, spoke. (You can see his talk here.) One thing that Aaron points out is that his team didn’t engage in anything resembling a user experience process, but because everybody at the company, from the CEO on down, cared about the user, they weren’t satisfied until they produced great results.

In Jared Spool’s talk “Journey to the Center of Design”, he claims that companies adopting a “user-centered design process’ actually produce less usable designs than those that don’t. What happens is that companies offload critical thinking onto the process, and assume that if they follow the recipe, good things will come out at the other end. It just doesn’t work that way.

Speaking of what comes out at the other end, that’s all that matters. Results and outcomes are what’s important, not the methods you use to get there. If a rigorous UCD process is what gets you to great design, awesome. If sketching on a napkin, then bringing that into Photoshop works, great. The proof of the pudding is in the eating — if people are happy to use the design, and it satisfies whatever tasks/goals/etc they seek to achieve, that’s what matters.

So, at most, use methods and methodologies as a scaffold to help you think and work through your problems. But don’t adhere to a process. Just use whatever works.

  1. Interesting article!

    I’d see some adherence to process and tools as being desirable. These are the means by which we produce something that expresses empathy and understanding of our users.

    Where it’s problematic, in my experience, is when it becomes dogma, process for the sake of process and little thought given to the context of the design effort.

  2. I totally agree. This shifts the focus from deliverables pegged to checkpoints along the process to what is actually delivered and consumed – the product or service. As with most advice like this, it’s great to have folks involved who are familiar with the bounds of a process before breaking them. Having a talented team who cares about the user from the CEO down also helps.

  3. My short experience thus far in human-robot interaction design corroborates your argument. However, I think (perhaps naively?) a team can benefit from the balance of having both a process nazi and outcome-oriented cowboys.

Comments are closed.