Building an agile design team
Anybody figure out how to do design in agile yet? My guess is no. Working in agile as a designer can be a big adjustment and although it's a big change, there is a way to structure your team for success.
The old way
Historically a design team would be made up of a few specialties. You might have a UI Designer for the fine details, a Web Designer to piece together some HTML and CSS, a Design Lead to oversee the process and a Jack-of-all-trades Designer who can be used as a swiss army knife as needed.
Before you’d start doing any work, you’d insist on a creative brief being filled out with all the details. Once you did start, you’d rely on your internal design processes which you’d honed over days, months, years of working together. You know, the part where the “magic” happens and you carefully pick out 16 shades of grey for your web app.
While you’re riffing on design concepts, the rest of your product team would be eagerly waiting for the results of your design wizardry so they could begin coding the product. When the time came, you’d throw the work over the fence to development and pat yourself on the back.
Once the developers built the designs out, you’d have the joyful Design QA process where you tell them to move the button 2px to the right. Anyone who knows anything about HTML & CSS knows this pain. Eventually, you would all come to an agreement on the product and release it out into the wild. Then you could go back to complaining about developers and vice versa.
In an agile world, this whole march to Mordor fails.
The specialist problem
Many teams will try to take that waterfall process and drop it into agile. It fails miserably for a few reasons. One of the first problems is design specialists. In agile, jack-of-all-trades designers are much more valuable than one trick ponies. I’ll get into the why later on but if you’re a designer, start panicking now if you don’t have a well-rounded skill set.
The timing problem
When you start working in 2-week agile sprints, you’ll never have unlimited time like in waterfall world. You need to figure out a new process for creating work in a circular manner. It’s okay to show a design that isn’t 100% complete to your development team for feedback. They just need to estimate the work and you can come back to it later to finish it off. Just ensure the broad strokes are solid and move on.
The design island problem
You are no longer on design island. The bar is closed and its time to head back to the mainland with the rest of your team. Seriously, the most important part of doing design successfully in agile is strong collaboration skills. You’re no longer on a separate design team, you are part of a scrum team that is building a product together.
Scrum designers
For a design team to be successful in agile, there are two key roles you need. A designer who is embedded on a scrum team with developers, QA and product is what I like to call a Scrum Designer. You are an official member of that team and you should be attending all stand-ups, grooming, planning and retro meetings. The way you succeed in agile is by building trust with your team so that they will give you the time and support you need to deliver great designs.
If your company has multiple scrum teams, you should have a designer on each of them. Some companies will have a designer dedicated to 2 teams, 4 teams, 16 teams. This fails because the designer is spread to thin and not able to build the trust required to be a full team member. They’ll always be viewed as an outsider who sticks their nose in and is a bottleneck for the team.
Its probably getting clear why jack-of-all-trades designers are valuable in agile. Yes, you may have an extended design team you can lean on for support and help. However, your main day to day interactions will be with developers and other non-designers. That means you need to be able to wireframe prototypes, polish high fidelity designs and even code the HTML and CSS for some of those designs. I cannot overemphasize enough how important it is to learn basic coding. Besides being fun it is the perfect bridge you can use to build trust with the developers on your team.
System designers
The second role you need for your team to work well in the agile process is at least one System Designer. These designers don’t belong to a scrum team. They are information architects, design system experts, and great at seeing the big picture of where a product is going.
The downside of Scrum Designers is that they are so embedded in their team that it is hard for them to see what the other teams are doing. That is where the System Designer comes in to tie everything together. If team A’s workflow is going to crossover into team B’s workflow, the System Designer ensures that happens in a fluid manner that enhances, not hurts, the UX of the product.
In some cases, your System designer may also be your design lead. There’s no problem with that if you choose to structure your team that way. However, they don’t need to fill that role. Instead, I would encourage you to think of a System designer like you would think of a Software Architect. An experienced team member that has built products in the past and knows the larger patterns and themes that need to be crafted for a successful product.
If you’re new to agile or have just never felt comfortable, hopefully, these tips on how to structure your team will help you feel more secure. Honestly, I’m still not convinced design is an agile sport, but this is the best system I’ve found for playing it.
