Archive for February, 2012

@agileuxnyc talk by @thinknow Lane Halley http://www.lanehalley.com

February 25, 2012

Lane Halley Quick, Visual, Collaborative, & Continuous

Liked the mindset from

Lean User Experience Residency

Back in the day we had the 4Ds: plan-build-test-ship — but we never had time to test. A lot came from HCI ( human computer interaction) … Struggle was how to get people to take time to test. Big struggle.

Products in perpetual Beta. For a while she didn’t like it. Then realized it was more fluid than in days of 4Ds. But even today we still base on model of practioners, deliverables, sips etc.

See her great slide on expanding role of designers.

UX now has a seat at table, but creating pain for team unless more quick, visual, collaborative and continuous.

Light weight research processes. Tomer and Andres talked about light methods.

Interview guides

Originally from Cooper (pattern! Just found out about thus company from Luke Hohmann).

Make Provisional persona that evolve over time

(Jeff Patton calls Practical Persona)

The persona themselves evolve over time

Hah! Sync. She mentions @jeffpatton. πŸ˜‰

And up go pragmatic persona slide. πŸ˜‰

These are made after some interviews.

Tips for researchers:
– pair interviews Withba back-up

Hah Jeff’s picture. πŸ˜‰

– use multiple note takers taking notes on cards with one thought per card or sticky note

– visual radiator (cred from me to Alistair – did he not come up w this term?)

– sketch board

Continuous customer engagement – this is what it really means: it should be like clockwork, not a special occasion

– five users every Friday
– talk to us button

Where previously would go get research, and understand needs, then do a report, then design… Instead do a mashup, find a small piece of story and ask user to show how they would do with product.

If a team doesn’t know what goes on the profile page, what goes on the page? Everything.

Innovation Games mention @lukehohman ;). “very useful”

Collaborative design session.

Shows a really lean prototype with just stickies.

Slides on sldeshare.

When you can predict the response, change test subjects.

[my main issue: how does this not turn into Big Design Upfront]

@glusman talk @agileuxnyc @meetup

February 25, 2012

Andres Glusman organizes Lean Startup Meetup; from Meetup, Vp strategy and community

Test a lot at meet up, down and dirty

Watch out for Malkovich Bias: that all people use technology way you do.

Way to cure? Show makers people using their products. Shifts from how I would use it to how s/he will use it.

Meet up uses gotomeeting – trying to eliminate friction between people who work on stuff and people using (testing) product

Quick rig for an iPhone test

Waste in experimentation

Tested 5 concepts for messages and approach to get people to create meet ups.

He hated the “Congratulations” and ” Don’t worry” tied for first. Adding graphics had very very little effect on outcome.

(cool “meet up” Warhol Campbell soup can teeshirt)

Structured an experiment on organizers with advisors from meetup. Took long time.

1. Give team direct access to customers. Remove friction.
2. Make it easy to test. Don’t worry about your test being perfect.
3. If test screws up, one right behind it.
4. Etc. Will be in posted deck,,,

It is such a dopamine lift to see test results, you will want to do more and more.

Steven Gary Blank : four Steps to the Epiphany: successful strategies for products that win

Handed out but no one read. Do not hand out a process. Do not follow the map in his deck. Just start doing it!!

What would you do if you knew you were going to fail? If you are going to run into a buzz saw? Hit it fast. Reason people don’t test is they are scared of failure. If you begin with assumption you are going to fail, you hit victory faster.

Q: Can you spend too much time testing not enough building? A: yes. Iterating on this process itself.

Comment : They have tested 600 or so participants. Have used meetup itself for Organizing project! Using tools for uses other than intended for.

@tsharon #agileuxnyc talk on user research – raw notes reflections later @google http://itsourresear.ch

February 25, 2012

Google’s Tomer Sharon

Einstein looked at a physics form and said “at was ok for then, but today answers are different.”

How do you get out of the building in an Agile environment.

Now, Usability testing needs to be about right now.

Keep it small. Should be small thing, not a big thing. How? Like clockwork, every week.

Recruit in advance.

Plan really fast. For instance he is deciding on Monday what testing Tuesday. See Smashing Maf article.

