In the field of crisis response and management is a general rule of thumb when it comes to designing new organizational or technological solutions, what is used on an everyday basis is also used in large scale crises. This means from a design perspective that we should design solutions that can be used in everyday work as well as in the not so often large scale situations. The rationale here is that people tend to use what they are familiar with and tend to reject special applications they have little or none experience of. I would for most cases that this idea is good and valid. However, we now see some new categories of solutions that are only meaningful to use in large-scale situations and less meaningful to use in the everyday work. Solutions oriented on massive collaboration among a large network of response organizations are not very meaningful to use in small scale events where one or just a few organizations becomes involved.

Even if we add specialized features to everyday solutions, so the everyday solutions can be expanded to also target large scale events, the problem still exists. A key challenge is how can we design feature sets or complete solutions that will only be use every second month? Should we use a user-centered approach and interact with the user that has limited or none experience of such situations? Or should we adopt a user-centered approach but perhaps look at aspects that resemble with aspects of the large-scale situations? We are moving to the latter. We must avoid to ask the users what they want and instead explore what is meaningful and important in general.

The role of the designer is to transform such insights into meaningful design, while at the sometime avoid asking the user what they specifically want. Moreover, the problem is not only that the user only “need” these features every second month but they will only use it for 60 seconds. This means that in a typical organization there will be very few that have any substantial experience of these fragmented moments of use. I would therefore argue that the designer cannot and should not put too much responsibility on the specific users in articulating the needs, but force the designers to strive and explore what is desired and could become a demand. User-centered design should never be a way to blame the users for not being able to tell what they need. Hopefully, the design community will have enough confident and relevant methods to target these rather tricky design situations.