You have a design problem

The following is an interpretive transcription of Ryan Singer’s UX / UI PeepCode sessions in the style of Paul Arden’s It’s Not How Good You Are, Its How Good You Want to Be.

You have a design problem.

Ask:
How did they get there?

What's going to happen when they're done?

Before, now, after.

Constrain the domain so the problem is simpler.
Think of the real-world analogy.

Draw information flows:
relations based on navigation trees.

Think about state.
Does it matter?

Is this a micro-domain? It can be transient.
Is this is social thing? The scale is bigger.

Email is UI too.

Split the UX into beginning, middle, and end contexts.
Afterwards, design for the screen with these in mind.

What screen matters most?

Find the simplest screen that:
forces you to be compelling
provides value
and contains no unnecessary detail.

This teaches you about the product.

Doing the most complicated thing first may be tempting,
but this may never be used.

Think of UX like a failing test.
There's always conflict.
Identify the thing that I don't know, and build it out. 
Remove uncertainty.

Consider the naive approach first.

Find the natural way of doing things.
If I did this in the physical world, 
what would its most natural-looking interface be?

(Scribbles on paper?)

Try to communicate using their vocabulary.

What's the dumbest idea that works?
If this were paper, how would I do it? 

Christopher Alexander said
conflict is the starting point.

What conflicts exist?
*Weirdness* is conflict.
Increase confidence by resolving conflicts through design.

Sometimes, it needs to be seen on screen to make a decision.

Confidence is a spectrum.

It's important to find group confidence in a design on a team.
Do this by working side by side on something.

Make the intended action clear.
One way to do this is guarantee there's only one thing to do.

Flows help.
Before, now, after.

Every step needs a concept and implementation.
They must be evident to the user.

Mock (in Photoshop) to explore alternatives.

Criteria for it working:
*reptile stuff*.

When I look at it...
how does it affect me?

Sketching UX doesn't mean doing everything. 
*Use as medicine to ease the pain of worrying.*

Prove clear thinking by sketching. Remove worry.
Just enough to know what you're doing.

Design on the wall is exactly this.
Temporary.
The point is: the designer, programmer work *together*
through the design.

Then they go work.

There's never a moment where everything is built.
Design only when I need to design.
See what's working from there.

Step by step.

To prototype your UI:

*Focus on one UI element at a time.*
Use whatever tool is most convenient. 

PS, Web Inspector.
Rails can be fast if you know it already.

Take screenshots.
Mash it up.
Throw it away.

Write it however you can to make it do what you want.
Don't plan your implementation.

You will externalize your CSS later anyway.
Write it inline. 

Write it the long, easy way.
Start with a mess.
Refactor when your conflicts are resolved.

Photoshop can remove doubt.
Use it to see something.
Mock it quick to see how it will look.
Throw it away.