UX Centered Product Leader

Think, Make, Learn – Super Lean UX Research

Last night I was honored to Meetup with some folks who are entrepreneurs and business-minded designers working at the intersection of UX, customer development, lean startup, and agile. I got to share what I’m doing at Tellagence. Specifically around the topic of UX Research.

Which is top of mind for me — as I should be writing a Quarter long “Research Plan” — but that will be another post.

We started by talking about Lean Startup and how what it means for us as UX people. I shared that the idea THINK, MAKE, LEARN (or Learn, Build, Measure) is what we as UX designers do so naturally. There is a great article here about that that I clipped from Cooper Journal a while ago.

If you build immediately — start in lo-fidelity and then get informed.

How do we get informed? In the twenty-five years I have been designing experiences –first as a theatrical designer, now as someone who designs software — the best way I have found is to first put something out there, watch people’s reactions, learn what worked and what didn’t — and then try again. This worked for me as a lighting designer. I’d set up a test in the light lab — usually hanging 8 to 10 instruments — experimenting with angle and color BEFORE I drew up a light plot and paid union guys to hang 500. I’d go see shows and spend most of my time looking up in the air at the lighting rigs — trying to figure out the design, and watching the audience reaction when the lights changed the look and feel of what was happening on stage.

So now, I do the same thing. Only I am learning about how people use software applications (or not) to solve their problems or add value to their lives. I am designing some lo-fidelity prototypes, and putting those in front of people.

Last night I shared some examples — some artifacts from user sessions that demonstrated examples of working with people to think, make and learn.
For the “Thinking” part, I showed some clips of generative research — out in the field watching people who mind their social communities use toolsthat are out in the marketplace to help them to grow their social network value. I demonstrated how watching people generated ideas for features and functions that would be USEFUL as well as interaction paradigms that were easy or difficult to inform my thinking about USABILITY.

For the “Making” part, I talked about doing participatory design in the field. Once I have learned something — ideas have been generated… I form a hypothesis like “Stella wants to see a visualized network of everyone on Twitter who is talking about InfoSec so that she can place herself in that community”. From that hypothesis, I ask a bunch of questions. Then I design an experiment. I MAKE something to test — mostly a lo-fidelity prototype that I can put in front of people and ask them to show me how they would use it. I can find out if it is USEFUL — what will make it USABLE, and I generate more ideas for features and functions. Sometimes I even get to do participatory design with people who might be users.

Write down the purpose for your research. Writing down the questions you need to answer to prove (or disprove) your hypothesis is important. We need to make use of every precious second we get to spend with people who do or might use our products. As a rule, don’t try to answer more than 4 or 5 questions in an hour session.

Write a test outline or script and follow it for each person you test. Do a pilot with a business stakeholder like the PO — this will get them comfortable with what is going to happen in the session — and they might have more questions to add to your ongoing research list.

Establish rituals around research with the product development team. (ie: every Friday is UX revolving door session day) Every Monday we talk about what we learned.

Use guerrilla techniques. Ask people 10 questions at a conference. Use WebEx to set up a share your desktop and show me how you work session.

Capture what you can with video and/or audio so you can go back and review it later. That way you can engage with the interviewee and not be bogged down with note taking.

Summarize what you have learned immediately and send it to the team. Don’t spend a ton of time analyzing. Form a new hypothesis and test it tomorrow.