Boxes and Arrows: Comments by Teresa Torres

Teresa Torres — Fri, 23 Mar 2007 02:27:06 GMT

Jeff, great article. I recenlty was facing a decision between a UED role and a PM role and your advice then was invaluable. It turns out, despite choosing the UED role, I ended up doing a bit of both. I look forward to part II.

Teresa Torres — Mon, 09 Apr 2007 21:31:16 GMT

I’ve worked as a solo interaction designer for the past 8 years. I started in at a non-profit who hired me for my HCI background, but at that job, I ended up in a developer role. The company liked the idea of claiming they used a user-centered design process, but didn’t like the idea of making time for it. I learned to bootstrap and fit various methodologies into the process as time allowed. It wasn’t ideal, but I learned a lot about how to sell UCD. I spent a lot of my “outside work” time doing user research and got very good at quick informal usability testing.

At the time, I had no idea this was going to be the best training possible for me. Because since then, I’ve worked at startups, where user experience is crucial but resources are limited. I’ve found the following things to be crucial to success:

1) Don’t try to do everything all at once. I’ve seen a ton of young UED folks join a company who wasn’t familar with any design process and get completely eaten alive because they didn’t ease into it. People don’t want to be told that what they’ve known their whole careers is wrong. Nor do they want to be told your “better way” is the right way. People need to be shown that something works not told that something works. I’ve found the most effective way to introduce design methodologies to a new company is to not ask permission but to just do things. Think something should be tested? Ask some friends or co-workers who aren’t familar with the project to be your test subjects. They may not be “real” users but they will help to demonstrate the value of usability testing to the non-believers.

2) Understand the key business metrics and use them to support your case. I’ve found this to be invaluable. We’ve all been in meetings where people discuss which color is better or whether that critical thing should be here or there. I’ve found the most effective way out of these arguments is to suggest, let’s do both and measure which one performs better. This is another great way to bring evaluation methodologies to the forefront.

3) The role of user research. This is the toughest one to bootstrap. This may be the most controversial one, but I’ve found that user research is not always necessary. The easiest way to turn a company off of doing user research is to spend a bunch of time and money learning something that people felt they already knew. They key here is to identify what the different stakeholders think about their users. Are they all on the same page? Are they designing for themselves? What is the bare minimum required to get them on the same page and to start to understand real users. This is the hardest, in my opinion, to integrate from an organizational standpoint. Even if you can only do a little bit of it, be sure to highlight what you’ve learned and the impact that knowledge has on the success of the product. It will make it easier to win time for more research in the future. Eventually, if you are patient, the smarter stakeholders will start asking for the research upfront.

Teresa Torres — Mon, 09 Apr 2007 20:18:10 GMT

I’d love to see an article on this topic. I’ve thought about making the leap from designer/product manager to entrepreuner. But just haven’t done it yet.

Teresa Torres — Tue, 08 May 2007 18:08:14 GMT

It’s not enough to anticipate problems. You also have to explore solutions to those problems. Nobody likes the person who always points out what’s wrong with an idea or what could go wrong with a plan. But if you point out the problem and suggest some possible solutions, then you are being productive as opposed to just critical.

Otherwise, a good article. :-)

Teresa Torres — Thu, 21 Jun 2007 19:35:01 GMT

Amy, great article. I agree with all of it. I personally have the hardest time with “Go Deep, Not Wide”. I’m a perfectionist by nature and it’s hard to say no to something when it clearly needs design help. But I’ve learned the hard way (over and over again, in fact) that less is more. I’d rather work on fewer projects and really dedicate myself to them then try to touch everything and not be satisfied with any of it. It just takes discipline and lots of it.

Teresa Torres — Fri, 29 Feb 2008 03:27:38 GMT

I’ve done quite a bit of usability testing around this topic, including designs that used both checkboxes and links. I’d be interested to hear what you found.