This isn’t the first time I’ve thought a lot about what an Agile Design process looks like. We practice it every day at SPARC without any formal definition. As our design team has grown in the past 3 years, we’ve let go of some traditional design practices in favor of ones that more closely match the work we’re doing. Our projects range from UX for software to marketing websites. Each project is slightly different, based on the team and the overall goal. When we call it a process, we’re really just looking at the common practices that make any type of project successful inside our environment.

Key concepts to Agile Design

• Communicate –  daily stand-ups encourage communication between designers,  developers and engage the client
• Collaborate – teams of designers with different strengths learning from each other
• Iterate – use the sprint cycles to scope work into manageable chunks
• Pivot – agile is broken into sprints so you can pivot to a new goal as the business need arises, design has to accommodate this thinking
• Finish – complete work by seeing the end of a sprint cycle & alignment with the goals

Using Agile to your advantage

One big difference in what I consider Agile Design vs. a typical process is that you are working with developers using the Agile Methodology to program. Some of the highlights for designers about this development methodology are:

• Sprint cycles of 1-3 weeks producing a working increment of software
• Break down bigger problems into smaller units & iterate on them
• Working from a backlog of features that can be re-prioritized based on the business need
• Rituals that encourage communication & transparency with the team and the client

As a designer, these translate to some different habits. By breaking down a large problem into executable elements you constrain yourself to finishing work within a sprint cycle. And the ability to iterate on a problem removes the fear of getting it “right” – you’ll be able to take another pass at it later. The rituals of stand-ups and sprint reviews take the design process out of a “black box” and make it transparent. The client and the development team invest in the design process and the final product.

Creating a team around the project

Design is never one persons job. It’s difficult for a single designer (no matter how talented) to cover the segments of Strategy, User Experience, Interface Design, & Front-end Development (or execution). This is where a team of people works best with 2 or 3 designers contributing to the overall goal. And contributing at different times in the project.

We don’t have many specialists on our design team, but we do have people who have strengths in one area such as UX or Visual Design. By staffing multiple people, we use their strengths where appropriate in the project timeline. The team that starts the project are still remains invested until the end. But their workload can decrease as the project moves into a different phase, and other designer team members step up.

Not to say one person can’t deliver on all of the above, but I believe there is value in the additional perspective of multiple designers. We’ve found it’s extraordinarily hard to stay focused on the UI, if you’re also the same person charged with prototyping, coding and user-testing that UI.

Lastly, learning that occurs when you have multiple designers working together. By mixing and matching different strengths & experience levels, they can use the project to learn from each other.

Learn from Good Projects

Look for “good” projects and overstaff them. This may seem counterintuitive, but when something is going well, try and find as many touch points for other team members as possible. What’s a “good” project? A good project could be an enthusiastic client. Or a good project could be an idea that’s interesting to the design team. But could also be the chance to work with a rock-star developer, or a project manager you trust and designers can learn from.

And a good project just feels right – it works, it’s a smooth process, and everyone’s excited about the results. Once a designer has experienced the tangibles & intangibles of a good project, they’ll bring that experience with them to the next project.

Communicate early and often

Another shift that I find encouraging is the amount of communication from designers. It’s in the nature of most designers to work heads down, and in the nature of most agencies to not share progress until the final design is magically “done”. Our designers uses basecamp to show iterative progress to the team. Iterative being key. Nobody gets upset when they see a half finished design because it encourages feedback. And because it’s iterative, there are no surprises for the client at the end of the process.

Continue to Evolve

There are many smaller best practices our team uses that help compose an “agile design” process. Over three years we’ve continued to evolve our process & practices to match the type of work we get. That word evolve is important – we’ve been given the creative freedom to decide how we want to work. We discuss these practices in open conversation very regularly. We try not to be afraid to try a new technique, or throw out an old practice when it stops working for us.

Few other Sources

There is a lot online about this subject, probably worthy of a separate post in itself. One in particular that inspired me was Doing UX in an Agile World: Case Study Findings– it summarizes how Agile Scrum impacts the User Experience & design process. A second article documents a few best practices in Agile. For more, google the term “Agile UX“.

And thanks for following along! These practices continue to work for us & I hope they are useful to you as well.