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 some of the most common methodologies, as well as some design approaches you might encounter on a project. The important thing to note is that most methodologies involve the same steps:
Plan the overall strategy, approach, and team structure.- Discover the relevant user and business needs that the product should help address.
- Define the product’s purpose and functionality (or that of a specific release of the product) by ideating on features and prioritizing the results.
- Design visual concepts, user interface elements, and interactions, evolving them as needed prior to development.
- Develop, test, and refine the solution.
- Deploy the solution via messaging, training, and a planned launch.
- Iterate by making recommendations for improvements.
The names for these steps may vary, as may the degree to which they overlap, the number of times you may repeat some steps before moving to the next, and the way information is documented. But the general activities in each step are common to most projects, and across different methodologies.
Waterfall Methodology
A waterfall methodology (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. The linear process then proceeds through implementation, testing, and maintenance.
)
Figure 4.3 Example of a waterfall approach, where each phase “falls” into the next upon completion
The problem with a pure waterfall methodology 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 Methodologies
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 An agile approach focuses on short cycles and high levels of communication between disciplines on the team.
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, or remotely in a highly synchronous work setting, 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.)
Many different agile approaches have been created, each with recommended practices. Here are three common variations that are good to know:
- Scrum includes timeboxed sprints of work, usually of two to four weeks, with small teams and daily check-ins called scrums. There are clearly defined roles within the team, such as a scrum master who (among other things) is responsible for helping the team communicate and overcome blockers, or obstacles that are preventing work to be done on an area of focus. According to the “State of Agile” report based on a survey of over 3000 companies, scrum is the most commonly used agile methodology. (For the full report, visit stateofagile.com.)
- Kanban is a Japanese word meaning visual signal, so it may come as no surprise that the framework is best known for its visual representation of workload and progress. A kanban board is the most widely referenced example of the framework and has cards representing user stories (which we’ll cover more in Chapter 10). You can find a kanban board template in most development-oriented platforms, like Trello and Atlassian’s Jira software (Figure 4.5). Kanban is less timeboxed and less role-oriented than scrum by nature, but many companies combine aspects of the two frameworks and refer to it as “scrumban.”
Figure 4.5 A kanban board (shown here in Atlassian Jira) is a visual representation of planned upcoming work. That work is broken down into small units that team members can move between levels of status (the columns), like To Do, In Progress, and Done. The board gives the team visibility into ongoing progress.
- SAFe (Scaled Agile Framework) is an agile approach that has been optimized for large enterprises. It has many of the features of scrum and kanban but is designed for companies with more than one team. This means there are additional practices for alignment and collaboration across these multiple teams and workstreams to help them divide and conquer in their work, but also come together when needed for shared milestones (like a major marketing event that could impact multiple digital products) and other reasons. You can find out more about SAFe at www.scaledagileframework.com.
)
When joining a new team, be sure to ask which product development approach the company tends to follow. It’s not uncommon for companies to borrow practices from more than one methodology—for example, a team could be holding daily scrums and use a kanban board to track work—so don’t be surprised if you end up blending practices from different agile methodologies, or blending waterfall approaches with agile ones!
Other Approaches a Designer Should Know
The approaches we’ve covered so far tend to cover the full product development lifecycle. There are also several common frameworks that specifically illustrate the Discovery, Definition, and Design phases that a team might go through (note that here as well, a “phase” could take days, weeks, or months depending on the cadence expected of your team). Here are some approaches that are often referenced:
- The Double Diamond framework, created by the British Council in 2006, models an approach to the discovery work on a project (as shown in Figure 4.6). The Double Diamond itself is often applied to problems at a variety of levels including large strategic problems; this is a common aspect of an approach called design thinking. (See the sidebar “Design Thinking” for more on this.) Teams diverge as they explore the challenge, converge on a definition of the problem, diverge again as they explore ways to address that problem, and converge again on the solution to launch.
Figure 4.6 The Double Diamond shows two rounds of divergent and convergent thinking—one around the problem space (choosing the right product to create) and the second around the solution space (designing that product well).
- Lean UX complements a lean product management approach, which is popular for products being developed in the face of great uncertainty (as most products for startups are). Lean practices focus on reducing waste in the project’s process by (for example) keeping documentation to a minimum and keeping a tight constraint on the number of features included in each iteration. The team creates a hypothesis and builds a minimum viable product (MVP) meant to help test the hypothesis (Chapter 5 contains more about forming a hypothesis). The idea behind it is to build and launch an MVP quickly and efficiently, measure the results, learn from those results, and build again in an interative loop (as shown in Figure 4.7). For designers, the hallmarks of a lean UX approach are a higher use of sketches and conversations, and a move away from detailed and formalized deliverables like high-fidelity wireframes.
Figure 4.7 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.
- Dual-track product development is an agile variation that runs two different tracks of work concurrently (Figure 4.8). A lean Discovery track is meant to help the team explore user needs and experiment in a search for valuable future features, which get added to a backlog, while an agile Delivery track focuses on the delivery of product releases based on the features chosen from that backlog by the product team. Separating the tracks gives the team the room to try an experiment (and have it possibly fail) without directly affecting the cadence of the Delivery team.
Figure 4.8 Dual-track product development runs discovery efforts and delivery efforts at the same time, so team members have the space to test out ideas (and possibly have those ideas fail to meet expectations) rather than being required to deliver ideas that have not been validated.
- Design sprints were popularized by Jake Knapp during his work with Google Ventures, and are described in his book Sprint: How to Solve Big Problems and Test New Ideas in Just Five Days (Simon & Schuster, 2016). They are a method of running some of the phases of the second diamond in the Double Diamond approach in a short, focused scope of work over the course of five days. A small multidisciplinary team immerses themselves in the week-long sprint, exploring and sketching ideas, choosing ones to prototype, and then testing that prototype with customers (see Figure 4.9). The sprint might be part of a regular agile cadence or done as a one-off activity when there’s a desire to do a deep dive into a particular problem the team would like to solve.
Figure 4.9 A design sprint focuses on a particular challenge and uses a highly collaborative, time-constrained set of activities to move the team from concept creation to prototyping and then to testing.
)
)
)
)
Though the pace, scale, and process of the approaches we’ve covered may differ, many of the topics covered in this book will apply to your project regardless of which approach you follow, because the basic activities behind them—defining and designing, for example—are still necessary.
Ask the Experts: Jeff Gothelf
)
Jeff Gothelf is an expert on product management, OKRs, and agility and is the co-author of Lean UX: Designing Great Products with Agile Teams, Third Edition (O’Reilly, 2021). We asked him to clarify some key aspects of Lean UX.
You’ve said that Lean UX is an approach that gets teams out of the deliverables business. Does this mean skipping deliverables (like detailed designs with annotations) entirely?
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 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. The more experiments you can run with customers, the more right you’ll be in the product you’re building. The goal is to do the learning work collaboratively in an effort to build a shared understanding across the entire product development team. . The more involved the rest of the team is, discussing what you’re trying to learn, why it’s important, and what results the experiments yield, the more everyone gets 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 shared understanding, they need less documentation in order to start building.
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 your experience, your expertise, and the evidence you’re collecting from the market to get the next iteration in customers’ hands.
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, then 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 goal is to figure out what those wrong answers are as quickly as possible and minimize the wasted effort spent going down those paths. If you don’t have the freedom to be wrong, then Lean UX will struggle in your organization.
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, it’s time to meet up with your stakeholders to really define the product space. On to Discovery!