This week, I got asked a couple of questions about applications for user experience people. One was from a researcher asking which applications they should know how to use, another was from a designer worried that they don’t know how to use Flash.
Three minutes on the internet will reveal plenty of UX people who have very strong opinions about the applications that you should know. Sometimes they’re advancing the idea that you don’t need to use a heavy-duty application, but rather that a (relatively) lightweight application can do the job. For an example of that, check out the power of Keynote by Paul Woods. Sometimes they’re putting a stake in the ground and advancing that there is only one true way, such as this reference to someone who won’t hire designers who can’t code.
I generally don’t care about specific applications. Job ads often list a bunch of applications, and I know that I’ve written job ads myself with a list of apps, but I don’t think that anyone needs to know every single app on that list. A candidate should probably know at least a couple (and I’ll get to why in a minute), but knowing the whole list isn’t necessary (or even necessarily useful).
What matters for user experience is communicating with your team. Using the right application is a method of communication. If you’re working closely with a development team that tracks everything in Bugzilla, you need to use Bugzilla too. If you’re working with a design team that loves OmniGraffle, you should learn how to use OmniGraffle. If you’re working with a PM who never seems to have any application other than PowerPoint open, you’d better make sure that everything you send to them is a .ppt file. If you don’t use their application of choice, then you’re decreasing the chances that they’ll open your file or pay attention to your work. You’re negatively impacting your communication.
For researchers, I rarely care about specific applications. They’re nice-to-have, but they’re not need-to-have. Email, a word processor, and a presentation app are absolute requirements.
For designers, I think that you should be a wizard in at least one design application, and you should be proficient in another couple. Knowing more than just one application shows me that you’re flexible and adaptable. I especially like it when you can tell me that one application is great in this case, but another application is great in this case. And I want to know how you’ll get up-to-speed doing designs in a new application too, since it’s all but guaranteed that you’re going to have to learn a new one.
For researchers, I don’t think that you need to be a wizard in a design application, but you should have at least a reasonable knowledge of a couple. You’re going to be communicating with designers, so just as you need to be able to communicate with that PowerPoint-lovin’ PM, you’re also going to have to be able to communicate with your team who loves OmniGraffle. When you get a mockup from a designer that doesn’t quite work for your usability study that starts in 10 minutes, you can tweak it yourself. It makes your life as a researcher that much better to be able to use the design app(s) that your team prefers.
Leaving aside the basics of email, word processing, and presenting, I don’t think that there is any application that I think that every single UX person should know. The application is the tool. I care about what the outcome of using that tool is, but — so long as you’re willing to use other tools when necessary or appropriate — I don’t care what tools you use to do the job.
With regard to designers, in my opinion I think the necessary tools fall out into two camps.
For visual designers, they have to become experts in tools that produce both bitmap and vector graphics. That may be Photoshop/Illustrator or may just be Fireworks for both. Like researchers, you don’t care if it’s Word, just that it’s a reasonable word processor.
Same is true for interaction designers. They have to have expert skills in tools that produce wireframes (Omnigraffle, Balsamiq, Visio, whatever) and they have to have like skills in tools that produce high-fidelity mocks (Photoshop, etc.). The last required skill I’d look for in interaction designers is that they have some basic coding skills for prototyping. Whether that’s (html/css/javascript) or Adobe Flex or .NET, a good interaction designer should be able to prototype their own designs at least on the small-scale, or they’re going to be relegated to ‘sitting in the corner’ by the rest of an engineering organization.
I really like how you’ve broken that up. It’s not so much about the specific tool, but the generic type of tool that you use to accomplish the overall goal of having great wireframes and a good clickable prototype.