Getting to Less part 2: Critically refocus

24 November 2007   

(Back to part 1)

Getting to Less is all about helping designers decide what to keep and what to throw out of their designs. Whether you’re designing software, websites, products or cities, you need to choose what to include and what to omit. But how?

Before we can even start to list the current and proposed features of our product so that we can evaluate them, we need to step back and look at the bigger picture. Even though we may have a specification or requirements document (though often we don’t!), we need to get back to the original problem or opportunity that is the reason for our product existing.

Flabby products come from forgetting what the product is designed to do and for whom. So let’s remind ourselves – and write down:

This doesn’t have to be a long narrative document. A photo of a spread of Post-it notes on a whiteboard will be more than good enough, but make sure you keep it in the project folder so you can go back to it when your focus starts to drift.

This process is particularly necessary when revising a product. On the first iteration, the design objectives are often relatively clear. The original designers are the team. But once you come to the first revision, you could have a different team and different management. It’s easy to lose sight of the original vision.

So don’t even attempt to refine a product before you can clearly state what it’s for. Critically refocus the design team on its reason for existing and take it forward from there.

Part 3 of Getting to Less to follow soon. Stay tuned.

Design theory  Simplicity

2 comments

  1. Getting to Less part 1: How to keep what you need and chuck what you don’t « Delightful Design by Adrian Short
    24 November 2007

    [...] Part 2: Critically refocus [...]

  2. OnlineMarketer
    2 December 2007

    This is a great series, Adrian. It’s amazing how many people don’t think about this stuff.

    I wonder if one of the culprits is the silo-ing of many agencies. The content people may only think about how content needs to come across. The design people see themselves as only visual. The developers often don’t care about anything besides code.

    So it’s left up to a creative director to bring all of this together. That is a recipe for failure. Everyone on the team should be working together, of course. (And I’m sure we’ve both been in meetings where the best ideas come from those outside of their particular “area of expertise,” i.e. coders showing brilliance in design, designers coming up with the perfect slogan. It has to do with perspective – being enough outside that area to see it how the consumer will see it.)

    I also like what you say about revision. Web 2.0 or whatever the buzzword is today frees us from the assumption that anything ever ends. We should think of everything as a prototype for a future iteration.

Your comments