Agile development has been one of the greatest efficiency boosters for development projects ever invented, the problem with the most common methods though (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 (or mobile apps) which can be built by a single developer in under a month. Instead of using classic SCRUM we take some of the ideas that make it so efficient and apply them to small web projects.
Instead of using time for breaking up the development, a series of steps is used based on the natural evolution of the project. 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 iterated until the product owner is happy with the result.
Break it Down into Tasks
The following tasks are used to break down a web project: Ideation, Content, Functional Prototype, Graphic Design and Finished Website. Content creation and the building of the functional prototype is placed before graphic design simply due to the fact that the overall user experience is 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, it can be achieved through brainstorming and workshops and the result can be in the form of descriptive texts and/or sketches, for example. It’s important that everyone who’s going to contribute to the development, maintenance, graphic design and content creation (and of course the product owner) participates in the ideation so that they can input their experience and skills to make the result as good as possible. It’s still the responsibility of the product owner to bring the entire package together (to avoid death by committee), but the participation of the entire team can lead to useful insights.
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 wireframing tools should be avoided, setting up the basic structure and graphic layout in HTML is literally done in minutes and can then be used to start producing real results. Do a quick check so that the prototype works on all relevant platforms and is responsive so that it adapts 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 in the back of the head) just because the design has to work with the content and user experience, not the other way around.
Once the prototype have been beautified we basically have a completed website, it’s just a matter of tying up the loose knots; minimizing the number of requests through concatenation of JavaScript and CSS-files, spriting images, adding sitemaps and tweaking the content, page structure and user experience. Now is also the time to test the website in all supported browsers and platforms to make sure that it works as expected. But that shouldn’t be a problem since used web standards was used to develop the site anyway.
Continously Develop the Prototype
By continuously working on a prototype based on the target platform we’re ready to deploy when we otherwise just would be starting out implementing. As a bonus we’ve had the time to test and adjust 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.