I was afraid to work in an agile environment. I felt like I would be amongst a group of developers who wouldn’t understand where I was coming from. This is because agile isn’t a style of work that is typically associated with design practices. It was created as a way to develop code better and faster in teams. So, it wasn’t unjustified for me to think “I must be crazy” to take the leap into an agile company.
Design often is time consuming and needs the structure that a “waterfall” style of working provides. The work-flow usually goes something like this: discovery, planning, design, development, and testing. The design is front loaded and nothing starts until a final design spec is approved by the client. Then work can commence actually building the product.
The reason for this (or at least the thinking behind it… I think) is that great design isn’t a process that lends itself to working quickly in that it requires editing, pruning and a lot of care. You work, often long hours, by yourself coming up with multiple viable solutions to problems. Then you review them with other designers and your creative director to make sure that things are on track. It is a process that takes time, energy and resources. It is common to spend a long time determining which is the best option to move forward with and then carefully making sure that everything is just right before showing it to a client for the first time.
My experience working with a team in an agile workplace has forced me to unlearn and relearn a lot of what I had been trained to do and have been doing for the last 10 years of my life. At it’s most basic, agile to me means that you aren’t looking for the best answer, you are working toward the best product. An agile project may start a little rough around the edges and get refined over time until they are polished to a razor sharp point. More importantly, it means that design and development most often start at the same time. Both design and development will continue to work together on and off throughout the entire process. This iterative way of working means that we can innovate and adjust as parameters change and ideas come up. You couldn’t do this if you were working any other way.
As a designer working in an agile environment, I am essentially designing in public (or naked for the promotional impact of the article title). It isn’t that I am standing in front of everyone with my screen facing them. What it does mean is that my design concepts are often shown to the client or team directly with little or no editing. There are checks and balances to make sure that the output is high-quality, but the pace is quicker. These concepts will then move quickly into production, or be applied to an already existing website or application. The design is informed completely by the project goals and exists to support the product and make it more clear and usable. In agile, the design has a very specific purpose and place within a project. It isn’t that it isn’t important, it just isn’t the total focus that it often is at a design focused company. This helps to create better all around software and not just visually appealing software.
It didn’t always make sense to me. In the beginning, it often felt like I was working based on a stream of consciousness and not a larger plan. In reality, this is more or less true. It was very uncomfortable to me at first, because the work really needs to flow at the pace of the project. My pace needs to match what the team needs in order for everything to move along smoothly. It isn’t something to be afraid of though. It also helps to bind the design process more tightly with the development process. By working so closely we can make software that does what it is supposed to right down to the roots. It also creates a much closer and deeply connected team. We don’t have to worry about “the designers” or “the developers” rivalry that happens when design is completed up front and then handed off. We are a team and we work together toward a common goal. This is pretty refreshing.
What I thought before going agile was that it could limit my creativity. I have found the opposite to be true. By designing in the open and sharing ideas openly I feel more effective as a designer and more engaged in the projects that I am working on than ever before. Removing the barrier of having to be completely “finished” with a design before implementing anything, has allowed me to try ideas that previously may not have made it into the product. This allows for incremental innovations in the design and removes the anxiety attached to floating new designs out into the wild. If something works, we can enhance it. If it isn’t working, we can always change it. This does require a good working relationship with clients and a lot of trust from them. Thankfully, we are good at cultivating healthy relationships with our clients and they learn to love us because of how we work.
I unashamedly design naked. You should try it too.