When to (re)apply?

A solution consists of humans and machines.

A solution consists of humans and machines.

A solution is not static, it needs continual revision: many changes internal or external to the solution merit will call for or merit from applying the user-centered innovation methodology to ensure high(er) levels of performance. Whenever a change is detected or predicted, the ‘trick’ is to analyse the solution and (again) prioritise focus of improvement.

To list a few drivers for (re)applying the methodology:

Changes in the context of the solution. The solution performs in a social, legal, environmental, economical, (et cetera) context. This also includes competitors, advances in technology, internet applications, et cetera. Changes to this context may have a big effect on some, or all, participants in the solution, including changes to their purpose, delivered added-value and desired added-value.

Changes in the behaviour of participants. Some or all participants may change their behaviour to a larger extent than previously taken into account within the solution.

Changes in the desired added-value of participants. Participants’ preferences on what they need change over time. This may be due to many possible causes, including changes in participants’ behaviour, expertise, optimisation of internal processes, et cetera.

Changes in delivered added-value. Participants may change the added-value they deliver to other participants. For example, what was desired was a simple camera feed (640×480 pixels, 20 fps), but with an upgraded camera the delivered added-value was an improved camera feed (1280×800 pixels, 40fps) which caused processing failures.

Changes in interaction patterns. Participants may start to interact in a different manner than before, requiring other participants to also change their interaction patterns. An important indicator that participants require more ‘autonomy’ (freedom of action) is that interactions may be started, and then aborted (become unfinished): completely stopping an interaction is sometimes the only means to act. For example, consider a checkout procedure, where there is no ‘back’ button, only ‘proceed’: if people stop the transaction (closing browser window, switching off internet connection) when viewing e.g. shipping costs, this is a hint that more flexibility is required in the interaction pattern.

Feedback from participants. Participants may complain about, or ask support for, or suggest and/or feedback that certain things do not work, or should be changed.

Some of these changes happen ‘unknowingly’: suppose a participant made a change for reasons of optimalisation, performance gain, and/or another positive motivation. Subsequently, this participant may discover that apparently other participants were depending on some previous quality that is no longer present… Key is to make these dependencies explicit.