ux london 2013 - notes and key themes

UX London 2013Simon Pan · April 2013

Conference Overview

• 3 days covering Product Design, Behaviour Design and Design Strategy

• Inspiring talks and intensive workshops

• Awesome atmosphere

Key Themes

We don’t know what will work

• Observe people & learn from emergent behaviour

• It won’t be perfect first go. Test and iterate.

• Learn from failure AND success

Technology is moving FAST

• Computing power doubles every 18 months

• Robots are replacing human labour

• Our lives are littered with crap that doesn’t work

• Change favours the creative

There is no perfect process

• ...only process for the circumstance

• Good work doesn’t come from the “5 D’s”

• It’s important to be honest with ourselves and our clients

• Change favours the creative

Design beyond the interface

• We need to work differently if we want to deliver meaningful experience that deal real value

• The challenge is designing organisations, not UI

Presentation Highlights

Tom Hulme IDEO

Design Disrupted

Key Outtakes

• How can we learn from Urban Design?

• No matter how we design cities, people take their own paths - “Desire Paths”

As Designers...

• We have the vision

• BUT The truth is in how

!

• Our responsibility is ALSO to react

How do we do it?

• Human needs rarely change

• We need to find ways to meet them more meaningfully and delightfully

1. Launch to learn

• Need vision. Need purpose.

• Pick something to launch, we’ll learn far more

• Don’t be precious

• Small 2 pizza teams - line of sight with customer

• Build and learn as you go

2. Don’t fight desire

• Look for desire paths and remove friction

• Accept that we will be wrong

• Whatever users are doing is the truth

• Plenty of good tools to find desire paths

3. Neither open nor closed

• Think of products as a jar

• API’s are your best friend

• Think about ways to open things up. Good for business, good for community.

4. You’re not alone

• Consider the bigger journey

• Work harder to design for how people leave

Jeff Gothelf Neo

Better product definition with Lean UX

Key Outtakes

• Startups fail because they don’t test their hypotheses

• Defining the right product reduces time spent building the wrong product

• You have to fail to learn

Product����������� ������������������  Manager

Rethinking Requirements

• Requirements are actually assumptions we are making about:

• the audience and their needs

• our product and design

We need to shift our thinking

• Requirements =

• We know =

• Let’s build it =

• Build this feature =

On Lean UX

Bring the true nature (experience) of a product to light as quickly as possible, in a collaborative, cross-functional way with less emphasis on deliverables and a greater focus on a shared vision and understanding of the experience being designed.

“

On Design Thinking

• Empathy

• Creativity

• Rationality

Design Thinking + Lean UX

• Prioritise

Product Definition

• Who is our customer?

• What pain-points do they experience?

• What is our differentiation?

• What’s our business model?

• What business problem are we trying to solve?

Requirements as Hypotheses

• We believe that [building this feature] for [these people] will achieve [this outcome] is our customer?

• We know we are successful when we see [this quantifiable signal from the market]

Measure progress by outcome

• Companies currently measure output e.g ‘Did you build this sign-up page?’

• Need to refocus teams on outcomes

• ...outcomes they can actually affect e.g not NPS

Measure progress by outcome

• McDonalds analogy:

• Fries = output

• Fat kid = outcome

• Obese population = impact

Make decisions with data

• Quantitative + Qualitative (objective observation)

• If it’s a bad idea, kill it before it kills you!

• If it’s a step in the right direction - change tactics

• If you’re getting there - double down and scale

Lean UX isn’t just for Designers

• Small, cross-functional “2 pizza teams”

• Bring perspective from all disciplines

• Everyone should understand the “why”

• Learn more, faster by sharing in discovery and creation

Ben Terrett Gov.UK

Building a consistent UX across gov digital services

GOV.UK Vision 2013

Single place for all government services and information online.“

Challenges

• 2000+ websites to consolidate

• Single government domain

• Public sector - large number of stakeholder

• Complex approval process

How they got there

• Creating an environment that keeps learnings within team

• Prioritising ‘good idea’ to ‘actually live’

• Advocating and changing the culture

typical����������� ������������������  approach����������� ������������������  to����������� ������������������  public����������� ������������������  sector

massive����������� ������������������  achievement!

Guiding Principles

• Gov should only do what gov does:

• Design in the environment that it’s going to be used

• Designing information not pushing around pixels - Technology changes, content is forever

Key Learnings

• Gov.uk isn’t a story about Interface Design, it’s a story about organisational design

• To enable design like this, we need to change how we work and how we think

• Need a working culture that values its people, embraces experimentation

What we can learn from the GOV.UK case study

Designing a better team

• Centralised, multi-disciplinary, close proximity

• Better spaces, intimate, focussed, wall space!

• Clearly defined roles within teams

• Specialisms are great, but using ‘UX Designer’ labels - everyone else is off the hook

Designing a better team

• The UX isn’t just the interface, it’s how fast the servers are, the structure of the URL, how the copy is written

• Products are a team sport

Designing better leadership

• Need vocal and consistent support from the highest parts of the organisation

• Continually evangelise for the team higher up and be the battering rams driving change

http://www.flickr.com/photos/benterrett/8576183560/

Designing better learning• Spend time creating artefacts.

• Maintain a shared vision about the way we should approach challenges and define solutions

• Be open to improving methodologies through learning and workspace hacks

• Don’t be dogmatic

Designing a better process

• Focus on delivering small chunks of work

• Visible deadlines and visible progress

• Test driven development (browser and accessibility baked into each sprint) + real people

• Continually deliver...avoid the big reveal

Thanks