BloggEd

Recently I was frustrated by the design of my pet project. It had most of the features I needed, but I thought to stop for a while and try to see what I would think of it as a user – more precisely, why the user would choose it instead of another software doing the same tasks (and perhaps even more).

My result was that she wouldn’t. There are existing projects that meet all the needs I can imagine, and I also found the software too awkward to use. Why was this so, I asked myself.

I found a very fundamental reason which I shouldn’t have missed, but I still did: all the requirements were derived from concrete needs, I lacked one, single philosophy of design upon which the software should be built. Partially because of that mistake my requirements seemed a bit random.

My solution was to restate requirements using this simple philosophy:

it must be as simple to use as possible

that is, no single feature should be added unless it makes overall use of the system easier, minimize the number of mouse clicks/key presses needed to do any given task, make it obvious to use without user manual etc.

Usually we do have some main strategy (or philosophy) in mind when starting a new project, but it really pays to make it explicit. Write it down and consider for a moment what it really means. Make that statement only one sentence long, and put it in front of your monitor or main page in development version of your software. Whenever you are thinking something new, reflect that thought against the philosophy, and ideally you should be able to link that philosophy against every functional requirement your software has.

It is consistent application of main philosophy which makes products really stand out from others. At best the philosophy is visible in the end product, like it seems to be with anything that 37signals releases.