27 May Why We Adopted Agile Design

Agile methodology has been around for a while, but has traditionally been applied more to development than design processes. When I took over management of Groupvisual.io from my co-founder Angela Shen-Hsieh in early 2013, I was looking for ways to simplify and modularize the way we deliver our design services. I noticed that almost all of our clients’ development teams were using some version of Agile, and thought it would make sense to align our UI/ UX design process to theirs.

I was familiar with Agile, since we had used it at Visual i/o (our previous company) when we were building the Decision Iris product in 2007-2009. Apart from the flexibility of the process, I liked the benefits that come from an agile approach:

• Better coordination and alignment among various teams
• Keeps everybody on the same page about the project goals
• Better visibility of dependencies and handoffs between and within teams
• Good issue-resolution

 
Over the last year and a half, we have gone through a process to restructure our work and delivery model around design sprints. For us, a sprint is typically a 2-week process, and we realized as we rolled out the model that most projects follow a similar pattern:

Sprint 1

Typically involves workshopping, discovery and research to understand the business and user goals, as well as the technology being used. Conceptual design ensures that the team considers the broader picture, not just the tactical goals of the project. To summarize and read-back this information for the team, we use what we call “strategic wireframes” which express the business and user goals as a series of statements that look like rough wireframes. Initial conceptual designs during this process are expressed through diagrams, workflows and wireframes.

Sprint 2

We move into design development, putting more definition and structure around the initial wireframes and concepts produced in Sprint 1. The process is iterative, typically involving a weekly checkpoint that includes key members across all teams. Between checkpoints, we try to get in 1-2 internal design cycles for the Gvio team.

Sprints 3+

Design development continues through iterative cycles, leading to production of design deliverables. After design deliverables are passed off to dev teams, the design team’s work continues — with coordination, QA and consultation during development, implementation, and delivery.

Since adopting an agile process, we have learned a number of things:

Coordinate Early

We like the design team to coordinate early on in the design process with their dev partners to make sure that what they are designing makes sense technically, and will be easy to build. This gets dev feedback and comments incorporated in line with the design process, not later, when changes become more complex. It also increases visibility both ways — so devs understand not just the design they are being handed, but the “why” and the thinking behind it. This helps devs to be in a position to make better technical design decisions during the dev process.

Communicate Often

Frequent, informal conversations between and among design and development personnel are very helpful. We generally use Skype group chat for that, and I am happy when I see a lot of chatter in a conversation. It speeds up development and boosts quality assurance, as devs can easily ask for feedback or clarification from the design team.

Have Design Reviews

It is very helpful for the design team to quickly review interim builds and get QA feedback to devs inline with their work. We’ve seen huge improvement in our products from having weekly reviews that involve both design and development teams.

Things don’t always go smoothly, of course. Here is a situation that can arise:

The design team produces something that the business owner approves and which generally looks good to the dev team. However, while the dev is coding it, they find an easier way to implement it, or maybe decide to use a different library or control. The result is something that works functionally but may not have the desired user experience. In an ideal situation, the developer would ask for the design team’s input when making such decisions. That may not be possible due to deadlines, or maybe the dev doesn’t think a formal review is needed. On the other hand, the UX team may inadvertently design something that is too hard or time-consuming for the engineering team to build. Either way, if the problem doesn’t get addressed inline with the development process, the design team should have an opportunity to review it at the next interim build and raise it as an issue if necessary.

Regardless of the issue, we have found that good communication can resolve pretty much anything. However, if the individual team members cannot come to agreement, the situation may require escalation to a manager. Managers need to be prepared for quick, non-judgmental conversations to learn what went awry and plan for resolution. We schedule weekly checkpoints between the dev lead and design lead to ensure that frequent communication is in place, and any issues that may be emerging can be dealt with proactively.

The picture I’ve come to have in my head about agile design is that it’s kind of like a garden—the team dynamic and our processes need constant tending, weeding, and watering to be healthy.