It is quite difficult to get all the questions you have in order in advance. Often the real research questions arise during discussions with stakeholders, with users, with other UX'ers, with developers, in the shower. Not only in the available time that you are given at the start to do research. You want a quick "answer" to these questions. Cumulatively saving up dozens of research questions until there is a large user test can result in a lot of extra work in the long term. By reserving time for research between sprints instead of only at the start of the project, you can also better substantiate and communicate adjustments and changes of direction. This can influence support and acceptance.
6. Just in time research
Just in time research is connected to agile research . Usually qualitative and quantitative research is the first step in the design process. After this step you have gained the insights and you start designing. If you think about it, it does not always make sense to do the research first, finish this step and then design and develop.
As with agile research, there is a lot to be said for postponing this research moment until more concrete steps are taken in the actual realization of a concept. The direction of a project changes quite quickly, often during the development of this concept, which can often make generated insights and information less relevant. Moreover, you only really learn when something is live and there is “real” interaction.
Just in time
Just in time research focuses – just like more agile matters – more on the here and now. Generating insights while knowing what you are looking for and what you want to test goes much faster than without focus. You can then quickly anticipate this before starting development, or you place it on the backlog to quickly pick up in the next iteration. We believe that agile/just in time research will really take off in the coming year.
7. Guerrilla testing
User research is often done from a lab, or another malaysia phone number list controlled environment with people who have been invited to a panel and who know what they are there for. But this selectively selected, controlled test is in principle already a small pitfall. Because how realistic is this group that you are testing with? These are people who have an hour available, want to participate well in the test and therefore have the patience to walk you through an entire test. Something that an average user of your digital solution will never have. They want quick results or an experience that does not bother them.
Normal end users
In the wild, you will encounter “normal” users and situations more quickly. The environment is therefore more natural. They often do not have much or any time, so they are more realistic than “testers”. They can also be more honest (because there is no time for nuance either). In the wild, testing often used to be done by means of paper prototypes (still possible, but it feels a bit clumsy to present a digital solution to a random person with some sketches). This often served as a reality check for the development of a concept. Because real UX cannot be tested this way.