malevole Redesign: Getting Really Real

Yeah, the title’s a gentle dig at 37signals’ bold weblog pronouncements and Getting Real methodology. I find myself nodding at most things, but at times it seems they’re over-extrapolating from their own experience and giving cocky, fly-by-the-seat-of-your-pants advice that sounds cool. Or maybe I just need to imagine “If you’re creating a new ‘Web 2.0’ application for yourself using a tiny, dedicated, multi-skilled team…” written before each statement. Anyway, now I’m going to extrapolate from my own experience and probably make some cocky statements. Isn’t hypocrisy wonderful?

If you’re in a busy company mostly made up of specialists (architects, designers, server-side coders, client-side coders, etc.), with multiple small-/medium-sized client projects on the go and deadlines to meet, you have to be a little bit boring and sensible. You can’t get away with “We’ll iterate until it’s good enough” or throw a graphic designer in at the deep end and tell them to get on with creating the interface, but you also don’t need excessive formality and endless pages of detailed UML.

So I like to create an overview specification, a lightweight document that’s a communication tool; not quite a functional spec in the usual sense, and certainly not a technical spec. Ideally, the main author should be a ‘web consultant’ (I can never think of a better job title), someone who knows the web inside out and has good awareness of design, usability, information architecture and technical issues.

Typically the document might contain:

---

Aims

A clear explanation of why the project exists.

Front-end features

A list of all the key features users will encounter, each with a short description.

Behind-the-scenes features

Aspects hidden from front-end users (e.g. automated processes, back-end integration, content management).

Site map and flowcharts

A hierarchical site map (presented as an unambiguous indented list of every anticipated page plus a pretty diagram showing upper levels only), and (for application elements) simple flowcharts showing paths the user can take (just boxes, arrows and labels; any intelligent non-developer should be able to understand it).

Storyboards

This is where Getting Real really grates, with the suggestion that fully designed pages be used to establish layouts and interaction. That just isn’t effective in most working environments, and tends to be cumbersome and confusing. Every designer I’ve worked with, however web-savvy, has absolutely loved having carefully-thought-out storyboards to work from (ideally they’re involved in storyboarding too, of course). There’s a valuable clarity of thought that comes from setting aside logos, fonts and colours to focus on basic page elements.

Interactive storyboards

For complex projects, an iterative phase using clickable storyboards to mock up the site is worthwhile, with the URL going into the main document and the conclusions feeding back into the static storyboards. Awkward interface issues can be ironed out, and everyone can have a play to understand what’s going on.

Technologies and standards

Server- and client-side technologies that’ll be used, along with development standards (e.g. W3C recommendations, accessibility guidelines, browser compatibility, etc.).

Design requirements

Branding guidelines, colour palettes and any more abstract design aspirations specified by the client. Although this is no substitute for a thorough in-person briefing and discussion, it documents the basics.

Schedule and costs

Time and money.

---

Once the plan’s agreed, everyone can then merrily get to work. The consultant/planner/architect steps back and keeps an eye on things, the graphic designer starts sketching and the coders look at databases and frameworks. The document can and should evolve during design and development, so you might want to issue numbered versions or use a wiki.

I’m already planning the malevole redesign using an overview specification, even though I’m a one-man combined dev team and client working on a gleefully stupid, pointless site. Posting progress reports’ll help me get things straight in my mind, push the project along and maybe even prove insightful in places (stranger things have happened).

Sun 5th Mar 2006, 9:24pm GMT (updated Tue 28th Mar 2006, 9:50pm GMT)

Filed under: Announcements, Hints and Tips, Planning and Strategy, Rants and Grumbles, Web

---

Comments

Comments are now closed for this entry.