Boxes and Arrows: Comments by Amy Hillman

Amy Hillman — Thu, 29 Mar 2007 00:06:13 GMT

Thanks for your comment Kate—I wholeheartedly agree. One of the worst things you could possibly do (IMHO) is to take on a huge, highly visible, project as a way of introducing a company to usability/UX methodologies! It’s not likely that you’ll be given free reign to overhaul the entire process on your first project—especially if it’s a critical one and you’ll end up trying to squeeze in a few techniques here and there (as you mention). Starting with a smaller scale project where you can track the results from start to finish is an excellent way to ease people into new processes. There are so many different elements that have to be cared for—not getting in the way of business getting done (that’s what we’re here for afterall), not stepping on toes, teaching, nurturing, explaining, evangelizing, advertising… it can take a long time to shift culture and processes and it certainly doesn’t happen overnight. But what’s cool is that people REALLY get it when you can show them how a smaller project, in their very own company, was a huge success because of this new approach to product development. One incredibly important thing I’ll add is that it’s crucial to really document that first small project because you need to be able to paint the “before and after” picture with real, tangible, points and data to back it all up.

Amy Hillman — Fri, 27 Apr 2007 17:19:00 GMT

This sounds like an incredibly useful article and I would love to see it published. Morae is such a great tool—showing how we can use it for heuristic evals and remote paper prototyping sessions would be excellent. It’s got my vote.

Amy Hillman — Fri, 27 Apr 2007 17:33:09 GMT

Great idea—I’d like to see this article. There are so many different approaches to prototyping—method, materials, when in the process, etc. In particular I think it would be nice to see an overview of different methods (maybe case study/process overviews for specific companies or practitioners?) and different ways of applying them in the product design lifecycle. Are prototypes used to generate ideas? Validate designs with users? Refine product/business requirements? Communicate vision to the VP/C levels? I bet there are vast differences in the ways people are applying prototypes to their work. What about the paper vs. screen prototypes debate that’s going on over on the IxDA discussion boards? Lots of interesting perspectives there… Good luck Todd, I hope to see this on B&A in the future.

Amy Hillman — Wed, 27 Jun 2007 07:24:45 GMT

Terry,

Thanks for your thoughts on this article—it’s great to get some additional perspective from another UX practitioner who’s spent time in the trenches. :)

I can’t say I agree with the argument that presenting time/$$ savings would “do more harm than good” when advocating a UX process. In my experience it’s always been one of the biggest selling points. But you do have to present those claims carefully. A critical component, as I mention later in the article, is managing expectations. Being honest with yourself about the level of acceptance for UX methodologies at your company, and on the team, is important. Take small steps first, on less risky/visible projects if necessary. Clearly communicate throughout the entire process (especially when you’re in the very early stages of introducing these new concepts). And then connect the dots for everyone so that they really see and understand the time/$$ savings.

If you have past experience proving the ROI of UX activities it’s a great way to show exactly how your process has worked before. If you don’t have a case study in your back pocket, find one—there are many examples of how a UX process has saved other companies time and money, online and in many of the great UX books out there.

One to check out is Cost Justifying Usability, by Bias & Mayhew: http://tinyurl.com/36836g

In the end, I think much of it comes down to communication. (As with much of life, I’ve found!)

It’s funny, but often I find myself observing and analyzing the user experience of my own team and company—and applying a similar approach to my teaching/advocating as I use in my research and design of a new product. I talk with my coworkers to find out what the current process is, how they feel about it, what’s working and what isn’t (contextual research, requirements gathering); I test the waters and explore different ways of applying these methodologies (conceptual “design”, user validation); and I document how the process worked before and what the effects are after adopting a UX process (baseline evaluation, comparative results reporting). Sometimes, it almost feels like a process within a process. :)

One great point you make is that UX activities serve as an excellent PR opportunity! In hindsight, I might have added that as another argument to be made in favor of a UX process. Talking with customers serves multiple beneficial purposes. You gain an understanding of your end users and ultimately build a better product, but you also get to start making a positive impression on them before you’ve even built that product. People really take notice when a company cares enough about their experience to ask them what they think. It’s win-win for everyone. Excellent comment, thanks for adding it to the conversation.

Amy Hillman — Fri, 22 Jun 2007 17:36:22 GMT

Here’s a shorter, hopefully fully active, link to the Bias/Mayhew book: http://tinyurl.com/36836g