Clarify focus and scope

From ICT research methods
Jump to: navigation, search


To get a grasp on what stakeholders want by getting a better understanding of their needs and requirements through quickly testing a general solution path, or to help stakeholders become aware of what they really want. Based on what your field methods tell you, you can ideate possible solutions (for example by creating brainstorm maps, paper prototypes and other “throw-away prototypes”) and discuss them with stakeholders to clarify the problem and to specify requirements. Occasionally, you will complement your explorations, in a break out, with expert information and existing solutions to fill in your knowledge gaps.


With the Clarify focus and scope pattern, you can retrieve information from the application domain (Field), and rapidly process it in Workshop so it can be fed back to the stakeholders as a proposal and an overview. You will occasionally identify and fill information gaps using existing work (Library).


This pattern is applicable when you are trying to understand the stakeholders and their goals, and when the stakeholders’ wishes have not yet fully crystallized. This is usually the case at the very beginning a project (problem analysis phase).


Even though you can quickly check your assumptions and interpretations in the field by developing them in Workshop, this is not a thorough check as Lab research is missing. Adding this will strengthen your results, but will also take more time since thorough testing is time intensive.

Because Library methods come in third place in this pattern, there is a risk you miss existing solutions that already (partially) solve your problem. Keep an eye out to prevent yourself from re-inventing the wheel.

Make sure not to spend too much time on prototype creation: the goal is not to present the stakeholder with a minimal viable product, but to create something that gets the conversation going and helps the stakeholders to get a better understanding of what they really need. Strip the details and focus on what is truly relevant for the project’s core. At this point details are completely unimportant and can even obscure the real goal of the discussion (e.g., a stakeholder complaining about the label of a button instead of giving feedback on the fact that your solution contains a form).

Even if you keep in mind not to spend too much time creating a full prototype, it is likely that you do spend some time and effort on a prototype. Never forget that these products were not meant as a first version. Therefore consider and treat them as “disposals” that are only meant to help you and the stakeholder to clarify the problems and demands. Throw them away once this phase is concluded! After that, start with a clean slate, and don’t let your previous work obscure the next steps (kill your darlings).

Examples from practice

Interactive installation

You are asked to create an interactive installation for a museum. The conservator is very enthusiastic but has little technical knowledge and background. To get an idea of what he is looking for and what might be a feasible solution, you interview him and a few visitors (Field). You then create a throw-away prototype of your solution (Workshop) and take it back to the conservator to further specify the problem (Field). This provides input for a better prototype (Workshop) that you will then discuss with the conservator (Field). At some point you will feel the urge to check for existing applications (Best, good and bad practices, Library) which will give you confidence that the ideas you are discussing can actually be built. Finding these examples also feeds the ideation process with the conservator.

(1) What kind of interactive installation does the museum need?
(2, 4) Create an artifact that makes my ideas discussable
(3, 5) What aspects of the artifacts match the needs of the museum?
(6) Break-out What ideas from existing applications can help me focus?

Automate a manual proces

You are building an app to automate a manual process. To get a grasp of that manual process, you observe one of the stakeholders: someone carrying out the manual process (Field). You create a paper prototype of your solution (Workshop) and after you have shown it to the stakeholder, you create a working prototype (Workshop) using a framework that fits your needs and that you have read about in literature (Library). You keep fine tuning and improving your prototype by discussing it with the stakeholder and making adjustments.

(1) What is the currently used manual process??
(2) Create a paper prototype of an app to automate this manual process
(3) Does my solution fix the problem?
(4) Break-out Which framework helps me to build this app?