This chapter is from the book
This chapter is from the book
This chapter is from the book
Understand the Project Approach
Knowing the overall approach, or methodology, of a project is an important part of understanding when and how you’ll be involved and how you should be involving others, such as your project team and business stakeholders.
Sometimes there seem to be as many project approaches as there are projects. How to choose the right approach for a project is a large topic in itself. The methodology you choose can depend on many things, including the structure and location of the project team, the technologies being used on the project, and the degree to which collaboration is a part of the company’s culture. For the purposes of this book, we’re assuming that you’ve joined a project where the approach has largely been determined by those responsible for the project’s success, such as the project sponsor and project manager. In this situation, your main goal will be to understand the approach and help make it effective for the business stakeholders and your users.
Here we’ll focus on two of the most common types of approach, as well as a third that shows a possible variation you might encounter on a project. The important thing to note is that most approaches involve the same steps:
- Plan the overall strategy, approach, and team structure
- Define the project requirements
- Design interaction and visual concepts and evolve them into detailed specifications
- Develop, test, and refine the solution
- Deploy the solution via messaging, training, and a planned launch
- Extend the project by making recommendations for improvements
The names for these steps may vary, as may the degree to which they overlap and the way information is documented. But the general activities in each step are common to most projects and to all three models presented here.
Waterfall Approach
A waterfall approach (Figure 4.3) involves treating the steps of a project as separate, distinct phases, where approval of one phase is needed before the next phase begins. For example, the Design phase does not begin in earnest until requirements have been approved by business stakeholders, who sign off on one or more requirements documents at the end of the Define phase.
)
Figure 4.3 Example of a waterfall approach, where each phase “falls” into the next
The problem with a pure waterfall approach is that it assumes that each phase can be completed with minimal changes to the phase before it. So if you come up with new requirements in the Design phase, which is common, you must suggest changes to documents that were approved at the end of the Define phase, which can throw off the plan and the schedule.
Agile Approaches
Because change is constant, project teams are continually looking for more flexible approaches than the waterfall model. Many methodologies follow a more fluid approach, with some steps happening alongside each other; for example, versions of the website could be released on a rapid, iterative schedule using an agile or rapid development approach (Figure 4.4). An agile approach generally has a greater focus on rapid collaboration and a reduced focus on detailed documentation and formal sign-off.
)
Figure 4.4 Example of an agile approach
A true agile approach (following the best practices developed by members of the Agile Alliance, for example) calls for small teams whose members are located next to each other physically, with little focus on defining formal roles between team members. Working this way allows a very high degree of collaboration, which reduces the need for heavy documentation between the stages of design, development, and testing. A team member can pose a question, come to the answer together with other team members during a quick whiteboarding session, and implement a solution without the delay of detailed documentation and approval. Stakeholder reviews occur with a fully functioning system when one of the many iterations is released, and the resulting input is taken into account as the next iteration is planned. (Iterations are draft versions of a particular site or application and may also be called sprints.)
Designers moving to an agile approach for the first time often face a conundrum. How do you go from a waterfall approach (which favors detailed documentation and sign off, taking weeks or months per phase), to an agile approach (which favors conversations and quick decision making over the course of days or weeks) and still make time for design thinking and user research? To see how some designers have made the transition, let’s dive deeper into a particular kind of approach called Lean UX.
Lean UX
Lean UX is an agile project approach that’s well-suited to products being developed in the face of great uncertainty (as most products for startups are). It reduces waste in the project’s process by removing effort spent on features that don’t really matter at the time of each iteration. For example, spending time designing an entire set of categories and subcategories of products may be wasteful if the team has not yet proven that they’re offering products that their target users are willing to purchase.
Some of the principles of Lean UX include:
- A focus on validated learning. Iterations of the product are not seen as simply working versions of the product, but as the presentation of a hypothesis that can be tested with users. The goal is to learn as quickly as possible, by validating design decisions with customers and incorporating the subsequent changes that will help the team learn the next important lesson.
- A continuous loop of Build—Measure—Learn. Lean processes prioritize the building of a testable iteration of the product as quickly as possible, in order to test assumptions that the team is making about how users will react to the product. Tests fail or succeed based on qualitative user feedback during research, and on quantitative measures that are put in place to track success. These measures should pull from actual user behavior—for example, the number of registrations for a site, the number of products purchased, and so on. Care should be taken that the measures put in place really test the assumptions of that iteration. For example, if people are registering for your site, but not taking any important actions in it afterwards, you’ve just learned that your post-registration experience needs to be more compelling! Incorporate that learning into your decisions on what goes into the next build, and complete the loop (Figure 4.5).
){kind=link}
Figure 4.5 Lean approaches focus on a loop of Build—Measure—Learn. The process is meant to increase the speed by which teams cycle through the loop, maximizing learning and allowing for quicker adjustments in strategy based on customer response.
- The importance of developing the Minimum Viable Product (MVP) at each iteration. In a lean process, the focus is on testing a hypothesis about user behavior, rather than building a fully functioning product at each iteration. Teams don’t need to create a fully functioning digital version of their product to test a hypothesis (although a more robust digital version will eventually exist after several cycles, if things are going well on the validation front). Especially in beginning stages teams can focus on developing a Minimum Viable Product, which Eric Ries defines as “that version of product that enables a full turn of the Build—Measure—Learn loop with a minimum amount of effort and the least amount of development time.” For example, elements of the experience that should eventually become automated—like confirmation emails when a purchase has been made—may be completed more manually by a team member while the test is being run in an earlier iteration.
Ask the Experts: Jeff Gothelf
)
Jeff Gothelf is the founder of Proof, a product innovation and design studio, and is the author of Lean UX: Getting Out of the Deliverables Business (O’Reilly, 2012.)
You’ve said that Lean UX is an approach that gets designers out of the deliverables business. But many UX designers use deliverables—documentation like detailed wireframes—in order to communicate design recommendations to their teams. Does Lean UX skip this step?
Deliverables aren’t skipped in Lean UX. They’re still used, to the extent necessary, to communicate to target audiences like stakeholders, developers, and customers. But they’re not the focus of the project, and they don’t create the bottleneck they would in waterfall where the team sits back and waits for the design to be “done” and then signed off before anyone else begins working. Also, there’s still a large amount of work that you’re doing as a designer outside of the actual documentation, because the goal is to validate your design hypotheses as soon as possible—so the more tests you’re running with customers, the more right you’ll be in the product you’re building. The trick to getting to a level of efficiency with it is to build a shared understanding across your entire cross-functional team. The more you’re out there with your team having conversations with them, discussing what you’re seeing and why you think that is, the more they get a clear sense of why you’re making the design decisions you’re making and what direction the design is heading in. When they have a clear sense of that, they need less documentation in order to start building those experiences because they have the foundation and shared understanding from which to work.
How does a Lean UX approach affect the role of a UX designer on the project?
It assumes a leadership quality to the UX role on the team. The Lean UX process forces you to constantly communicate out to the team and solicit feedback from them. But it’s not design by committee, either. Yes, you’re out there soliciting feedback from your team early and often, but it isn’t your job to take all their feedback and make sure it all makes it into the next iteration of the design. It’s your job to prioritize the feedback based on what’s needed to get to the next level of learning with your customers. Then you incorporate that and communicate the result out to the team so they’re aware of what design decisions are being made, and why.
Is there anything the team should have from the beginning to ensure a Lean UX approach is successful?
There needs to be a freedom to fail in the organization. If people feel they have to get it right the first time, right out of the gate, than the whole process fails. This is a hypothesis validation process, and by the very nature of it you’re going to come up with some wrong answers. The idea is to figure out what those wrong answers are as quickly as possible and minimize the wasted effort going down those paths. If you don’t have the freedom to be wrong in your organization, then you will not be able to execute this process with any kind of success.
- A move away from formal deliverables and detailed documentation. This is consistent with the overall agile approach. Deliverables like detailed wireframes and use cases, which may become replacements for direct communication and fast implementation of ideas, are removed from the process in favor of faster methods like sketching. Conceptual wireframes are often still used, but are meant to illustrate quickly as an aid to communication, and do not “live on” as records of design decisions.
When an agile approach is working as it’s designed to, it’s a beautiful thing. At most companies and within most consulting engagements, however, teams rarely follow a pure agile approach. In part, this is because companies often have distributed teams and remote workers, which makes it difficult to maintain the high degree of collaboration needed to take best advantage of the pure agile approach. However, a greater prevalence of virtual collaboration tools and digital sketching tools makes this distributed agile approach increasingly possible, as long as teams commit to clear communication, high availability, and effective decision-making.
Surfing
LUXr is a company founded on Lean UX practices. You can see an introduction to Lean UX and more detail on its principles on their site at http://luxr.co/lean-ux/9-principles-for-lean-ux/.
All UX designers should be focused on reducing waste in the process, and prioritizing communication over documentation regardless of the specific approach of the team, as Whitney Hess points out here: http://whitneyhess.com/blog/2011/02/27/why-i-detest-the-term-lean-ux/
Modified Approaches
Many projects try to follow an approach that marries elements of waterfall and agile approaches, with enough structure and documentation to reduce the risks posed by distributed teams and turnover of team members, but enough collaboration and iteration to respond to changes in a relatively nimble way. For example, a project may follow a waterfall model but include an overlap in phases so that there are key collaboration points from team to team. This allows potential changes to surface earlier in each phase. This may also include an early release (such as a beta release to a particular user group) with a shorter iteration cycle. Feedback from that release can then be incorporated before the full deployment of the new site. (Figure 4.6)
)
Figure 4.6 Modified waterfall with beta release
Notice the smaller iterations within the Design phase in Figure 4.5. That’s one of the greatest values you bring to your team as a UX designer. Tools such as wireframes (Chapter 12) and prototypes (Chapter 13) can allow you to gather feedback on quick iterations of ideas, before a lot of development time has been put in.
This book loosely follows a modified waterfall approach like the one shown in Figure 4.6. However, many of the topics covered here will apply to your project regardless of the specifics of your approach, because the basic activities behind them—defining and designing, for example—are still necessary.
Deep Diving
If your project is using an agile approach, you’ll have unique needs during requirements gathering, such as the writing of “user stories” as a way to capture requirements. We recommend User Stories Applied: For Agile Software Development by Mike Cohn (Addison-Wesley Professional, 2004).
How Does the Approach Affect Me?
Knowing your approach helps you understand a number of things:
- What questions you should be asking, and when. For example, if you’re working with a pure waterfall approach, you’ll need to put in extra effort to make sure the requirements captured in the Define phase contain all the information you need for the Design phase. (We’ll be discussing requirements in the next chapter.)
- Expectations on how project team members will collaborate and how close that collaboration will be. For example, an agile approach requires very close collaboration. A waterfall approach may involve individual work most of the time, with touchpoints once or several times per week.
- The level of detail needed in your documentation and the level of formality. Documents submitted at sign-off points need to be formal, almost like legal contracts. Typically, you’ll need more formal documents in a waterfall approach, where sign-off is required before you move on to the next phase. However, you may also have some formal sign-off documents when using an agile approach—for example, to capture information at major decision points, such as when a particular iteration is prepared for full release and deployment.
- Important milestones that involve approval from stakeholders and deployment to different groups. The approach will determine what different audiences need to provide at various points in the project, including approvals from stakeholders at sign-off points and feedback from potential users during a beta release.
Now that you’ve solidified your project objectives and gained an understanding of the project approach, in the next chapter we’ll start with the primary work in the Define phase: gathering requirements.