Long gone is the time when what the designer creates on day one sticks. There is no longer that one genius moment of creation that forms the entire experience of a project. In the world of Agile, there are endless moments of creation. So before we go any further, let’s embrace the Agile Manifesto to “Welcome changing requirements, even late in development” (agilemanifesto.org/principles.html) and accept that the layout, among other things, will change over time.
But just because everything is always changing doesn’t mean that everything must change. (Apologies, if your brain hurts. The sensation you now feel is exactly how designers who don’t want to be left behind feel today.) Amid the flux lurks a great constant: principles upon which design was created, principles that support the project vision, must be honoured with as much integrity as they were before Agile. Doing Enough Design Up Front is absolutely necessary.
Interview the stakeholders
The first thing to do up front is stakeholder interviews. They save you time and prevent grey hairs and are therefore worthy of a reminder. Never do all stakeholders have the same vision for their project much less the same position on their brand. To find the illusive true vision, talk to everyone involved as individuals, then reflect back to the group your results. There will be surprises, and that’s a good thing.
For example, the A-Number-One site feature you took away from the person who talked most at the kickoff meeting might turn out to be the least important feature to everyone else. And until you talk to someone in the marketing department, “Company Blue” may not really have to be omnipresent in all aspects of graphic design. If you don’t honour this principle early on, you and your clients will never be on the same page. One hundred hypothetical pages later, you could be drawing the conclusion to a Greek epic, and they could be expecting Chaucer.
Secondly, plan the basic information architecture and establish a few key user flows and use cases up front. You don’t have to do this for every feature, just in key areas so that everyone on the team can know how the baby is going to look and feel before they conceive it. Will the site have five pages or 100? How will this product handle things like registration forms or shopping carts? While it’s easy to fall back on the industry’s best practices, a great UX designer will take time to find smart ways to make these kinds of interactions both intuitive and branded.
Make use of Photoshop comps
Finally, some Agile advocates may also be tempted to remove all Photoshop comps because of the fluidity of the process. (I love this talk by Ian McFarland about Enough Design, even though he doesn’t appear to love Photoshop comps: pivotallabs.com/talks/106-enough-design).
But how many times have we heard the phrase, “My boss is a very visual person. We’re not going to show them anything until we can see the designs?” When it comes to getting approvals, Photoshop comps are an indispensable tool. Okay, so that’s not very Agile, but this elephant in the room appears so often, you may as well front-load some comping in your schedule.
Get the balance right
While Photoshop comps are the basis for all visual aspects of projects, you can’t lean on them for everything on an Agile project. A major part of the design process is seeing how all of the individual components work together. The interaction design, typeface choices, colour palettes, photography treatments, and of course branding, must get along brilliantly to achieve proper visual balance and style. Achieving that balance is not something easily done ad hoc.
Overall, doing enough design up front makes the work better. This probably translates to designing more initially than you’re ordinarily asked to on Agile projects. Too often we take the easy way out because people think, “Hey, this is Agile. It’s all going to change, so why bother?” But as a designer, you need to start from a strong position in order to set the vision, so that you have the ability to adapt along the way. After all, they didn’t hire you just to make it work. They hired you to make it awesome, right?
