By the end of the lesson, you can formulate a checkable design hypothesis from a research or test finding. You know why decisions should not be explained from memory, and you can record in a decision log the evidence, the change, the expected effect, and the remaining uncertainty.
Why is it not enough to "fix" the error?
After a test the most obvious reaction is to fix the findings one by one. This often works, but it has a risk: you fix the symptom, not the cause. If participants do not notice the cancellation condition, a larger font may help, but if the cause is that it appears in the wrong place, they will get stuck at the same point in the next test. A hypothesis forces you to state the causal assumption, and so make it checkable.
From finding to hypothesis
A design hypothesis is a checkable assumption about the expected effect of a change. (In chapter 1, an assumption was a not-yet-verified claim about the situation; a hypothesis is more precise: it links a change and an effect.) A useful form:
If [change], then [user behavior or understanding] improves, because [assumed cause].
For example: "If we show the cancellation condition next to the selection of the appointment, in a short summary, then participants can correctly state the rule before payment, because the information needed for the decision will be visible at the moment of choice." This does not guarantee success, but gives a testable statement.
What makes a hypothesis good?
Checkable: the effect is observable (observation, metric), not a mood.
It concerns a single change, otherwise you do not know which one had an effect.
It contains a cause ("because…") from which you can learn if it is wrong.
A success criterion is attached: on what basis do you say it worked?
What is the decision log for?
Iteration is modifying the design based on new evidence. A decision log is a document recording the reason and consequence of design decisions. During a project it is quickly lost why an element was moved, why we dropped a feature, and on what evidence we chose between two solutions. The decision log treats this not as administration, but as a learning tool.
The fields of an entry:
Field
Content
Date / iteration
When and in which round
Starting evidence
Which finding, how many participants
Hypothesis
If… then… because…
Chosen change
What you modified
Rejected alternative
What you did not do, and why
Expected effect
What improves, how you check it
Open question
What remains uncertain
This also helps in the later presentation. You do not have to say "it seemed better this way", but you can show which participant behavior you started from, what you changed, and what limitation remained. If the new version does not work after all, the log is valuable even then: you will not run into the same dead end again.
Evidence and uncertainty
Do not give the result more certainty than the research allows. The repeated getting-stuck of three testers is a strong signal for improving the prototype, but it does not prove that all users behave the same in a live system. In the log, mark whether a decision was made on the basis of research data, a professional principle, a constraint, or an assumption (the evidence labels of chapter 1).
Worked example: a log entry for Mai program
Finding: two participants thought the selected event was booked automatically. Hypothesis: if after the selection a clear summary and a "Submit registration" action appear, participants will distinguish selection from finalization, because the difference between the two steps will be visible.
Field
Entry
Iteration
Round 2
Evidence
2 / 4 participants took the selection for finalization (research data)
Hypothesis
see above
Change
A status at the top of the screen ("You have not registered yet") and a modification of the button label
Rejected alternative
A pop-up confirmation window (slows the routine task)
Expected effect
In the round 3 test everyone states correctly whether the registration is final
Open question
Will the summary remain emphasized enough on mobile?
Common misconceptions
Claim
Clarification
"The decision log is needed only at the end."
Recording close to the decision is more accurate, and also helps the next iteration.
"A hypothesis means we already know the solution."
On the contrary: it states what still needs to be checked.
"I can fix several things at once."
With several simultaneous changes it does not become clear which had an effect; smaller steps are more instructive.
In brief
A finding does not automatically give the solution; first the cause and the expected effect must be stated.
Hypothesis: if [change], then [behavior] improves, because [cause]; checkable and about a single change.
The decision log records evidence, alternative, expected effect, and open question.
Adapt your certainty to the limits of the sample.
Review questions
From which of your findings can you write a hypothesis today?
What is the evidence supporting your strongest decision?
Behind which of your changes has the most uncertainty remained?
Hypotheses and the decision log
Objectives
By the end of the lesson, you can formulate a checkable design hypothesis from a research or test finding. You know why decisions should not be explained from memory, and you can record in a decision log the evidence, the change, the expected effect, and the remaining uncertainty.
Why is it not enough to "fix" the error?
After a test the most obvious reaction is to fix the findings one by one. This often works, but it has a risk: you fix the symptom, not the cause. If participants do not notice the cancellation condition, a larger font may help, but if the cause is that it appears in the wrong place, they will get stuck at the same point in the next test. A hypothesis forces you to state the causal assumption, and so make it checkable.
From finding to hypothesis
A design hypothesis is a checkable assumption about the expected effect of a change. (In chapter 1, an assumption was a not-yet-verified claim about the situation; a hypothesis is more precise: it links a change and an effect.) A useful form:
For example: "If we show the cancellation condition next to the selection of the appointment, in a short summary, then participants can correctly state the rule before payment, because the information needed for the decision will be visible at the moment of choice." This does not guarantee success, but gives a testable statement.
What makes a hypothesis good?
What is the decision log for?
Iteration is modifying the design based on new evidence. A decision log is a document recording the reason and consequence of design decisions. During a project it is quickly lost why an element was moved, why we dropped a feature, and on what evidence we chose between two solutions. The decision log treats this not as administration, but as a learning tool.
The fields of an entry:
This also helps in the later presentation. You do not have to say "it seemed better this way", but you can show which participant behavior you started from, what you changed, and what limitation remained. If the new version does not work after all, the log is valuable even then: you will not run into the same dead end again.
Evidence and uncertainty
Do not give the result more certainty than the research allows. The repeated getting-stuck of three testers is a strong signal for improving the prototype, but it does not prove that all users behave the same in a live system. In the log, mark whether a decision was made on the basis of research data, a professional principle, a constraint, or an assumption (the evidence labels of chapter 1).
Worked example: a log entry for Mai program
Finding: two participants thought the selected event was booked automatically. Hypothesis: if after the selection a clear summary and a "Submit registration" action appear, participants will distinguish selection from finalization, because the difference between the two steps will be visible.
Common misconceptions
In brief
Review questions