Jethro Larson is a website designer/developer for Auctiva Corp. Jethro is a self-declared standards evangelist and user experience advocate. He strives for good UI, good code, and easy maintenance.
For more sources on Jethro, please visit:
Jethro’s contribution to developers
Now for the interview.
When and why did you get into this industry?
I started with web design in high school(2000-2001), doing a couple minor sites that have since been lost. In college I took courses in Computer Science, Communication Design, and Art. As it turns out, raising children, working, and attending school at the same time is difficult so I my grades slipped in a bad way. I was put on academic suspension and found a job at http://auctiva.com as a web maintenance guy.
I was assured that I wasn’t going to do much design or development work when I was hired. I also wasn’t given much to do so I spent my time learning. I read thousands of blogs and studied more web technologies than I can remember. I brought a lot of what I learned to Auctiva, which included AJAX, jQuery, XSLT as well as development tools like Firebug.
What is your specialty? Why?
Usability Design. In my studies I picked up a book, Design of Everyday Things by Donald Norman. This really struck home and I started seeing good and bad usability in everything. There’s a big difference between a product being able to do a task and being designed with humans in mind.
Here’s a big one: When usability fails many users blame themselves. So if you create a powerful product that’s hard to use, then the users will thank you whilst secretly calling themselves stupid for not being able to use it. You’ll never get complaints or bug reports from these people, they’ll just be lost customers.
Beware. Getting a taste for usability is like getting a taste for wine. You quickly find it hard to find anything you like. I hate all washing machines and microwaves now.
Is there anything commonly overlooked in web application testing?
From my perspective the biggest thing that’s overlooked is usability. Some would argue that this is a problem for design rather than testing but there’s no designer that can get web usability correctly everytime. Granted in a lot of development pipelines by the time a product goes to testing it’s too late to change the design but the more critics you have the more problems you can find. If I was a QA tester I’d want to get in on early prototypes and start testing products early in the design/development phase. Obviously this wouldn’t be trying to find all the technical bugs, you’re trying to find the problem areas that will get in user’s way later on.
Ideally you want to do usability testing on fresh people, not yourself. You’ll get a lot more out of watching someone else use a product than you will from using it yourself. There’s some great guidelines in Don’t Make Me Think by Steve Krug, that can get you started on simple, cheap usability testing.
For even more ad hoc moments I do what we call monkey testing.
- Find someone at the company that hasn’t worked with the feature, or even better the whole web site. The dumber the monkey the better the test.
- Sit monkey in front of the product/prototype.
- Give the monkey some context. If it’s a shopping application tell them to think of an item they want to buy. It will always be a banana, but it’s important that they choose.
Watch the monkey. If they get stuck you better write down what the issue was. If you can get them to think out loud that will help you as well, but don’t help them if you can manage it. Any developers designers responsible should be present, but make sure they shut up. - Throw away the monkey. Yeah, it’s harsh but usability testers are like cleenex. Once they’ve been used they’re spent for whatever you were testing.
The true advantage here is that you can get a quick usability test as fast as you can say, “Hey Dave, come here!”