I’m a big proponent of agile development (although that’s a bit of an understatement, I’m huge fan), the problem with the most common methods (SCRUM, for example) is that they don’t work so well when the entire project is smaller than a single sprint and the development team can be counted on one or two fingers. This is the case for many fairly straight-forward websites which can be built by a single developer in under a month. So, I’ve been thinking about how to take some of the ideas that make SCRUM so efficient and apply them to small web projects.
I propose that instead of using time for breaking up the development, a series of steps is used based on the natural evolution. These steps are designed to give a result that the next step can continue to work on so that no effort is wasted. The purpose is still the same; to give the product owner a chance to monitor the progress and adapt the solution based on experience with the prototypes and to accelerate the development efficiency. Every step should be demoed and should be iterated until the product owner is happy with the result.
The following tasks are used to break down a web project: Ideation, Content, Functional Prototype, Graphic Design and Finished Website. I choose to place the content creation and building of the functional prototype before graphic design simply due to the fact that I find the user experience way more important than eye-candy. By adapting the graphics to the function instead of adapting interaction design and content to a graphical profile the end result is focused on the user and the user experience.
During the ideation phase the purpose and basic information architecture of the website is decided, the result can be in the form of descriptive texts and/or sketches, for example. It’s important that everyone who’s going to be contribute in the development, maintenance, graphic design, content creation and of course the product owner participates in the ideation so that no one feels left out and is prepared to use their skills to bring the end result towards the common goal.
Using this information the content is created, nothing is final in a living product (which a website is) but the closer this content is to being final the easier it is for the interaction and graphic designer. It’s not just easier, it’s a prerequisite to be able to create a functional prototype simulating the final user experience and creating a graphic design that will resemble the final website.
The functional prototype is created on the same platform that the final product will be developed in and deployed on. This way no work and effort is wasted and we also make sure that all flows and technical solutions work in the real world. For this reason I don’t use wireframing tools and actually discourage others from using them as well, setting up the basic structure and graphic layout in HTML is literally done in minutes and we can then start producing real results. Do a quick check so that the prototype works on all relevant platforms and adapt the layout to the format on different devices, if desirable (which it should be).
When the work with the functional prototype is completed it’s used as a base for the graphic design. It’s very important not to lock down any design decisions until now (even though it’s always good to have ideas from the ideation phase forward) just because the design has to work with the content and user experience, not the other way around.
By continuously working on a prototype based on the target platform we’re ready to deploy when we otherwise just would be starting out developing. As a bonus we’ve had the time to really test the functionality, think about the information architecture and base the graphical design on the content and user experience. This method is not only applicable on new projects; the same steps can be adapted to new functionality and flows in existing web sites.