ºÝºÝߣ

ºÝºÝߣShare a Scribd company logo
Quick and Cheap
  Usability for
 Programmers
   By Megan O¡¯Rorke




       SD Ruby 4/1/10
The Plan, Stan

General idea of usability
What will/won¡¯t be covered
Who, What and Why?
Cheap & quick tricks of the trade
Audience questions
General Idea

Error free is not enough


World conquest = make the person on the
other end of your interaction happy
This talk will cover

Get actionable data


Methods for programmers
This talk will not

Cover an in-depth history of the usability ?eld


Go into all the techniques


Convert programmers into usability professionals
Who, What and Why?


Why: Other people¡¯s ESP sucks


Who gives the most useful feedback?


Real world data
Who: the Upside of Ignorance

People in the trenches have lost the na?ve perspective
Jargon becomes familiar
  ROR, PEBKAC
  IGO, NIGO
What/Why: Observation FTW!
Observation reveals what anticipation misses
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
Tips

Early & Often: 3 people, at least once a month


Discuss ?xing critical issues seen in the data


Sketch, prototype, scrap and iterate
Good Luck!

 Questions?

More Related Content

Intro to UX for Programmers

  • 1. Quick and Cheap Usability for Programmers By Megan O¡¯Rorke SD Ruby 4/1/10
  • 2. The Plan, Stan General idea of usability What will/won¡¯t be covered Who, What and Why? Cheap & quick tricks of the trade Audience questions
  • 3. General Idea Error free is not enough World conquest = make the person on the other end of your interaction happy
  • 4. This talk will cover Get actionable data Methods for programmers
  • 5. This talk will not Cover an in-depth history of the usability ?eld Go into all the techniques Convert programmers into usability professionals
  • 6. Who, What and Why? Why: Other people¡¯s ESP sucks Who gives the most useful feedback? Real world data
  • 7. Who: the Upside of Ignorance People in the trenches have lost the na?ve perspective Jargon becomes familiar ROR, PEBKAC IGO, NIGO
  • 8. What/Why: Observation FTW! Observation reveals what anticipation misses
  • 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 ?xing critical issues seen in the data Sketch, prototype, scrap and iterate

Editor's Notes

  1. 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
  2. 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
  3. 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
  4. 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
  5. 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
  6. 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
  7. 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
  8. 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
  9. 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
  10. 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
  11. \n