Hello, my name is Sarah Donnell I'm, the UX research manager at Kate lab. When you hear a customer problem, it can be talked into just dive right in and devise a solution. However, it's important to remember there is never just one good solution to a problem. A problem can be solved in many different ways, depending on what we need to focus on users can be unpredictable. What we think might solve their pain points may not actually even begin to address the problems they are facing.

Therefore, it's advisable to test your ideas before you start building a solution. A way in which you can do this is to write and test hypotheses. A hypothesis is basically an assumption. It's a statement about what you believe to be true today, which can be proven or disproven using research. A strong hypothesis is usually driven by existing research. Ask yourself why you believe your assumption to be true.

Perhaps your hunch was sparked by a passing conversation with the customer, something you read in a support ticket or issue, or even something you spotted in get most usage data. There are lots of different structures for hypotheses, but I recommend using this simple statement. We believe doing this, for these people will achieve this outcome. The statement is comprised of three elements. The first part we believe doing this should detail your proposed solution to users problems.

The second part for these people should identify, who you attacked in the third and final part will achieve this outcome is where you should document your measure of success. What is your expected result? For example, we believe storing information about how an incident was resolved, how long it took to resolve and what the outcome was in a historical record for engineers responsible for incident management will achieve a 20%, faster resolution time for incidents. This is because, referring to past incident, information helps to inform potential solutions or remediation.

When writing your hypothesis focus on simple solutions first and keep the scope small. If you're struggling to articulate your assumptions about the users, it's probably better, to start with developing a better understanding of users. First, rather than forming weak hypotheses and winning aimless research studies, a strong hypothesis is easy to test it shouldn't. Take you much time to design a research today to validate or invalidate your hypothesis.

If your hypothesis is invalidated by users, don't feel disheartened. You've stopped precious engineering time being spent on building a solution that simply doesn't solve users problems. A good measure of being iterative is throwing something away because user research proves that it wasn't going to work you're, not always going to get things right. The first time we learn more about user needs as a result of testing multiple hypotheses and in turn, we generate new ideas for future rounds of testing.