Agile + Human-Centered Design: Better by Design

In the two decades since its introduction, the Agile methodology and its core idea of minimum viable product have risen to prominence in software development. However, these processes are optimized for predictability and speed, at the expense of delivering the right features, an optimal user experience, or a future-proof design. Meanwhile, the field of Human-Centered Design (HCD) provides a cost- and time-effective path to delivering the right product and user experience the first time, by investing up front in research to define problem statements before attempting to design solutions. These are compatible approaches that can yield products with better traction, higher value, and greater long-term results than Agile alone.

The Agile Revolution

Twenty years ago, the idea of moving software development away from the “waterfall” approach favored for hardware development was truly revolutionary. As engineers sought to develop software that could run on other companies’ hardware, they initially assumed that they could use the same processes for design and manufacture. They quickly realized waterfall processes were not adequate for imagining and building complex software applications. Many of these projects were abandoned before the software was delivered. Worse yet, they might be introduced after long delays, only to discover that the requirements were misunderstood or that the needs of their users had already changed. The methodology was limiting the rate of successful innovation, and a new approach was needed.

This new idea was first referred to as “iterative development.” Instead of designing, building, and testing software in one long cycle, this approach called for development in smaller pieces over multiple releases. This allowed for faster user feedback and team learning, which could be used to adapt the requirements of the next release. While working in fixed intervals (or iterations) was a major shift for engineers, clients and stakeholders liked the apparent improvements in speed and predictability of releases. As iterative development gained traction, the question became how to decide which features to build, and in what order. Minimum viable product (MVP) was the notion that a team would maintain a backlog of features and intentionally delay decisions about what to build next, until it was time to build it. In principle, this gave developers time to learn and adapt based on actual user feedback. Agile was born.

Enter the Designers

Over the last 20 years of Agile transformation in the marketplace, a lot has changed. Once a luxury, UX/UI design is now fundamental in our day-to-day experience as consumers. This concentration on improving consumer experience has led to great business outcomes for some companies. It has also led to higher consumer expectations for every digital product or service.

How did these companies make this happen? In many cases, there was a necessary shift from an engineering-centric culture that was dominated by the need to start building fast and limited by what could be accomplished in an Agile sprint. Instead, they tried a human-centered approach that put product and design first, researching user needs and prototyping and testing user experiences that met those needs before committing to full-scale productization. UX researchers and UI designers were not forced into what could be imagined in a few days and quickly rendered into user stories so that developers could immediately begin to build. In some cases, this meant starting over and redesigning products that had already been shown to have value in the market. More often, this meant creating new products and services that were so compelling they were a runaway success. Think Airbnb, early Instagram, and Uber—all were design-led and based on unmet user needs.

Human-Centered Design: Slowing Down to Speed Up

Funding a new product, or a major new feature, involves business decisions about the investment tolerance for both time and finances to bring it to market. For Human-Centered Design to work, a company must be willing to make some of both investments up front. Each has its own challenges:

Time

Once the company is committed, the technical team knows that the clock is ticking. They must produce the most functionality possible within the available time. A rapid start allows the team to storm and norm on technology and tools, and to establish a stable “story point” process and predictable velocity. These steps enhance the team’s ability to predict capacity needs for the remainder of the work. However, the desire to start sprinting can lead to premature staffing decisions and shortcut any efforts by product and design teams to research and identify the truly important feature set. Not only does this prevent creation of a meaningful backlog of stories with a well-conceived and tested user experience, it makes it virtually impossible to build the right thing in the first place.

Budget

If your organization is still at the beginning of the HCD journey, then your current budget structure could be a problem. As an engineering leader, you may have all your funding committed to technical staff and not be in a position to quickly shift it to building out the product management and design capabilities you need to do HCD well. Your team might default to building as the way to keep busy and to figure out what to build just in time.

To avoid this trap, you need to find a way to augment your product management and design capabilities and break that cycle. This may be a permanent shift in resources from technical delivery to product and design. Alternatively, you can use a services company to boost your product and design capacity, so that you can support HCD. Either way, expect a longer-lasting shift in how you allocate budget to these different activities, as product and design teams need to work to stay ahead of future releases as well.

Unfortunately, the factors of time and budget often combine to create product releases that are barely functional and rarely viable—much less successful—in the market. Instead of building the right thing, the delivery team declares success because they met an arbitrary deadline. Who knows how much they had to compromise on needed features and quality of user experience to do so?

However, there is growing evidence that more time spent on design up front yields better long-term results. A Forrester Total Economic Impact (TEI) Study for IBM showed that the company’s design thinking practices cut costs by $20.6 million. Over three years, IBM expanded use of design thinking to one quarter of its entire portfolio, contributing to a $18.6 million increase in profits. McKinsey Quarterly’s 2018 report, “The Business Value of Design,” found that companies in the top design quartile have an annual growth of 10% compared to the industry benchmark of 3–6%, and a total return to shareholders of 21% compared to the benchmark of 12–16%. These companies demonstrate the value proposition that investing in design solutions that better meet user needs and address the most impactful user problems ultimately increase profits.

