Skip to navigation

malevolent design weblog

This blog is now defunct, but you can find more stuff over at my personal site

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).


Comments

37s always has some great insights and suggestions, but i agree - they are not the beall/endall. their successes are admirable. here's hoping they keep it real.

— bughouse, 6th Mar, 6:43pm


Comments are now closed for this entry.