Archive for the ‘Methodology’ Category

@zakiwarfel talks about Design Studio @agileuxnyc raw notes

February 25, 2012

@jeffpatton mentioned again

Tips for Design Studio

-use butcher paper and Painter’s tape; use sharpies
-graph paper
-team members with teams, get scenarios and one of the personas
— do not use all designers, etc. Use people from each expertise, business, UX, tech particularly
– most important tool is stop watch — likes Top Chef’s Quick Fire challenge

Has a grid system to use with block at bottom – do 6 to 8
To warm up, have them sketch stuff quickly using pencil, like circle, square and show to workshop–also levels everyone

Everyone is equally uncomfortable regardless of place in hierarchy

Goal is just enough idea to pitch to team members, and don’t have time to details

Only get three minutes to pitch.

Elect a team member to pitch to another team.

Hyper Island did this in our Master Class

Feedback can tend to I like / I don’t like

A critique is did they accomplish goal?

2 minutes to provide 2 to 3 ways design accomplished goal and 1 to 2 ways. Whether you love or hated it. Doesn’t matter. Use red to mark oops and green to what works.

Stealing is highly encouraged.

If you rip it off, have to make it better.

Generate six weeks of work in six hours. So costs? Costs less!

@andersramsay #agileuxnyc raw notes on collaboration talk #agile

February 25, 2012

UX Rugby

Says he is an Agile UX Coach. Makes me think of @Tobiasmayer vpcurrent Twitter thread that is “against” coaching

“Feeding the Beast”. Devs delivering features faster than can design

“Half-baked UX” – product owners pressured into get anything that functions out door.

“Sprint Tunnel Vision”. – and delivering an incoherent product

Why? A lot of UX designers playing Waterfall game on an Agile playing field. designing a Sprint ahead – is waterfall.

Lacking tools to understand how Agile game is played.

@totheralistair mentioned Collaborative Game book….

Mentioned Nonaka and Takeuchi’s New, New Product Dev paper

Compares Waterfall to Relay Race. Game is not designed for support

Rugby is intensive, continuous, with collaboration at the core

– reach goal line again and again to win game

Moved to concrete examples

Showed a meeting, like those we typically attend with a one-way, broad cast, meeting presenter. (but that is us now! Unfair, I know).

Then showed a workshop.

In a workshop you can rapidly iterate a shared understanding

Ideation Clearinghouse (like Design Studio).

Talked about a case of a CMO who just sat in on a waterfall design review in which he shut down product after saying designers did not understand his requirements

Do warm-ups. Card storming.

Sketching in a time box – with no rules – not even that they must draw. Can write.

Critique. Pay attention closely to what you are seeing if facilitating. Look for exceptions. Can uncover vision differences quickly.

Learn, apply and recombine workshop patterns.

For stuff that takes sitting down, do pairing. Showed cool yin-yang pairing desk.

Showed snapshare method. Paper prototype/wireframe to build / HTML CSS

Mindset – copied HSBC ads on mindset showing rugby vs relay race

Learning to play passing game in a collaborative manner.

Q: how do we estimate in planning meeting
A: no magical answer – make sure element of sketching in place before estimating. Have a few sketches

Have business sponsor do the elevator pitch of what the problem is we are trying to solve

Five minutes best time box

Only strong survive. Only stuff that achieves goals – devs excited, bus people figure out how to talk to engineers

Prepping room. Put up Butcher paper sheets and each team gets packet with persona.

@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.”