Deep in start-up race – entering last sprint before POC, and a friend sends me a link to Marty Cagan’s most recent post on SVPG.  It’s all about the MVP vs. Minimal product.  (Read it here).   The thing in the article that resonates for me, a UX person, is how a “usability test” can be SO MUCH MORE.

View of my MacBook Pro using my iPad as a second monitor

Early morning in Portland, walking through the results of User Testing with the Scrum Team

It is critical  to figure out — when one is making a new product, especially, not just IF someone can use it….. but WILL they.    Will they buy it, and use it, make it a part of their lives, and recommend it to their friends and colleagues?  How do you find this out?  Lots of market research, sure.  But we can also grab some of this information during UX sessions — where we have traditionally focused on “can the user figure out how to perform critical tasks”  and “is the experience pleasurable — or  just not heinous.”

That’s why I am a big fan of the paired guerilla-style “User Test“.    These are 3-way sessions that take place between a potential user,  the user researcher, and a product owner.   My favorite product owner and I just did a round.  I was in Portland, he was in the UK, and our potential users were all over the world.  I set up a simple WebEx and shared my screen for the users to work through the session.  The PO was able to see what they were doing and take notes for his questions.  Generally, these sessions take 60 minutes.  I do the first 45 as UX and the PO takes the last 15 to talk about value proposition.

Here’s how it goes.

  1. Pull together a prototype that is pulled together enough for a potential user to work (or talk through how they would) work through the critical path that gets them to see the value.   This last part is critical.   No sense in wasting one of these sessions on — can you fill out all these form fields …. if you don’t show them the really cool thing they get from the product that sheds light on their world or saves them a bunch of grief.  Note… if you are very early in the process of product definition, you can even test a competitive product to get requirements for yours.
  2. Get together with the PO and put together a script.  Important.  Write a damn outline of what you are going to ask the users to do.  Make sure you run a proto-session and refine.  Have some flexibility in your pocket.  Test the most important things first.  You’d be surprised at how long users will spend on something you think is simple — or how someone who is really verbose will chew up your time.
  3. Recruit customers — or people who you think will be your customers.   Ask them to participate in a 60 minute session where they will be running through some tasks — followed by an interview with the product owner.
  4. Set the ground rules.  The UX researcher conducts the first part of the session and gets through the script.  NO INTERRUPTION from the PO.  When the UX person is finished,  the PO, who has been observing, and furiously writing down questions can jump in and ask follow-ups
  5. Run the first part of the session focused on task-based testing.  This is important!  Don’t just jump right in to a pitch and ask users  if they’d buy the product.   Stand by your locker and look cool.    Start by showing the user the VALUE screen.  The really cool reporting dashboard, for example.  Ask them three questions:
    1. where are you?
    2. what can you do here?
    3. what would you do with this?
  6. After that, your will have your context
  7.  Now ask them to go through some task activities that you are having particular difficulty working out — like sorting a big list, or filling out a complicated query string.  This is the “can a user USE this thing?” part.
  8. Once you are done with the test protocol, ask the user for any questions they might have.  This is a good time for the UX person to get at ease of use issues,  and most often provides a great segue to introduce the PO (who is dying to jump in by now) to join the conversation.
  9. UX person, shut up now.   Let the PO go in and ask all the questions that make us cringe.  Because, at the end of the day, we also need to know if the user would actually buy, or choose to use, the product, and if not, what it would take.  Very often during these sessions, the PO might realize we have the wrong target customer or user;  or that we’re solving the wrong problem or have the wrong approach.
  10. Have fun, and invite them back.  Record the session and share it with the scrum team.

Oh, and Marty Cagan also says that participating in user tests is “the single most important thing product owners can do to add value to their team, their product and their company”

http://svpg.com/the-most-important-thing/

Dude.