Design and Agile: From Idea to Pilot in Three Phases

The significant investment you’ve made in your design and agile development functions won’t give you the maximum return until the two areas are properly integrated. Understanding the how agile design and development works, the proper structure of the system, and the roles people play within the process will empower you to make the shift and guide you through the transformation.

Integration offers massive benefits. For users, it helps create products that are ultimately more desirable. By bringing developers into the process early, before ideas are fully formed, they can provide guidance and insight based on feasibility and begin thinking about how they can add value. Often, this opens up new possibilities or suggests products or content that can be woven into new ones. For the agile design and development teams, it brings clarity at the start of the process. Integration provides a structure that enables the team to define the plans and roadmaps at a level of detail that makes execution faster and easier. For the business, the combination of these benefits means that it delivers higher-value products to market faster.

We’ve seen that many agile organizations invest tremendous time and money into building products, but often don’t define, test, and articulate their vision thoroughly enough.

This process has three major phases. Phase One is about establishing a voice-of-customer perspective. Phase Two focuses on prototyping, and then translating that into a plan for the full build. Phase Three involves creating a pilot and evolving it to scale. All three phases involve some form of testing with users, to ensure that the work is moving in the right direction.

We’ve seen that many agile organizations invest tremendous time and money into building products (Phase Three), but often don’t define, test, and articulate their vision thoroughly enough in Phase One and completely skip Phase Two. Doing this upfront work completely and properly is critical to a smooth build and a compelling product.

Phase One: Envision and Resonance Test

At the outset of the project, the team should understand the business challenge they’re being asked to solve. It’s their job to translate that into customer needs and associated opportunities, create the right ideas to address them, and define and communicate the vision for the future product. One or more developers should be involved in the team from the point at which they start creating and aligning on ideas. This serves to push the team to think expansively about the possibilities and constrain ideas to something realistically buildable. Such a relationship works best when everyone involved—strategists, businesspeople, designers, developers—can play various roles, based on their experience and knowledge.

During this process, developers should begin to understand the idea and how to add value in future phases. Designers and strategists should develop a clear voice-of-customer and a vision for the future customer experience, connected to clear customer value. They should create the tools—typically frameworks, visual stories, verbal descriptions, and rough wireframes—needed to communicate this future experience. Finally, they should build the beginnings of a rough prototype to show and help them plan the content of their tests in Phase Two.

At the outset of a project, the team should understand the business challenge they’re being asked to solve amd translate that into customer needs and associated opportunities, create the right ideas to address them, and communicate the vision for the future product.

When Continuum worked with a healthcare association to design a new business model to serve its members, we used short written stories and drawings to convey what the proposed experience would look and feel like. We tested two different stories and asked potential users to read through them frame by frame and share their reactions. We prompted them to explain what they did or did not find appealing about the proposed experiences—and why they reacted the way they did. This helped us understand what was most valuable, so we could create the best prototype.

Phase Two: Prototype and Resonance Test

Now your agile design and development machine kicks into high gear. The team’s objective: to do as much discovery and experimentation as needed to create a clear and thorough roadmap that will guide Phase Three. During design and testing of the prototype, developers should get more involved, helping to inform the team’s direction, refine the work, and understand the customer value. The team should begin working at a sprint cadence, with each session involving further refinement of a prototype, lasting as long as it takes to deliver some value that a user can react to, and culminate in a user test.

At the conclusion of this phase, the team should have a prototype of the front end experience that allows full nonlinear interaction (though still with some “dead ends”) based on real code. This front end and evolutions of it will form the customer experience throughout the pilot and scale. For the back end of the experience, the team should follow a “duct tape and baling wire” philosophy. The spirit here is to simulate the customer experience as closely as possible to test and learn without spending the time or money to build out a back end because it’s less important to the process of understanding the customer value. Remember, the mission is to create a customer experience that feels as real as possible, so the team can collect the most useful data from the tests while keeping the investment small and flexible.

The mission is to create a customer experience that feels as real as possible, so the team can collect the most useful data from the tests while keeping the investment small and flexible.

When Continuum prototyped and resonance tested the Audi on Demand experience, we anonymized the client and presented ourselves as a local startup, complete with uniforms. We delivered actual Audis to real people (who had previously agreed to participate) on the streets of San Francisco. When customers phoned the “call center” number to ask questions, it rang a cell phone in a Continuum team member’s pocket. When they booked a car, it was captured in a spreadsheet on a Continuum laptop. To the customer, the experience felt real, but there was no permanent infrastructure underpinning the process. This allowed us to quickly optimize the experience by testing multiple permutations and avoiding any further investment in ideas that weren’t ideal.

Phase Three: Pilot and Usability Test

In this phase, the team will begin releasing working software for continued testing and scaling. This phase may be most familiar to developers who are used to agile work. However, it’s still critical to have designers on the team and working to add detail to the experience as the team is testing and learning.

The team should identify an early adopter cohort of real users who agree to use and provide feedback on the pilot. They should expect to use the software as part of their normal work stream but be aware that it won’t be fully polished. They may notice some parts that are incomplete or still contain some kinks or workarounds. With new releases and updates every sprint, the team should survey or otherwise contact this cohort in every sprint so they better understand what’s happening. They can tailor the work in future sprints as new user needs surface, or they can reprioritize work based on an evolving understanding of how people use the software.

The team should identify an early adopter cohort of real users who agree to use and provide feedback on the pilot. They should expect to use the software as part of their normal work stream but be aware that it won’t be fully polished.

During this phase, the team should be converting the "duct tape and baling wire" back end to real code and creating the middleware layer necessary to connect it to the front end. Simultaneously, the team needs to evolve the front end so that it feels more complete and robust, more features are integrated, and it eliminates any dead ends in the experience.

When we piloted new types of accounts and experiences for a large wealth management company, our first cohorts of users were company employees and existing clients with strong relationships. Not only did we track click-throughs and signups to understand what was most appealing, we returned to people in that cohort to get more detailed feedback on the experience, so we could update and improve it in future sprints.

Adopting this system and shifting the emphasis early in the process toward one of testing, learning, and evolving will ultimately result in a better outcome for customers, better business results, and a more efficient workflow for your design and development teams. In the next installment, we’ll dig into the roles individual people play in the process and how you can best organize them to deliver on the promise of agile design and development.