First Taste of Agile Design
, by René Morency
It was around early autumn last year we began implementing the agile methodology, but only in the past 6 months have we started to apply this methodology to our visual design process. So how have we found it?
Well the same agile principles apply; we plan, we discuss and segment the project into releases based on user stories, so far it’s proved a great way of managing projects both internally and externally. But for now I’m not going to talk about our agile process or project management, as Creative Director I’m interested in sharing how this new methodology has changed the way we approach visual design.
The Agile Process
I guess the best place to start is by making comparisons to then and now, and the benefits we’ve witnessed since January.
In short, prior to our new approach, visual design often began with wireframes using tools such as Axure. After the necessary iterations were made we moved onto applying the all important visual style to each page. With an array of colours, strokes and excellent photography at our disposal this was usually the most enjoyable part for anyone with an eye for visual aesthetics.
Agile design on the other hand changes this process, I’ve watched tasks such as the laborious process of designing individual pages give way to a modular design process in which decisions on visual direction are made by both visual designer and developer.
The shift to designing individual elements in a style guide (which are then translated into a HTML and CSS style guide), meant that page and content layout could simply be designed by sketches which significantly reduced the amount of time consumed by designing each page individually.
Individual elements are quickly replicated across multiple pages in accordance to the user stories, all of which eventually being brought together to form a website. Time saving. . ? Yes.
So far I’ve enjoyed watching this process, it’s proved time efficient, heavy workloads are easily spread throughout the team and to the delight of the project managers the number of change requests have been significantly reduced.
But above all, what’s really struck me is the way the agile design method has allowed our visual designers, developers and clients to work asynchronously. Visual designers now have the ability to guide, re-evaluate, and design pages using the visual style guide as and when required.
We’ve not lost the spontaneous flair our designers love, it’s more that we’ve channelled it into a much more streamlined process – enabling the project to continuously evolve through to launch.
Share on TwitterShare on Facebook
Getting developers and designers does not seem like the barrier that it might have once been. Where I see the resistance is from agency to client. They are so used to seeing mock-ups (might be because they are used to the print design process) that showing them a Style Guide or Pattern Library is often underwhelming. They also have problems visualizing what these elements would look like without seeing that full mock-up. I know part of this is about setting client expectations, but if you have worked with them for a few years, how do you transition them to this new process?
Hi Nick. Change is always going to be something that is met with resistance (both client side and internally), but is something that is inevitable and for most parts beneficial to both parties – even if they don’t realise it! The solution lies in communication: explaining the benefits of agile to clients. Efficiency and cost saving mechanisms always draw attention ;)
So in response to your question: the first point is that we’re able to get to screen much quicker and start delivering iterations of a working prototype that clients can test very early on (often within the first week of development). Our clients have welcomed this since they are now able to continuously see our progress and collaboratively assess the project from an early stage.
The second point relates to budget and efficiency. We break everything down in to iterations based on priority and associate an effort level/cost to it, this helps clients visualise where the value lies. It’s easy to see that allocating 25% of the budget to a pixel perfect mock up (which is most likely to change) has no real value. This helps highlight the cost effective benefits of Agile which of course clients usually welcome with open arms.
@David, thanks for the first hand explanation. @Jacob, hope that gives you enough info with regards to the style guide. As for your second point, it’s not really a case of convincing designers to listen to developers, it’s more that the agile methodology allows the project to move forward collaboratively with each team member contributing, discussing and making decisions as a team. I guess the obvious answer to your question is we simply encourage everyone to talk (and of course listen) more frequently – As the saying goes. . two heads are always better than one :)
Hi Jacob, you can see a style guide example we produced for Passenger Focus. This was designed in Photoshop early on to allow us to throw together quick visual layouts. It also meant that layouts could form during development without much prior design. For more recent projects we’re doing even less Photoshop mockups.
From my perspective doing design & front-end dev, because we’re not spending a massive amount of effort designing the whole website prior to development it means things can be discussed first between designer/developer and client. I think a lot of designers in a non-agile project will ignore advice because they’ve invested so much into their work already. At Browser we can do more iterative work because so little time and effort has been spent with the design happening in isolation.
Sound like an interesting process. Would love to hear more about your construction of the style guide that is in turned used to create markup. From a designers point of view as well I’d love to hear how you convinced your designs to listen to a dev on visual aesthetic decisions ;)