Send the link below via email or IMCopy
Present to your audienceStart 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.
Lean UX Basics
Péter Balázs Polgáron 30 June 2014
Transcript of Lean UX Basics
Research should be continuous and collaborative.
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.
Look for patterns
Park your outliers
Verify with other sources
Identify patterns over time (audience changes).
- 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.
: common starting point for the team
With whole group, from existing data (analytics, usability reports, previous work, competitors)
: 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
Tactics to reach an outcome. Create these by brainstorming about the user and the business needs.
[create the feature]
in order to achieve
MVPs help test our assumptions with minimum work.
Once we see which features are worth, we can invest resources there.
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
Cross functional teams
Made up by various disciplines involved in the creation of the product, with continuous, high collaboration.
Small, dedicated, colocated
Permission to Fail
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.
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.
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
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
almost paper feel
Wizard of Oz interaction
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
with the users (test day every week).
record and broadcast
, the whole team should watch.
Researcher coaches the team to plan and execute together.
Pen and Paper
Click through mockups
Hi-fi - Coded
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
Declaring all assumptions