If usability test falls in woods and no one hears, it did not happen. Team needs to decide what, who, etc. Testing AND what you do with results.

NO reports. Using Google spreadsheet.

Takes 45 minutes between each session. What they are doing is focusing on what happened, NOT possible solutions. Do this live, so.

Meander took 3 minutes for Eric Ries’ name to pop up in conference. Sr eve Brandt calls getting out of building.

In Hong Kong, smart thing is they have a signon sidewalk reminding walkers to look right, because drive English style on left.

Three things to do to get out of building:

Not going to, but at least bring users along.

Coders can write code for years and never see user use coded product. So Google schedules call with user of product and Dev or prod owner to chat. Not and test, necessarily. Ask user to talk about themselves, ask basic questions, and he steps back and let’s engineers, etc., talk, even ask leading questions. If patterns repeat, may do a product change. But more to humaniz e user for engineers.

Do an outside event. Go and visit a client. No agenda, no goals. Just go, maybe to their home, with goal to let engineers to interact with actual people who use their product. Extremely useful.

Collaging is third technique. Thoughts or feelings around a topic. Why? Sometimes people don’t know what they need. This is based on science. What people think they want or need is pretty much not what they need. He does not ask future state questions. Asks about most recent past, and teases out actual recent past problems.

Ask people to create a collage for a product. From magazines. Like a talking dumpster.

Tips for getting buy-in for user research. You become One Team who worksnon creating something.

Achieve Failure and Success Theater. In his mind, work on research in a way people care about it, by involving them. Collect research questions. Finding out stuff interesting but not helpful.

To get buy-in listen to what people say, identify assumptions and hypothesis and prioritize with everybody on team.

Dealing with introverts. Shows making a morning route talking with everyone on your team. About relationship of being in same company and caring about same things.

Book title: It’s Our Research (itsourresear.ch) out in two weeks. Videos on site.

Elsevierdirect.com

@jseiden #leanux #leanstartup @proof_nyc @agileuxnyc raw notes

February 25, 2012

Josh talking about requirements.

(this conference is incredible)

Internet Mouse

– dealing with a visionary unicorn who had them create an Internet mouse – the product guy framed as a requirement

Hypotheses are a more effective way to manage your work than requirements.

Eric Ries quote on products created in extreme uncertainty.

(Eric mentioned in every talk so far. He should be here.)

Business does thinking. Comes in and places order with product team. Problem is team has no visibility into business problem.

(This is #1 complaint I hear from the most senior creatives in advertising!!! We have briefs which hide the problem behind an order for a TV Ad).

How do you contain a creative?

If you are certain, need requirements. If output / outcome uncertain, you need hypotheses.

Validated learning is primary measure of progress. Not just working software (from Scrum).

Janice Fraser diagram of why every thing you out in market is a hypothesis.

(This is going to be big!………….No one clicked)

Less risk when you release more often.

An hypothesis is a proposed explanation of the way things work.

In order to be a hypothesis must be testable.

In case of Internet mouse: ” we believe people will pay for a Device to easily use Internet”

Slides will be posted, but has a list of process for hypothesis. (when I type less notes is because more words available in deck. Some folks all image.)

Find the riskiest hypothesis:

* To deal with people with requirements laid out in a story map mentioned @Jeffpatton ( go Jeff!). πŸ˜‰

*Then identified risk spots on story map

All risks fell in one bucket: do customers value our offering enough to pay for it?

So from their developed hypothesis. One hypothesis about why people would pay (data!! In this case)

There are free widgets of similar function.

Tested against a persona (“Debbie”)

One-click install vs copy code. So in this case is a way to get people to install. Question should not be can people install it is there is enough value to install– so about the value.

Hypotheses are a way to reframe requirements. See his deck – I will post link when I get.

Question: story mapping – how to do non- collated teams – cardmapping.com.

“Jeff’s work is awesome, I encourage you to reach out to him via email. He’s going to love me for that.”

I am so lucky we were able to have Jeff come twice to my company.

“People want to work on stuff that is meaningful. When you see AgileUX starting to take hold, you see this efficient relationship. Teams feel surprised about the nonsensical requirements thrown over the fence at them.”