Waterfall vs. Agile
In software development there are two ways to develop products: waterfall or agile. The waterfall process takes the necessary time to design and plot all aspects of the application from front to back, and does a hand-off to development for implementation. With agile the work is compiled into a development backlog that includes the full scope of your project, however it is broken out into two-week sprint cycles in development. Both have advantages and disadvantages, but for the purpose of this post I wanted to focus on the positive aspects of defining an agile design process.
Agile software development helps to integrate product, design, and development strategies seamlessly. Since so much can change within the evolution of a product, agile has become a standard for most agencies looking to innovate rapidly. Agile allows for tasks to be assembled and prioritized throughout the week, and gives a great deal of flexibility. A traditional sprint cycle is two-weeks, and design is usually one sprint ahead in handing off the production assets for the next sprint.
Since agile contains so many moving pieces it can be easy to get lost or disorganized. I find having a development backlog from the start helps sync product and development tasks, which makes designing the full scope of the features a lot easier to complete. Once there is a clear direction to the development backlog it is a lot easier to map out the different aspects of the build. Since a product owner traditionally prioritizes the tasks completed within a sprint cycle it is helpful to be flexible in how you approach your design. I usually map interactions to user stories to ensure the proper screens are accounted for, and will refine individual screens as the sprint cycle approaches. Taking a soft pass at the overall layout of the app helps define a baseline of files to work from, which makes adding or editing screens a lot easier. Keeping each screen confined to an artboard helps to organize your design. I like to take a general pass at all the screens prior to getting too far into details. This helps to define an over-arching creative direction, while developing interface patterns for repeating content elements. This part is vital to ensuring consistency and quality throughout your application. Without the right direction I have seen many clients come to me with designs that are less than halfway complete and lack any clear direction to the decisions they chose stylistically.
The goal of my work is to create consistent experiences that align product, design, and development into one cohesive path.
Before any development is done a kickoff meeting is held with every stakeholder to coordinate the efforts in the build. The estimation timelines and assumed velocity (amount of work that can be complete given resources) help to define the story points that can be included per week. I find one dedicated design resource leading two development resources produces the right amount of velocity for most sprint cycles, which equates to around 12 points per week. Once a baseline is established for velocity the planning part can take place. It's helpful to plan all weeks of the sprint at the initial start to give some organization to the build. Every two-weeks there is a list of tasks completed, and at the end of those two-weeks there is a review process for functionality and design. In smaller proof of concept builds I find one-week sprint cycles work a little better.
Defining Agile Design
The process of designing on an agile schedule is something that always has its fair share of complexities. By starting with a development backlog it helps to ensure the product and development aspects are accounted for, so when designs are completed it accounts for as many edges cases as possible.
The goal is not to define a process that is rigid in implementation, but rather to suggest that by coordinating the efforts from product, design, and development it creates a more consistent and cohesive product.