Lean UX를 설명하는 첫번째 책.
Table of Contents
We are still building linear organizations in a world that demands constant change. We are sill building silos in a world that demands thorough collaboration. And we are still investing in analysis, arguing over specifications, and efficiently producing deliverables in a world that demands continuous experimentation in order to achieve continuous innovation.
What is Lean UX and How is it Different?
The Lean principles underlying Lean Startup apply to Lean UX in three ways. First, they help us remove waste from our UX design process. ... Second, they drive us to harmonize our "system" of designers, developers, product managers, quality assurance engineers, marketers, and others in a transparent, cross-functional collaboration that brings nondesigners into our design process. Last, and perhaps most important, is the mindset shift we gain from adopting a model based on experimentation. Instead of relying on a hero designer to divine the best solution from a single point of view, we use rapid experimentation and measurement to learn quickly how well (or not) our ideas meet our goals.
Part I. Introduction and Principles #
Chapter 1. Why Lean UX? #
Lean UX is deeply collaborative and cross-functional, because we no longer have the luxury of working in isolation from the rest of the product team. We can't continue to ask our teams to wait for us to figure it all out. We need daily, continuous engagement with our teams if we are going to be effective. This continuous engagement allows us to strip away heavy deliverables in favor of techniques that allow us to build shared understanding with our teammates.
Chapter 2. Principles #
Part II. Process #
Chapter 3. Vision, Framing, and Outcomes #
What is Hypothesis Statement:
Hypothesis statement is the starting point for a project. ... It states a clear vision for the work and shifts the conversation between team members and their managers from outputs to outcomes.
Elements of the hypothesis statement:
- Assumptions: A high-level declaration of what we believe to be true
- Hypothesis: More granular descriptions of our assumptions that target specific areas of our product or workflow for experimentation.
- Outcomes: The signal we seek from the market to help up validate or invalidate our hypotheses.
- Personas: Models of the people for whom we believe we are solving a problem. (See Proto-persona)
- Features: The product changes or improvements we believe will drive the outcomes we seek.
Problem statement template:
[Our service/product] was desinged to achieve [these goals]. We have observed that the product/service isn't meeting [these goals], which is causing [this adverse effect] to our business. How might we improve [service/product] so that our customers are more successful based on [these measurable criteria]?
Hypothesis statement template:
We believe [this statement is true]. We will know we're [right/wrong] when we see the following feedback from the market:
[qualitative and/or quantitative feedback and/or key performance indicator change].
I find it helpful to break the hypothesis down into smaller and more specific parts.
We believe that [doing this/building this feaure/creating this experience] for [these people/personas] will achieve [this outcome]. We will know this is true when we see [this market feedback].
Chapter 4. Collaborative Design #
In this chapter ... we look at:
- Why everybody gets to design
- How low-fidelity artifacts increase collaboration
- Building a shared understanding across your team
We'll alos dig into a series of techniques that enable this more productive way of working, including:
- Design studio - a collaborative sketching exercise for the entire team (See Design studio session
- Style guides and pattern libraries - living repositories of all the customer-facing elements of your product
- Collaboration techniuqes for geographically distributed teams
Chapter 5. MVPs and Experiments #
Non-prototype Minimum Viable Products:
For many teams, the default approach to creating an MVP is to create a prototype - to immediately begin designing and writing code. ...
Sometimes it makes sense to create an MVP that doesn't simulate your product and instead lets you test something related to your product. ...
The mantra to keep in mind when creating non-prototype MVPs is this: you can always go leaner. Th plan your MVP, ask yourself the following questions:
- 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 indicators for my main signal?
- What's the fastest way for me to find this information?
Types of non-prototype MVPs:
Google Ad Words
By measuring click-throughs, you can see how much interest there is in the words and messages you propose.
(Fake) landing page
- The button to nowhere
Chapter 6. Feedback and Research #
Too often, teams outsource research work to specialized research teams. And too often, research activities take place only on rare occasions - either at the beginning of a project or at the end. Lean UX solves the problems these tactics create by making research both continuous and collaborative.
Collaborative discovery is a way to get out into the field with your team. Here's how you do it:
- As a team, review your questions, assumptions, hypotheses, and MVPs. Decide as a team what you need to learn.
- Working as a team, decide whom you'll need to speak to in order to address learning goals.
- Create an interview guide that you can all use to guide your conversations.
- Break your team into interview pairs, mixing up the various roles and disciplines within each pair.
- Arm each pair with a version of the MVP.
- Send each team out to meet with customer/users.
- Have one team member conduct interviews while the other takes notes.
- Start with questions, conversations, and observations.
- Demonstrate the MVP later in the session and allow the customer to interact with it.
- Collect notes as the customer provides feedback.
- When the lead interviewer is done, switch roles to give he note-taker a chance to ask follow-up questions.
- At the end of the interview, ask the customer for referrals to other people who might also provide useful feedback.
Part III. Making It Work #
Chapter 7. Integrating Lean UX and Agile #
See Lean UX process
Chapter 8. Making Organizational Shifts #
Shifting from output to outcomes.
Moving from limited roles to collaborative capabilities.
Every team member possesses a core competency ... Howevery, he or she may also possess secondary competencies that make the team work more efficiently. ... Allow your colleagues to contribute in any disciplines in which they have expertise and interest.
Embracing new skills:
Many companies hire designers to create Wireframes, specs, and site maps. ... The success of a collaborative team demands more. ... Designers must open up the design process. The team - not the individual - must own the product design.
Creating Cross-functional teams:
...Keep your team cohesive by breaking down the discipline-based boundaries.
Creating small teams.
Creating open, collaborative workspaces.
Not reying on heroes.
Eliminating Big Design Up Front.
Placing speed first, aesthetics second:
In Lean UX, working quickly means generating many artifacts. Don't waste time debating which type of artifact to create, and don't waste time polishing them to perfection. Instead, use the one that will take the least amount of time to create and communicate to your team. Remember, these artifacts are a transient part of the project - like a conversation. Get it done. Get it out there. Discuss. Move on.
Aesthetics are an essential part of a finished product and experience. ... However, putting in this level of polish and effort into the early stage artifacts - wireframes, sitemaps, and workflow diagrams - is a waste of time.
Valuing problem solving.
Embracing UX debt.
Shifting agency culture - Agencies are in the deliverables business:
The basic agency Business model is simple, after all: clients pay for deliverables, not outcomes. But agency culture is a huge obstacle as well. The culture of hero design is strong in places that elevate individuals to positions such as Executive Creative Director. Cross-disciplinary collaboration can also be difficult in big agencies, where processes and "project phases" encourage deliverables and departmental silos. ...
To make Lean UX work in an agency, everyone involved in an engagement must focus on maximizing two factors: increasing collaboration between client and agency, and working to change the focus from outputs to outcomes.
Some agencies attempt to focus on outcomes by experimenting with a move away from fixed-scope and deliverable-based contracts (See Fixed-scope contract). Instead, their engagements are based on simple time-and materials agreements, or, more radically, on outcome-based contracts. In either case, the team is freed to spend their time iterating towards a specified goal, not just a deliverable.
Clients give up the illusion of control that a deliverables-based contract offers but gain a freedom to pursue meaningful and high-quality sulutions that are defined in terms of outcomes, not feature lists.
In agency relationships, software development teams (either at the agency, at the client, or a third-party team) are often treated as outsiders and often brought in at the end of a design phase. ... Development partners must participate through the life of the proejct - and not as passive observers. Instead, you should seek to have software development start as early as possible.
Working with third-party vendors:
Third-party software development vendors pose a big challenge to Lean UX methods. If a portion of your work is outsourced to a third-party vendor - regardless of the location of the vendor - the Lean UX process is more likely to break down. The contractual relationship with these vendors can make the flexibility that Lean UX requires difficult to achieve.
When working with third-party vendors, try to create proejcts based on time and materials. Doing so will make it possible for you to create a flexible relationship with your development partner, which you need in order to respond to the changes that are part of the Lean UX process.
Navigating documentation standards:
Many organizations have strict documentation standards that help them meet both internal as well as external and regulatory compliance. ...
The basic philosophies and concepts of Lean UX can be executed within these environments ... during the early parts of the project lifecycle. As hypotheses are proven and design directions solidify, transition back from Lean UX to the documentation standard your company requires. Use this documentation for the exact reason your company demands: to capture decision history and inform future teams working on this product. Don't let it prevent you from making the right product decisions.
Being realisitic about your environment:
Change is scary. ... Change can be especially disconcerting for managers who have been in their position for a while and are comfortable in their current role. ... Try out some ideas and prove their value via quantifiable successes.
Managing up and out:
Lean UX gives teams a lot of freedom to pursue effective solutions. It does this by stepping away from a product roadmap approach, instead empowering teams to discover the features they think will best serve the business. But abandoning the product roadmap has a cost - it remvoes a key tool that the business uses to coordinate the activity of teams. ...
You must constantly reach out to members of your organization who are not currently involved in your work to make sure they're aware of what's coming down the pike. ... By reaching out to them proactively, you allow them to do their jobs better. In return, they will be far less resistant to the changes your product designs are making.
Two valuable lessons to ensure smoother validation cycles:
- There are always other departments that are affected by your work.
- Ensure that customers are aware of any significant upcoming changes and allow them to opt out (at least temporarily).
Incoming Links #
Related Articles (Article 0) #
Suggested Pages #
- 0.025 Agile Experience Design
- 0.025 Iteration planning
- 0.025 User experience
- 0.025 Stand-up meeting
- 0.025 Brainstorming
- 0.025 UML Distilled
- 0.025 Waterfall process
- 0.025 Kanban
- 0.025 Retrospective
- 0.025 Extreme Programming Explained
- More suggestions...