# usability testing on the cheap

* good usability can make small things feel big
* can also make big things feel manageable (e.g. Heroku)
* usability is expensive, whether outsourced or in-house -- $100/hr. for contractors

# caveat

* presenter isn't a UX person; she's a self-taught dev with a psych degree
* if you can afford a UX person, get one

## when?

* when you get the idea
* before you design
* before you code
* while you're coding
* after 1.0

## testing

* when testing code, test usability at the same time

### when you have an idea

* talk to your customers
    * where are they?
    * DON'T ASK "would you use this?" -- loaded question; people are polite
    * "do you use something like this?"
        * a way to find competitors
        * what doesn't it do? (the competing app)
    * face to face
    * outcomes
        * is it unique?
        * is it desirable?
        * who is your competition?
        * where are your users and how do you interactive with/communicate to them?

### where does everything go?

* cards
    * about 30
    * on each card goes an action
    * ask them to sort cards into piles
    * handwritten, so you can add more cards
    * watch them as they're uncertain, changing their mind, etc.
    * outcomes
        * what is the structure of the site?
        * what content is hard to categorize?

### make it pretty

* face to face
* have a neutral party present it
* questions
    * initial thoughts?
    * does it remind you of anything?
    * how would you...?  ( do this task, find this piece of information)
        * see if they can find x in the IA
* screen AND paper
* watch faces!
* outcomes
    * are you sending the right message?
    * can people guess what your content is intelligently, without using a search box?  ("i bet that would be there")
    * more the design appealing

### coding

* very small iterations, then go back and "what do you think now?"
* mock up new ideas first
* outcomes
    * are you on the right track?
    * did your users have a better idea?

### out of beta

* you're not done talking to your users
    * interview them again
    * are there any pain points to our system?
    * what do you like?
    * how do you...?
        * don't fight your users, make it easy for them to use it in the weird way that they do
    * outcomes
        * do your users still want your product?
        * what should you drop?
        * what should you promote?
        * is it time for 2.0?
            * are they getting bored with the site?

### accessibility

* don't do it at the end
* speaker wrote a book about it
* Penn State accessibility site
* accessibility suites ---> NO

### questions

* look at competition before developing your product?  really?
    * yes. look deeply, and you'll see where the market opportunities (weaknesses) are.
    * you need to know how to make a case for your product with users of competition.
* how do you know if the less-used features are critical for a few?
    * analytics, talking to people
    * if this is the case, promote the feature
* how do you find the testers before you build?
    * join local user groups, bulletin boards, meetup groups
    * start with Reddit
* how to get more feedback from the community once you've found them?
    * SurveyMonkey
        * look over those questions very carefully
        * get a psych person to look over them, if possible
    * email
    * face to face == best feedback, even from a much smaller pool