This is the celebrated journal of Mr. Simon Collison A.K.A Colly

Process Toolbox, part five: Roadmap

22nd March 2010

Part five now of my The Process Toolbox presentation. With the methodology in place, we can now focus on how the website will evolve and scale alongside exciting new initiatives, developments and shifts of focus? If we are building a “system”, how do we build it iteratively, and ensure it can evolve?

Content Audit

Simplicity

I’ll begin with a couple of quotes from two renowned authors.

When writing, Elmore Leonard tried to “leave out the parts that people skip”.

George Orwell tried to write text that lets you see the subject without noticing the words that convey it. He called it “transparent writing”.

I am also one of those old web designers who always cites Steve Krug’s superb usability book “Don’t Make Me Think!” It fits so many conversations and situations, and it sums up the way people use the web.

In tandem with that, I adore those two quotes from Orwell and Leonard, and I try and think about them during key decision-making, whether regarding audience modeling, feature requests, requirements, content-authoring, IA etc - anything in the process. If something needs too much explanation, or requires the user to think rather than do, it probably doesn’t work. We can apply the advice of Orwell and Leonard in our roadmap.

It is key that we define a roadmap for a website’s development at the earliest stage. This will remain flexible, but needs to ensure both sides can identify what features will be implemented during which release, or added as additional functionality outside of an initial costed project. These principles contribute to our roadmap quite clearly.

Content Audit

As part of defining a roadmap, a Content Audit gets the client team working hard and really thinking about what they have and what they need - and what their audience needs.

  • It measures scale, reach and sheer quantity of content with existing sites.
  • It identifies pitfalls - sullied content, migration issues.
  • It helps devise a Content Strategy.
  • This strategy in turn identifies fresh copy requirements early on.
  • We can collaborate to devise a re-write-for-web plan with the client team. This helps us squash the repurposing of press releases and horrid bloated copy from a website.
  • We can identify the most important or most recent content to be included, with a plan for adding less important or older content running up to or after launch.

This kind of audit doesn’t have to be time-intensive. If anything, getting this right saves wasting time later on. It’s one of the most vital tools that we can use, and properly scoped out, it avoids those niggling disagreements later on about quality and quantity, and who’s uploading what etc. It saves us money to have a Content Strategy based on a Content Audit.

Features vs Requirements

It is a clear mistake in any project to jump on a feature and consider it a requirement without being careful to understand the problem and the expectations around a proposed solution.

Features vs Requirements

Understanding this, and the impact it has upon what we create helps us better develop a successful website. We must prioritise requirements and only work on the highest priorities (based on key Goals) first.

We can also look to identify what is needed to begin with - what sections and features are key to the initial release, and what features might be held back or added through further releases. It may well be that everything goes in with the initial release, but this needs to be clearly defined in the roadmap. In essence, we’re talking about releasing features and tools simply, carefully and efficiently. We can then inspect and adapt the roadmap throughout a website’s lifecycle.

The roadmap is again something that might only be written when there is a true understanding of the intended audience and the weight of existing client collateral. It may be re-written, amended, scrapped, iterated after launch, before launch, anytime. The key is that it acts as a spec document to outline what features or tools might be implemented, and with which release of the product. But its broader than just a document - its a bit of a philosophy.

Iterating the roadmap can be done on the fly, but a good features roadmap is like a good business plan. If a client is involved, this is essential to building a long-term relationship, and managing expectations. When you are building a complex system, it pays to have a plan.

*Note:* Slides designed by Gregory Wood.

Full series…

This article was originally posted on Erskine Labs, September 2009.

Prev 798 Next

Superfluous Aside

Archived in Design & Web, Writing & Speaking

External References

Copyright © Mr. Simon Collison 2003-2017. Protected and licensed under a Creative Commons License. Grab the RSS feed

Engineered in Nottingham, scaffolded by ExpressionEngine, steam-pumped by United & kept alive with tea and hugs.