9. How
In house labs vs portable usability labs
Cheap and fast outsourced options:
feedbackarmy.com $10 for 10 people’s feedback
usertesting.com $39/user, get video + written report
10. Tips
Early & Often: 3 people, at least once a month
Discuss fixing critical issues seen in the data
Sketch, prototype, scrap and iterate
Hi, my name is Megan O'Rorke and it's my pleasure to be here to speak about usability tonight. I got my bachelors of science from UCSD in Cognitive Science with a focus on Human Computer Interaction. Human Computer Interaction is commonly abbreviated HCI or CHI and the idea behind the field is to make the interaction between people and computers more efficient, effective and enjoyable. That means is that given whatever the project's constraints are: physical, virtual, political or other; I and people in my field do everything we can to make the experience a pleasant one for the people on the other end of whatever interaction is being built- whether it's a database, a path through a physical building, or completing any variety of the types of tasks you can do on a website. \n
First I'm going to start by explaining the general idea of usability, then briefly set expectations for what will and won't be covered in this talk, share some tricks of the trade- cheap and quick things programmers can use, and at the end I will answer audience questions as time time slot allows.  \n
So the general idea behind this field is that eliminating all the error in the code will not guarantee you conquer the world whether you measure that by largest market share, most conversions, etc. As Apple has proven over the last few years it's not enough to have something that is error free. I'm here today to share a bit about how programmers like you can take advantage of what people like me have learned about how to get concrete data and action items of things to improve the interaction between what you're building and the people on the other end. I'll also let you guys in on a few cheap and quick solutions for programmers. \n
I am going to tell you how to get actionable data and quick and cheap ways you guys can get your hands on some data if you’re budget is as little as $100 and your time frame is 2 days from now. \n
We’ve got limited time so I’m not going to cover an in depth history of the field, or describe in detail all the various techniques. I’m focusing on a very small portion of the techniques that I think will be useful and easy for you guys to incorporate on your projects. And this talk will not convert programmers into usability professionals. \n
So how do we get this data? Who do we recruit, what do we have them do and why is this useful? Would watching someone sitting next to you at work give the same data as your target users? What should the task be? \n
The people who will give you the best data for feedback will be the ones who haven’t been working on the project 10 hours a day 5 days a week. \n
Observing people try to do what you’re hoping they’ll be able to do when using your program or website works so well because very often people will do something you did not anticipate or NOT DO something that to you thought they would do (like click on the question bubble or read the instructions you wrote for example).\n
In house labs- usually you need at least 2 rooms- 1 for observers, and 1 test room, speakers, microphones, screen sharing software, a moderator, and recruits willing to come to you. \n\nFor what’s called a portable usability lab: laptop with a built-in camera, and screen recording software. In other words the mac I’m using now + “Silverback” which will record the screen and optionally audio and video of the user time synched with the \n
Unless you’re planning on writing a research paper, test early and often with 3 people at least once a month. After the tests discuss how you’re going to fix the critical issues. The hardest part will be sticking to the issues you’ve seen in the data. Hack together something that resembles what the final interaction will be and test that on someone new. Sketches and prototypes are faster to scrap or iterate than lines of code. \n