In my last post, Why “Sprint Zero” is Not Enough, I discussed some of the pitfalls we’ve encountered with taking a pure agile approach, where designers and developers start an engagement at roughly the same time.
Instead of taking a one- to two-week “Sprint Zero,” where designers rush to get design started while the developers spin up dev environments and other infrastructure, at Atomic Object, we typically structure our engagements to start with a Research, Design, and Planning (RDP) phase. We’ll schedule this phase at the beginning of a new project or at the beginning of a new phase of work with one of our existing customers. This round of work could last from a couple of weeks to a couple of months, depending on the scope of the project.
Typically, the RDP team is comprised of a subset of the people who will make up the final project team. It often looks something like this:
- Designer: Full-time
- Delivery Lead: 1/2- to full-time, pairing with designer
- Development Lead: 1/4- to 1/2-time, providing technical input & working on system architecture
- Client Stakeholders: An important part of the team, they need to be more available for feedback and participation during this critical time
During an RDP phase, we usually look to complete the following key activities:
- Project kickoff
- Detailed storymap
- Ethnographic research/user interviews
- Detailed storyboards or context scenarios describing high-level use cases and value propositions of the product
- High-level, grayscale wireframes or prototypes of all major feature sets (sketches or digital fidelity, depending on project)
- Visual design direction (several visual design studies, direction identified, style guide started)
- Entity modeling and technical system design
- User testing & validation of prototypes
- Development backlog (based on wireframes) created in PivotalTracker (or other task management tool)
The storyboards/context scenarios and wireframes/prototypes are the key deliverables during this round of work. The goal of an RDP phase is to create a clear roadmap for the project and to uncover potential areas of complexity, allowing for much better estimation and agile scope control farther down the road. To that end, we try to discuss—in varying levels of detail—each feature set we want to deliver and get a high-level understanding of their workflows.
During this phase, it’s key to note that we don’t design every corner case and error state for the product. Instead, we look to develop medium-fidelity wireframes covering as broad a swath of the application as possible. This allows both Atomic and our clients to gain an understanding of the project and come to an agreement about where we’re headed.
We’ve learned that it’s good to go into more detail for the more complex and innovative workflows and the activity spaces that are key to the product, but it’s fine to paint in broader strokes on the less-risky, more well-understood ones. We don’t do detailed visual and interaction design at all, unless we have a particularly risky idea that we’re looking to validate with end users.
We meet with our clients on a regular basis (at least weekly, sometimes daily) to review work and get feedback. We also make sure that concepts for the key workflows are validated with target users, to identify any product fit or usability issues before we go any further.
The development lead works closely with the designer and delivery lead on the context scenarios and wireframes, providing insights into technical feasibility and potentially identifying ways to achieve the same user goals for lower cost. This ensures that even at this early stage, ideas are scoped to fit our clients’ budget and their users’ needs. During this phase, the dev lead may also be working on technical architecture, choosing technologies and doing spikes as necessary.
Starting the Project: Reliable Estimates, Ready to Go
After the RDP phase, the rest of the development team joins, and active development begins. The first task of the development team is to estimate the product backlog using story points. Armed with detailed context scenarios and wireframes or prototypes, the team can estimate with a much higher level of certainty.
As the development team ramps up and starts working on the project, the designer and the delivery lead continue to flesh out the product design in higher fidelity, working two to four sprints ahead of the development team. By this point, most of the concepts should have been validated—at least at a high level—with the stakeholders and end users. Now, it’s only a matter of perfecting the visual design, interactions, and animations, and fleshing out edge cases and error states, and the stories are ready to go.
Benefits of an RDP Phase
Working through the design before development starts allows developers to come in and crush the work very quickly, without a lot of re-work. Together with our client and their customer, the RDP team has been able to iterate on the software design, de-risking it by the time it gets to development.
This approach gives everybody on the team a much better understanding of the full scope of the application. Designers can make the best choices when it comes to applying design patterns, and developers can do the same when it comes to development and architecture. Refactors still happen over time to streamline the design and the code, but they are more infrequent and minor.
With the runway of time an RDP phase affords, there is ample opportunity to validate the design with our clients and their end users via design reviews, user interviews, and user testing. This results in lower development costs, eliminating rework stemming from poorly tested design. It is much cheaper and faster to iterate in mockups and prototypes than in actual software—developers are expensive!
The accurate estimates coming out of an RDP phase give us and our clients a much better picture of overall project progress much sooner, enabling us to work together to make smart tradeoffs where necessary. If the velocity-to-scope numbers aren’t lining up after a few sprints, we can take action to cut scope or increase budget with high confidence.
Happier Teams, Happier Clients
It’s been several years and likely more than a hundred projects since we grew beyond “Sprint Zero” and started applying this approach. I like to think of it as “Just Enough Design up Front.” It’s resulted in all of the benefits I outlined above, creating happier, more productive teams, and happier clients.