![]() |
||
|
April/May 2007 |
Volume 47, Number 5 |
|
||||||||
So You Want to be a Usability Engineer?
Moving to another field is always a challenge, and that first step can be influenced by several factors. I was lucky to be in the right place at the right time–the company I worked for was acquired by a larger company that had a user experience group. I set my sights on becoming the first member of that group at my company site, and after over a year of pestering, cajoling, and pleading, I became a Level 1 Usability Engineer. At the same time, I commenced my courtship of the UEG manager, contacting him regularly to mention articles I was reading, to report design feedback I was providing to development, or to ask questions about the work of the group. I also began working with another usability engineer to set up an apprenticeship arrangement so that I could learn more about what he did. Additionally, I took some friends who worked in the usability field out for lunch and asked them countless questions. If you have a usability department in your company, you can follow a similar path. If the department does not exist in your company, you can start working on a plan to convince decision-makers of the need for one. You’ll find plenty of research that makes the case for the ROI (return on investment) of usability. However, moving departments within a company can create a new set of issues. Interacting with people in a different way than they are used to may generate friction, which can require some finesse. If usability has not been an important part of the process in the past, you will often find yourself having to convince people of the value of doing user-based research. Combine these issues with the fact that you are still a novice at what you do, and you have a difficult first year or two ahead of you. Technical writers often share the same passion for knowing the users, understanding their concerns, and helping them achieve their goals as easily as possible. They also typically know when they see a bad user interface, because they have to explain how to use it in seven steps or less. If you have done usability research, you know what it is. If you haven’t, begin incorporating usability research into designing and writing your documentation to gain experience. User and Task Analysis for Interface Design by Hackos and Redish describes some of these methods, and specifically relates to documentation. There are many other methods, including usability testing, card sorting, and affinity diagramming. After getting some of this kind of work under your belt, you can argue that you have experience in the field and would just be changing your scope from documentation design to product design. Several local colleges offer courses that can help expand your knowledge. Based on the job postings I have seen, employers are typically seeking degrees in Human Computer Interaction, Human Factors Engineering, Cognitive Psychology, or related fields, but degrees are often not required. A class or two in some of these fields would bolster your resume. You can also look into available seminars and training courses. The annual STC Conference, coming up in May, offers pre-conference workshops and certificate programs in usability. STC also has a Usability and User Experience SIG, which provides many additional resources. ![]() |
||||||||
|
||||||||
|
© Copyright 2007 |
||||||||