Loading presentation...

Present Remotely

Send the link below via email or IM


Present to your audience

Start remote presentation

  • Invited audience members will follow you as you navigate and present
  • People invited to a presentation do not need a Prezi account
  • This link expires 10 minutes after you close the presentation
  • A maximum of 30 users can follow your presentation
  • Learn more about this feature in our knowledge base article

Do you really want to delete this prezi?

Neither you, nor the coeditors you shared it with will be able to recover it again.


Make your likes visible on Facebook?

Connect your Facebook account to Prezi and let your likes appear on your timeline.
You can change this under Settings & Account at any time.

No, thanks

Lean UX Basics

Presented at Lean Startup Circle meetup: http://www.meetup.com/Lean-Startup-Circle-Budapest/events/190523862/ 2014.06.27.

Péter Balázs Polgár

on 30 June 2014

Comments (0)

Please log in to add your comment.

Report abuse

Transcript of Lean UX Basics

Lean UX
Research should be continuous and collaborative.
Collaborative discovery
Entire team gets out of the building to meet the customers.
Team reviews questions, assumptions, hypotheses, MVPs, decides together what you need to learn, summarize in interview guide
Decide together to whom to speak
In pairs, one conducts the interview, other takes notes
Start with questions, conversations, present MVP latter
Making sense of the research
Team activity, evaluate together (based on the notes).
Read up individual notes, write on sticky notes, group, discuss.
Maximize learning:
Look for patterns
Park your outliers
Verify with other sources
Identify patterns over time (audience changes).
Test everything
- whatever is ready on test day:
Sketches (for concept value, but no workflow, no design and no usability feedback)
Static wireframes (for information hierarchy, layout, navigation taxonomy, copy choices)
Hi-fi mockups (tactical feedback, aesthetics, grouping, relationships, clarity of call-to-actions)
Clickable mockups (interactions)
Coded prototypes (design, behavior, workflow feedback)
"No Battle Plan Survives Contact With the Enemy"
Helmuth von Moltke the Elder
chief of staff of the Prussian Army for thirty years
Benefits for the team: focus, communication, camaraderie.
Team collectively understands what to do, so less need on reports and detailed documents.
Team mentality is important, elite experts don't support team collaboration. Members should share the ideas and the spotlight.
To find the best solutions, experimentation is needed on ideas. It must be safe to fail on some of these to be successful. Experiments lead to creativity which leads to innovative solutions.
What we believe.
Specific, testable assumption.
Validated hypotheses
: common starting point for the team
With whole group, from existing data (analytics, usability reports, previous work, competitors)
Problem statement
: Current goals, problem we want to address, explicit request for improvement
Prioritize based on risk and unknown.
Assumptions transformed into testable statements.
Maybe needed to break down into smaller parts (to properly test)
Has to include: persona/target, outcomes, feature that solves the problem.
High level outcomes should be broken down into smaller parts (to easier measure)
Models of the users we are interested in, based on user research - what is interesting for our goals.
Method for creating: sketchy proto-persona based on assumptions, latter adjusting based on the ongoing research - maybe modifying the target audience.
Sketch and name
Behavioral demographic info
Pain points and needs
Potential solutions
Tactics to reach an outcome. Create these by brainstorming about the user and the business needs.
We will
[create the feature]
in order to achieve
[this outcome].
MVPs help test our assumptions with minimum work.
Once we see which features are worth, we can invest resources there.
Non-prototype MVPs
What am I trying to learn?
What are the main signals I need from the market to validate my hypothesis?
Are there any other signals I can test for that will serve as an indicators for my main signal?
What's the fastest way for me to find this information?
Email (open, click-through, task completion for recipients)
Google Ad Words (monitor what people are searching)
Landing Page (from click-through traffic, a facade for the service with a specific call to action)
Button to nowhere (tours the new feature, clicks indicate user's desire)
Lean UX is a mindset
Lean UX is methods
Getting feedback
Cross functional teams
Made up by various disciplines involved in the creation of the product, with continuous, high collaboration.
Small, dedicated, colocated
Shared understanding
Permission to Fail
Problem-Focused Teams
Team is working on a business problem, and not on implementing a set of features. This shows trust, helps coming up with own solutions.
Anti-Pattern: Rockstars, Gurus and Ninjas
Small batch size
Create designs only to move the team forward, don't keep an inventory of untested designs.
Making over debate
More value in creating the idea than debating over it. Answers are not created on meetings, but by users. For the users to see it, they need to be concrete.
Getting Out of the Deliverables Business
Focus is not on documents, but the outcomes the team is achieving. Discussions with stakeholders is less about the artifacts created and more about the outcomes. Documents don't solve customer problems, good products do.
Externalizing Your Work
Get your work out of your head and computer into public view - whiteboards, printouts, sticky notes for exposing the progress to teammates, coworkers. Everyone sees where the team stands, creates an ambient flow of information and inspires new ideas.
Removing waste
If it doesn't help the outcome, it should be removed from the process.
Progress = Outcomes, Not Output
Features, services are outputs, business goals they help are outcomes, progress should be measured by outcomes.
GOOB: The new User-Centricity
"Getting out of the building" - meeting room debates about user needs can't be settled conclusively, answers are outside. Test your ideas sooner.
Learning over Growth
Learn first, scale second. If the idea is unproven it's risky to scale first. Ensuring the idea is right before mitigates risk.
Engage the customer in the whole process both with quantitative and qualitative methods. Research is frequent, regular and involves the whole team.
Continuous Discovery
User tests
quick and cheap
fun to create
can modify on the fly during a test
rapid iteration is hard
simulation is artificial
native, non-production code
easier to modify
can be created from existing (screenshots, paper)
texts get more attention
have to give proper context
realistic looking
visuals similar to end result
can be test remotely
data interaction may be limited (no content)
effort in similar range than real product UI
code reusable in production
realistic, native environment
data is hand coded or real
can be also a/b tested
too detailed, slow to develop
"release delay"
almost paper feel
Wizard of Oz interaction
Keynote (Keynotopia)
Wireframing tools
wireframe + linking tools
Is our solution usable?
Is there value in the solution and features for the users?
Is there a need for the solution we are designing?
Learn from MVPs
scheduled conversations
with the users (test day every week).
record and broadcast
, the whole team should watch.
Field interviews
Researcher coaches the team to plan and execute together.
Pen and Paper
Click through mockups
Hi-fi - Coded
Cross-functional teams:
PM, designer, UX, developers
(+support, marketing); daily meetings, weekly planning
Kanban to show progress for every task, focus on less waste
Continuous user research on target users
Different prototypes, testing iterations
Small batch sizes
Talk about outcomes, not features
Involve developers
Declaring all assumptions
Full transcript