By the end of the lesson, you can present the project not as a list of screens but as a checkable design story. You can tell the claim, the evidence, the decision, and the result apart, and you know why it is important to word things in proportion to the strength of the evidence.
Why is it not enough to show the screens?
At the end of the semester you have a finished prototype, and it is obvious to walk through it. But from the final result the audience cannot see what you know: the essence of design work is the thinking behind the decisions. If they see only the screens, it is as if a chef showed only the finished dish, not the recipe and the tastings. The design story makes visible why this solution, in the examined situation.
The structure of a design story
A design story is the coherent presentation of the problem, evidence, decision, and result. A design rationale is the short, evidence-backed explanation of why you chose exactly this layout, label, or interaction. The two belong together: the rationale is a "because" within the story.
The claim should be concrete. Instead of "users found it hard to find the cancellation", show in what task, with how many examined participants, in what behavior this appeared. The evidence can be a quote, an observation, a user flow, a before–after screen, or a test finding. A single strong, relevant piece of evidence is worth more than many decorative screenshots.
Evidence, decision, result
Do not leave a logical jump. If a new feature follows directly from a research quote, explain the interpretation. The four links of the chain:
Link
What does it show?
Example (Mai program)
Observation
What you saw / heard
Participants switch between several views to compare time and price
Insight
What this means
The decision data do not appear together
Decision
What you changed
Both data are visible up front on the result card
Result
What the effect was
In the next test participants chose with fewer steps back
This chain makes the presentation professionally traceable.
Do not claim more than the evidence allows. From a small test, speak about "the participants examined", not "all users". If a change has not yet been tested, call it a hypothesis, not a result.
What is worth showing?
An artifact is a tangible document or output of the design process. Choose artifacts that explain a decision:
a short research summary or a telling quote;
a persona or a situation description;
a user journey or user flow;
a low-fi sketch and the refinement that came from it (before–after);
a prototype detail;
a test note and a finding;
an iteration from the decision log.
You do not need to project the whole workflow. A screen is useful if it shows which problem it answers, and what shows that the answer works or is still uncertain.
Condensing a long project
A semester's work consists of many threads; only the main thread goes into the presentation. Filter questions:
Did this change a decision? (If not, it is probably not needed.)
Is it necessary to understand the main claim?
Is there evidence behind it, or is it just pretty?
What you leave out can go into an appendix.
flowchart TD
A["Problem and context"] --> B["Research evidence"]
B --> C["Design decision"]
C --> D["Prototype and test"]
D --> E["Result and limitations"]
E --> F["Next step"]
Worked example: the story of Mai program
"In the research, participants could not compare the basic data of events, so they opened extra tabs. On the cards we displayed the time, price, place, and registration requirement together. In the second test all three participants could decide whether a result suited them; the interpretation of group size, however, remained open."
This is a short design story: situation, evidence, decision, result, and limitation. The design rationale is the "because" part of it: the unified card was placed at the top of the list because participants missed the data needed for the decision, and the map view was based on an assumption.
Common misconceptions
Claim
Clarification
"If I show every screen, I am thorough."
Thoroughness is visible in the justification of decisions, not in the number of screens.
"Do not show the failure."
A rejected alternative or an open question makes the story more credible.
"A design story is an invented tale."
On the contrary: every claim of it is tied to evidence.
In brief
A design story is the coherent presentation of problem, evidence, decision, and result; the rationale is its "because".
The chain: observation → insight → decision → result; there should be no logical jump.
Show only the main thread; details that did not change a decision can go to the appendix.
Word things in proportion to the strength of the evidence.
Review questions
What is the one-sentence main claim of your project?
What evidence supports your most important decision?
Where is there a logical jump in your current presentation?
Which screen can you leave out because it does not explain a decision?
Design story and evidence
Objectives
By the end of the lesson, you can present the project not as a list of screens but as a checkable design story. You can tell the claim, the evidence, the decision, and the result apart, and you know why it is important to word things in proportion to the strength of the evidence.
Why is it not enough to show the screens?
At the end of the semester you have a finished prototype, and it is obvious to walk through it. But from the final result the audience cannot see what you know: the essence of design work is the thinking behind the decisions. If they see only the screens, it is as if a chef showed only the finished dish, not the recipe and the tastings. The design story makes visible why this solution, in the examined situation.
The structure of a design story
A design story is the coherent presentation of the problem, evidence, decision, and result. A design rationale is the short, evidence-backed explanation of why you chose exactly this layout, label, or interaction. The two belong together: the rationale is a "because" within the story.
The claim should be concrete. Instead of "users found it hard to find the cancellation", show in what task, with how many examined participants, in what behavior this appeared. The evidence can be a quote, an observation, a user flow, a before–after screen, or a test finding. A single strong, relevant piece of evidence is worth more than many decorative screenshots.
Evidence, decision, result
Do not leave a logical jump. If a new feature follows directly from a research quote, explain the interpretation. The four links of the chain:
This chain makes the presentation professionally traceable.
Do not claim more than the evidence allows. From a small test, speak about "the participants examined", not "all users". If a change has not yet been tested, call it a hypothesis, not a result.
What is worth showing?
An artifact is a tangible document or output of the design process. Choose artifacts that explain a decision:
You do not need to project the whole workflow. A screen is useful if it shows which problem it answers, and what shows that the answer works or is still uncertain.
Condensing a long project
A semester's work consists of many threads; only the main thread goes into the presentation. Filter questions:
What you leave out can go into an appendix.
flowchart TD A["Problem and context"] --> B["Research evidence"] B --> C["Design decision"] C --> D["Prototype and test"] D --> E["Result and limitations"] E --> F["Next step"]Worked example: the story of Mai program
"In the research, participants could not compare the basic data of events, so they opened extra tabs. On the cards we displayed the time, price, place, and registration requirement together. In the second test all three participants could decide whether a result suited them; the interpretation of group size, however, remained open."
This is a short design story: situation, evidence, decision, result, and limitation. The design rationale is the "because" part of it: the unified card was placed at the top of the list because participants missed the data needed for the decision, and the map view was based on an assumption.
Common misconceptions
In brief
Review questions