New blog design today on grist.org, plus a nerdy rant about iterative design — with diagrams!

Today we’re introducing the first iteration of a new blog design on Grist.org. Scott Rosenberg, our executive editor, has agreed to serve as our guinea pig — so this this new design will be introduced first over his content, and then later over more of Grist. This change is the of many you’ll see on Grist in the coming months as we refresh our product and crank up the pace and focus of our news offerings. Check out Scott’s post on Grist for more on what we’re rolling out today, and how you can help us with feedback!

From a design and technical point of view, we’re very excited about this first step — certainly because we think the design is cool, but also because of how we’ve decided to approach this sort of evolution on Grist.

There are fewer activities more fraught than the undertaking of a major web redesign. These sorts of projects generally take forever, follow circuitous and jerky routes through a forrest of requirements and edicts, and often end up somewhere short of where you’d hoped they would. Plans are laid out in a linear, (waterfall) fashion, and often extend stiffly into the future horizon. Likewise, scope tends to balloon, meaning that redesigns rarely confine themselves to a particular product or problem, but spread across the available landscape via an often malignant web of dependencies and good intentions. Change becomes ever more expensive. Risk increases too, as does cost. Things look something like this:

Like many small web teams, Grist has been using agile methodologies to help us manage our web development activities for some years now. We’re now extending this philosophy into the design and product development process too. Nowadays, our design activity adheres to some general principles, but otherwise concerns itself with a series of smaller changes or products that are deployed much more quickly and then iterated upon. This allows for rapid change in priorities, lets us adapt to unforeseen problems, and keeps us constantly thinking about only the decisions we need to consider. Visually:

This approach is not without its pitfalls … for example, maintaining design unity and consistent state for the whole site is more difficult when designing in this way. However, what we’re aiming for is a pleasant, continuous, rolling evolution that is actually less jarring that the traditional massive-end-reveal that often characterizes redesigns.

As long as we have a set of principles to which we adhere, we think that this approach will prove effective … only time and (more importantly) our readers will tell.