Process tweaks for rapid HTML delivery

In the past at 24.com, we followed a very linear process of website and application development. The process was characterised by discrete activities performed by different teams, with a hard sign-off at each stage before delivery to the next team.
I’d say it was a production-line process, with each stage needing to be complete before handover to the next team.
Of course, it also mapped nicely to the organisational structure at 24.com, and it was easy to lay out on a gantt-chart for project planning.
The process went something like this:

1. Someone (usually an editor or business manager) comes up with an idea for something they want to develop
2. Project kick-off meetings are scheduled, and a team of project managers, creative people, tech guys, business analysts, business owners, editors and anyone else with a stake is assembled (This meeting can take some time to set up because it contains so many people)
3. Business Analysts document the requirements, create use-case diagrams, process-flows, wire-frames and put it all into a BRS or “Business Requirements Specification”
4. Designers design the website/application in Photoshop or Illustrator
5. Interface developers painstakingly recreate the designs in HTML, CSS and Javascript, creating ‘flat’ (non-databased) versions of the site that work in every browser supported.
6. HTML pages are handed to developers who start making the app or website dynamic. Database access, display code, business logic, iterators..
7. Business owner thinks up some changes
8. Developers try to accomodate
9. Layouts get screwed
10. Designers pull their hair out, and integrate changes into their designs

Interface developers re-code the changes

11. Developers go crazy trying to re-implement the new CSS and HTML now that the app is already running
12. Developers demo the site
13. Everyone flips because it doesn’t work properly in Internet Explorer
14. Developers say “it works on my machine”
15. Designers point out that they handed over perfect html
16. Everyone is miserable
17. Project takes forever

Apart from the issues with inflexibility in the process, it was slow – it could routinely take 2-4 weeks to create high-quality, tested HTML templates from the Photoshop designs.

Recognising the flaws in the proceess, we turned things around, and it’s worked very well for us.
We’ve completely cut out the step of creating flat HTML from designs and then handing those to developers.
Instead, as soon as decent quality wireframes are available the developers can start building and prototyping an unstyled app. Once designs are approved, the analysts pick through them and document all the rules – where particular pieces of content come from, how often it’s updated, what sort order to use, the update interval, whether updated from a feed or manually.
The application developers work directly off printouts of the marked-up designs.
While they are writing code, the interface developers are styling their work.
They use the same source-code repository (SVN) to check out the templates, CSS and JS, and make their changes on the same code-base as the website developers.
Instead of a linear process, it’s now completely parallel, and the site takes shape while the logic is being added.
Changes are much easier to accomodate because they don’t have to do a round-trip through multiple teams.

I had hoped for some success with this process change, but the results have been astounding – we’ve cut weeks from the schedule of projects we’ve tackled this way, the developers and designers are much happier and more productive, and we’re able to flex and accomodate change during the project with little impact on the timelines.
If you’re building websites like a factory production-line and experiencing any of the common problems, I highly recommend trying to work in parallel in this way.

I’d love to hear your stories or feedback on how it’s done in other organisations – drop me a note in my comments and let me know about your experiences

Related articles by Zemanta

• Methodic approach to CSS coding: Four Bubbles Model (woorkup.com)
• 35 Fresh and Useful jQuery Plugins (noupe.com)