Computers are useless. They can only give you answers.
Pablo Picasso

I'm not sure the aphorism attributed to Picasso is true. I however believe that some right questions can help us to better re-frame our problems.

Which are the questions a design team should answer before, during and after the design phase of an interactive product?
The design process, as defined by the UK Design Council, identifies four distinct phases, Discover, Define, Develop and Deliver. The main steps of the Discover phase are market research, user research and information analysis. A good research starts with good questions. I believe that we should try to answer four main questions: who are our users? Why should they use our products? What information and functions do they require to full-fill their goals? And, of course, how should we implement those functions, and how should we organise those information?


We do not design four ourself: identifying the target of our product is mandatory, for at least two reasons:

  • without knowing the who, id would be difficult to decide the why;
  • identifying our target helps us, the team and the stakeholders to keep an user centred approach, minimising the risk of a self-referential design.

The identification of the target, however, should not lead to an attitude to design ad excludendum.

The need to identify, at least in a broad manner, the target of our product is theoretical motivated by the fact that people are different: diverse people need different products. But which differences should be taken into account?
Users have different motivations, mental models, different knowledge, and different resources. Those differences should be at the centre of the user research. If we decide to use the personas as a design tool, we should describe those dimensions: needs, goals, values, motivations, mental models, levels of knowledge and resources.

The motivations are linked with the why, the resources with the how.


Why does a person use an artefact? Because he is motivated to. The motivation can be intrinsic or extrinsic. If I drive at 8 am in the traffic to reach my office, I'm probably not intrinsically motivated. I would rather prefer to stay at home, or to drink a cappuccino and read the newspaper. I drive because I'm extrinsically motivated by the fact that I have to go at work.
But if I decide to drive to the sea to see the sunset, my motivation would be intrinsic.
If you foresee that your users would use your tool because of an extrinsic motivation, you have to strongly focus your efforts on the utility, usability and accessibility dimensions. If your target should use your product because intrinsically motivated, the hedonic aspects assume a greater importance.

The motivations drive the people's goals. They use their resources to full-fill them. Your product or service can be one of the resources they need to satisfy their goals. Don't forget, however, that they need some resources to use your product. Not just economic ones: they need attention, time, memory, cognition. The basic rule is: try to minimise the resources needed to use your products. This is the First Commandment of usability, accessibility and interaction design.


Which information should we include in our site? Which functions should we implement? The answers to the what question becomes the basis of the requirement analysis.

A good starting point is the competitive analysis (also known as benchmarking), to study the solutions adopted by our competitors.

A second, important step is to involve the stakeholders and the experts.  I strongly believe, however, that this is not enough: the final users should be involved in this phase. Questionnaires like the free listing and importance evaluation should be used to understand which informations and functions the users think they need.


How should the requirements be implemented is, of course, a complex issue. I promise I will dedicate a whole post on this. Here, I just wish to note that the same goal can be accomplished in different ways, and that it depends mostly by the resources of the users. Different resources, different ways to achieve a goal.


I wish to conclude with an observation concerning the participatory approach. I already suggested that final users should be involved in the what phase. Users can be involved in defining the who (who are you?), the why and the what. The how, however, should not be delegated to the users. They can know what they want, and why, but usually they don't really know how a function should be implemented.