When designing the interface of a tool (be it a real world instrument, a program or a web-site), we usually have the following questions:
- which controls to use?
- how should they be arranged?
What is wrong with this (apparently normal) picture? I think the problem is that these steps should not be the first ones in the list. Normally, any project starts with gathering the requirements for it, which implies talking to potential end users, conducting market research, etc.
Small companies or individual programmers usually skip this step, because they have no time, or money; worse - they don't think this is necessary because of the "I am not going to take advices from a user" mentality.
I propose another step, which has to be performed prior to answering the questions above - ask yourself "which questions the user will ask themselves when using the program?". This is what I call "question oriented design".
The benefits of question oriented design
Poor man's interviewing users - one difference is that this forces us to place ourselves in the shoes of the users and see things from their perspective - this is not a perfect equivalent of interviewing potential end users, but this is better than doing nothing at all. It prevents us from doing things we think are useful, such as displaying different intermediate values, status information, and so on. Developers like this - I want to see the state of my variables, the contents of memory areas - this way I can spot problems and troubleshot them. It may come as a surprise, but users rarely need that much information - to them it is visual noise.
If "How do I see the intermediate value of this calculation before I get the final result?" is not in your list of questions - there is no reason to display that value.
- Avoid narrowing your horizons - question oriented user interface design provides a high-level view of what has to be done, but it does not tell us how to implement that (which widgets to use, where to place them, how to align them, etc). This prevents us from prematurely constraining ourselves to the possibilities of the chosen widget set. Also, this makes it easy to divide a task between a designer (someone who is good at designing) and a developer (who is good at programming) - let them do the job they are good at; after all, we don't let our doctors to build our bridges nor we let our architects to heal our children.
- Post-hoc checks - "no matter how far you are on the path of evil, turn around now", an old proverb tells us. The approach can be applied after a program was written and given to the masses. All you have to do is go through each widget (checkboxes, labels, buttons, etc) on the screen and ask yourself "which question does it answer?". Widgets that provide no answers are candidates for removal.
Question oriented UI design, a case study - BillReminder's timeline widget. The mailing list discussion shows how the timeline widget evolved from its original form under the guidance of question oriented UI design. An illustrated summary with additional examples will be offered in the next article, stay tuned.
