Agile Website Design
At Browser we’ve been transitioning into an Agile development process.
If you know nothing about Agile, it involves breaking down a project into individual requirements and delivering them within an iterative release cycle. This not only allows for a feedback loop involving client and agency alike, but it also gives an evolving indication of time and budget. The start of an agile project requires a scoping exercise in which every requirement is time-estimated and prioritised in respect to the MVP (Minimum Viable Product). Once that is established, and anything surplus to budget is moved into the “backlog”, requirements are grouped into one or two week releases and development begins.
Those that speak “agile” contrast the methodology to the more traditional “waterfall” approach whereby stages of planning, design, development, and testing are all done in very long, individual, and sequential steps. The problem here is that waterfalls cascade down. As every stage is “signed off”, everyone involved in the project slowly begins to realise that it’s going in the wrong direction. The client ends up with a website far from what they envisioned. Working this way perpetuates and compounds misinterpretation and provides no opportunity for correction. Agile solves that problem.
Website Design (The Right Way)
When designing websites in an agile development process the work has to follow the same iterative flow. This means that the upfront deliverables are kept to the bare minimum. Prior to development, a certain level of “design vision” is required to get a sense of the aesthetic style and brand, same too for core layout challenges, but ultimately design is about doing just enough to get by.
What agile design does not involve is the delivery of proposed concepts for large portions of the website, or worse, the whole thing (be it hi-fi Photoshop comps or low-fi wireframes).
This is tricky because good design requires a certain amount of holistic thinking (in fact, quite a lot). Therefore “just enough” often involves looking one release ahead of development. Design issues that crop up can be treated like development bugs and fixed in the next iterative. To avoid mistakes, designers must be very knowledgable — and influential when required — in the project scoping (which itself is a living process).
Design is done when required. So is research and testing. There is not a single best design method. For me Photoshop is often the preferred tool, other times a rough sketch will suffice. From time-to-time even an interactive prototype is required (websites are not static, after all). What this does mean is that however design starts, it very quickly ends up in the web browser. Anyone who tells you “the web browser is the best place to design websites” is not a particularly great designer (I can guarantee you that!) but one cannot deny, it is obviously the most important place a design must work. The agile design process is immediate in this respect.
As a front-end developer (and designer) I work alongside the back-end developer as each release begins. It’s important that communication is continuous so that both sides accommodate each other. Because design influences development and vice-versa, working in silos is a recipe for disaster. It’s also my job to bring in the big guns when additional input is required from fellow non-dev designers.
Thoughts So Far
The benefits of Agile development should be clear but I can tell you with first-hand experience they become starkly apparent, especially when your past projects have been stuck in the waterfall workflow. Designing this way is not immediately intuitive. Initially you feel like you’re committing to a style before you’ve had a chance to explore, but you must remember that Agile is a feedback and test-driven process. It makes little sense to design a whole website prior to development. This is the point at which understanding between all parties is at its lowest. By working in iterative release cycles, design evolves and in reality you get more time to improve and perfect it.
If you read my last article (I’m bored with code), this is why. I no longer have to spend weeks coding a signed-off design that unravels with every additional day the project lags. Front-end coding for me is now simply a means to reach the next iteration of testing, feedback, research, and design. That is an awesome way to build websites.
I’ll finally add that our process is very in-tune with each project. We’re not aiming for a by-the-book approach, only to take the best that Agile has to offer. (You can prise Photoshop from my cold, dead fingers.)
