Don't just add features - solve problems

Aug 21, 2012

Users’ attention is a rare and precious commodity.

Technology is a brilliant enabler, and it’s very easy to get over-enthusiastic with it.

I see many media owners reaching out for their to-do list every time their competitor rolls out something new without thinking about why the opposite camp had done something in the first place. Another common scenario is this - “now that we have this (module) available, let’s drop it here, here, here and there”.

Just because your Content Management System has a rich module list, it doesn’t mean you should drop them into every empty space on every page just because “it’s related”. Every time you add something, you need to be absolutely sure that you’re solving a problem, and that you’re solving it in a right way. Otherwise you are wasting your users’ time and diluting your own resources.

If an element, page or workflow doesn’t pass a rigorous “why is this here” check, it is safe to assume that it simply shouldn’t be there. If in doubt, cut.

Jared Spool has an interesting theory about market maturity cycle. Spool says that most markets start with technology, then go through features (aka checklist battles), and in the end – arrive at the experience.

Similar path applies to people who build products. If you see a designer, developer or a product manager sprinkling features here and there, you can be sure they are not quite there yet. It takes some mileage to be able to get to the bottom of things, and what usually happens is that solving, first of all, means reflecting back on the organisation itself, rather than instantly producing code or some graphics.

Thing is that many people think that more money should get them more web design. More buttons, bigger forms, longer feature lists, stacks of pages.