Building Momentum Without Building

Imagine that you have made the leap and are going to invest in Human-Centered Design. What is the right kind and level of involvement for the engineering team to have with the design team, and what else can they be doing while the research and design is underway? There are a couple of schools of thought:

Just Wait

In some ways, this is the easiest answer. HCD focuses on problem definitions and solutions to determine what to build. Development determines how to build it. Until the research shows the channels and features that will be used to deliver the service, there is little that a technical architect can do that would be considered worthwhile. Until the information architecture and UX design have been approved, there is little that the developers and testers can build. It’s reasonable to consider waiting to involve the technical team until such milestones are met.

However, there are some valid counterpoints to this: the choice of technology platforms, availability and capability to develop what is decided, buy/build decisions, training, technical proof of concepts, and understanding of the cost and timeline implications of all of these factors is part of determining if the business and strategy plans are viable overall. If they’re not, then this can help the design team to understand any technical constraints, and to know what options are practical and whether they need to iterate with users to test alternatives.

Good product owners are able to take such technical feedback and guide the process to a deliverable conclusion. They can also help find new paths to viability by considering budget, time, and staffing alternatives and preparing these to be in place when the work begins. However, there is a clear downside to early technical involvement. You need to make sure that the technologists do not limit the creativity or discovery processes by jumping to implementation details or by steering the discussion to what is easiest to build, rather than what is best for the user. They need to be there for the same reason that design is there: to listen, to learn, to imagine, and—only then—to shape.

Shape and Prepare

Simply put, the purpose of engaging the technical team early in HCD is to save time and money by making sure they have the same understanding of the user’s needs and the business’s strategy as they architect and build. IBM’s TEI study found that the company’s user research ensured that teams truly understood what users wanted and how they would use the products, enabling confident investments in solutions that were less likely to fail. Some examples of valuable early-stage engagement by technologists include:

Expand the delivery options: The best decisions are informed decisions, so you need to really understand the problems you are trying to solve. Seek solutions through technologies that are both effective (solve the right problem) and efficient (solve the problem the right way). This will help the team make the best trade-offs between the ideal feature set and user experience and the lowest total cost of delivering those features. This includes evaluating buy/build decisions and understanding how to architect and deliver composable solutions as well as custom applications.

Sharpen the saw: If you are fortunate enough to have access to a broad and deep talent pool, and can assume that the experts you need will be available when you need them, then you can skip this part. The rest of us need to monitor how our choices are evolving and start searching for those skills and teaching the delivery team that we have what they need to know to be effective. The learning curve is the primary bottleneck on any new technical endeavor, so activate the team to learn.

Storm and norm: Every new team needs to learn how to work together and to build collective buy-in to the approach and tools that will be used and to stabilize their ability to predict and deliver.

• If you don’t already have a well-defined and -understood DevSecOps process, then this is a great place to start. One of the options on the table could be learning to use a complete, cloud-based managed service that includes a complete CI/CD pipeline. Or maybe you already know you don’t want to be locked into a vendor’s CI/CD toolstack. This could be a good time to master a platform-neutral alternative stack.
• If you’re deciding on a design system, there is work that you can do to learn component libraries that can be used to build it. In doing so, you may even discover an alternative that is so compelling that it influences your design system decisions.
• You might already know that the business goals for the solution impose non-functional requirements related to scalability, reliability, performance, or security, and that you’ll need to architect for one or more enabling technologies. For example, perhaps you know that you need an identity management solution that will require choosing between incorporating libraries that already exist or using a managed solution from a third party. Or maybe you already know that your internal users will have data and reporting requirements that require a reporting solution that meets stringent compliance requirements, such as HIPAA or HITRUST.

In our experience, the process shift toward HCD doesn’t need to starve the tech team for work. That time can be put to good use in ways that will improve decisions, ease the learning curve, and otherwise reduce the amount of technical and design debt that will be incurred during the later rush to build. The best way to accomplish this is to unify the HCD and Agile methodologies, and their associated centers of excellence, into one.

Agile and Human-Centered Design, Unified

Agile and Human-Centered Design evolved separately to solve different problems and to capitalize on different roles and skill sets. Blending the two is often perceived to be a zero-sum proposition, and the resulting tension can be both intense and political. In reality this is not the case. Despite their differences, the two methodologies are complementary, and in combination they are a powerful approach to design and development.

Balancing Agile and HCD creates the best outcome for users and for the business. It can create financial results that more than compensate for the up-front costs and time. In this approach, the design team can address desirability of the end product by focusing on users’ unmet needs. The technical team can concentrate on feasibility and use the Agile infrastructure for speed and iteration. And the business analysis and strategy teams can focus on product viability, knowing it makes good business sense to build the right thing from the outset.