DP Design Tech
IA Guide

A practical reference for the 50-hour design technology internal assessment project. Up to 40% of your final grade.

Use this guide alongside your teacher's advice and the official IB documentation.

The Internal Assessment is a 50-hour design project. You identify a real user's problem with an existing product, research the context, generate and test ideas, and present a redesigned solution. It is worth 40% of your final DP grade.

The Five Criteria

CriterionNameMarksWhat You Show
AEmpathize9Research into the user, task, and existing products
BDefine6A precise problem statement and testable specification
CIdeation6Three distinct design ideas, evaluated against the spec
DDesign6Iterative prototypes and formal technical drawings
EPresent6Final solution compared directly to the original product
Total33Digital portfolio, max 35 A4 pages

Key Rules

📄
Maximum 35 A4 pages. The examiner stops reading after page 35.
✏️
Annotations 10 words max each. Longer annotations count toward the word limit.
🔢
Maximum 3,500 words total body text (annotations under 10 words excluded).
🚫
No appendices. Include everything in the main 35 pages.
🔁
You must redesign an existing product. Do not invent a new one.
👤
The redesign must address the needs of a real, named user you have observed and interviewed.
✍️
Handwritten annotations must be legible, equivalent to Arial 11pt.
📚
Use subject-specific vocabulary: ergonomics, anthropometrics, biomechanics, percentiles.
Critical Rule — Redesign, Do Not Invent

You must redesign a product that already exists. The IB exemplar "FPV Drone Racing Tool" (Example 5) lost marks because the student tried to create a new multi-tool rather than redesigning the tool bag that was the actual identified problem. Start with an existing product — your job is to improve it for your user.

Page Budget

CriterionRecommended PagesContent Breakdown
A — Empathize~9Persona (2), Storyboard (3), Product Analysis (4)
B — Define~4Problem Statement (1), Specification (3)
C — Ideation~8Three ideas (6), Evaluation Matrix (2)
D — Design~10Iteration log (6), Technical Drawings (4)
E — Present~4Final Solution (2), Comparison (2)
Total~35Do not exceed this limit

Mr. K's Notes

Notes from Mr. K will appear here.

This is the foundation. You research a real user, analyze the specific task where the product fails, and evaluate existing products. Everything in later criteria connects back to what you find here.

Three Strands

1 Primary Persona ~2 pages

A detailed profile of your real user, based on observation and interview, including human factors data.

2 Storyboard ~3 pages

Step-by-step visual breakdown of the specific task where the existing product fails your user.

3 Product Analysis ~4 pages

Critical evaluation of 4–6 existing products using formal design principles and human factors.

Mark Scheme

BandWhat This Looks Like
1–3Basic research with limited connection to the user or the existing product.
4–6Research identifies a problem but lacks depth in human factors or critical product analysis.
7–9Thorough, user-centred research across all three strands. Human factors used. Product analysis is critical and specific. All findings connect to the user's problem.

The persona is a profile of one real person — not an imaginary character. You should observe and interview this person while they use the existing product. Photographs of them using the product are expected.

Include: who the person is, what they want to achieve, what specifically frustrates them about the existing product, and the physical and environmental context of use. Include anthropometric data (measurements, percentile ranges) and ergonomic considerations.

Persona Outline — Copy This Structure

[NAME OF PERSONA]
- Photographs of the person using the existing product
- Age:
- Occupation:
- Location:
- Relevant physical characteristics or limitations:

GOALS
- [What does this person want to achieve?]
- [Be specific to the task your product addresses]

FRUSTRATIONS
- [What specifically limits them about the existing product?]
- [Use direct quotes from your interview]

MOTIVATIONS
- [Why do they care about solving this problem?]

CONTEXT OF USE
- [Where, when, and how often do they use the product?]
- [What is their environment like?]

HUMAN FACTORS
- Relevant anthropometric data (hand dimensions, percentile range)
- Relevant biomechanical considerations (grip force, reach range)
- Ergonomic requirements (posture, repetitive strain risk)
What Success Looks Like

The Prosthetics project scored 8/9 on Criterion A. The persona interview revealed a specific, measurable goal: "The hand can move like it did before 80–90%." This gave the student a clear target to test against in later criteria.

Common Problems
  • The persona is fictional or based on a stereotype rather than a real, interviewed person.
  • Frustrations are vague ("it is uncomfortable") rather than specific to a moment of product use.
  • No connection between the persona's frustrations and the design of the existing product.
  • No photographs of the real user with the real product.
  • Human factors (anthropometrics, biomechanics) are completely absent.

The storyboard is a step-by-step visual analysis of one specific task where the existing product fails. Each frame shows one step in the task sequence. This is not a general story about the user's day — it is a close analysis of one moment of failure. Annotations must explain what is happening and why it is a problem.

Storyboard Frame Structure — Copy This

STORYBOARD: [Name of Task]
Persona: [Name from your persona]
Existing Product: [Product name]

FRAME 1: [Step title]
- Visual: [What is shown — photograph or drawing]
- Annotation: [What happens and why it is a problem]

FRAME 2: [Step title]
- Visual: [What is shown]
- Annotation: [Key action or difficulty at this step]

FRAME 3: [Step title — the moment of failure]
- Visual: [Specific point where the product fails the user]
- Annotation: [What goes wrong and the consequence]

FRAME 4–6: [Continue the task sequence]

CONCLUSION FRAME:
- What the user cannot do, or what takes too long / causes pain
- Connection to: which design specification points this will generate
What Success Looks Like

The Prosthetics project storyboard focused narrowly on one failing task: braking a bicycle. Each frame showed one specific moment. The examiner understood the precise problem immediately.

Common Problems
  • The storyboard shows a general lifestyle rather than analyzing one specific task step-by-step.
  • The Math Play Set project scored only 4/9 because its storyboard showed general difficulties of refugee life, not a detailed task analysis of the maths education problem.
  • Frames show what the user does without explaining why each step is a problem.
  • Photographs without analytical annotations — annotations are required.

Analyze 4–6 existing products. Include the product your persona uses, plus competing products. Be critical — find both strengths and weaknesses. Use formal design terminology: function, aesthetics, ergonomics, materials, sustainability, safety, inclusivity, anthropometrics.

Product Analysis Template — Copy This

PRODUCT ANALYSIS — Product [#]
Product name:
Manufacturer:
[Annotated photograph]

FUNCTION
- Primary function:
- How well does it achieve this for your persona?

ERGONOMICS & ANTHROPOMETRICS
- How does the design relate to the user's body?
- Relevant percentile data:
- Required postures or movements — comfortable?

MATERIALS
- Primary materials and rationale:
- Durability, weight, safety:

AESTHETICS
- Visual language, colour, finish:
- Appropriate for the user and context?

SUSTAINABILITY
- Manufacturing process considerations:
- Lifespan and end-of-life:

STRENGTHS (for your persona)
-
-

WEAKNESSES (for your persona)
-
-

WHAT THIS MEANS FOR YOUR DESIGN
- Feature to keep or improve:
- Problem this product fails to solve:
What Success Looks Like

Strong product analysis connects each product's weakness directly to the user's frustrations from the persona. Each product teaches you something that will appear in your design specification.

Common Problems
  • Analyzing only 3 products — the guide recommends 4–6.
  • Analysis that only describes products without evaluating them critically.
  • No connection between the products analyzed and the persona's specific needs.
  • Human factors (anthropometrics, biomechanics, percentile data) are missing.
  • Only the product the persona uses is analyzed — competing products must be included too.

Criterion B converts your research into a precise, testable plan. It has two parts: a focused problem statement, and a design specification where every requirement is justified by evidence from Criterion A.

Two Strands

1 Problem Statement ~1 page

A concise, specific description focused on one user and one product.

2 Design Specification ~3 pages

A table of specific, measurable requirements, each justified by evidence from Criterion A.

Mark Scheme

BandWhat This Looks Like
1–2A problem statement exists but is vague. Specifications are general wishes, not testable requirements.
3–4A reasonable problem statement. Most specification points are reasonable but some lack justification or measurable targets.
5–6A precise problem statement. Every specification point is measurable and fully justified by evidence from Criterion A. The specification is clearly a test plan for the solution.

The problem statement is a focused paragraph. It names your user, names the existing product, and states the specific problem that prevents the user from achieving their goal. It should not describe a global issue or a general category of problems.

Problem Statement Template — Copy This

[Persona name], a [describe user in one phrase], currently uses [name of existing product] to [describe the task].

However, [existing product] fails to [specific limitation], which means that [persona name] cannot [specific goal from persona] without [specific difficulty or consequence].

This project will redesign [existing product] to address [specific problem], so that [persona name] can [specific user goal from persona].

The redesigned product must meet the design specification that follows.
Common Problems
  • The problem statement describes a large social issue rather than focusing on one user and one product.
  • The existing product is not named.
  • The statement introduces the solution before the specification has been written.

Each specification point must be specific (not vague), measurable (testable later), and justified (traced to evidence from Criterion A).

Critical Insight — Trowel Project Commentary

The IB Trowel project commentary specifically criticized specifications that referenced "boarding houses and aesthetics" without evidence from Criterion A. Every specification point must trace back to something you found in your research. If you cannot find a source in Criterion A for a specification point, remove it.

Design Specification Table — Copy This

DESIGN SPECIFICATION

# | Requirement | Justification | Source (Criterion A) | Priority
--|-------------|---------------|----------------------|----------
1 | [What the product must do or be. Include measurable targets.] | [Why is this needed? What did your research show?] | [Persona / Storyboard / Product analysis] | Essential
2 | [e.g., Handle diameter 32–38mm to suit 5th–95th percentile female hand width.] | [Persona interview: grip fatigue reported. Product analysis: handle is 28mm — below 5th percentile.] | Persona + Product 1 | Essential
3 | [e.g., Product must be operated with one hand only.] | [Storyboard frame 3 showed user's other hand is occupied.] | Storyboard, Frame 3 | Essential
4 | [A desirable (not essential) feature] | [Supporting evidence] | [Source] | Desirable

"Essential" = design fails if not met.
"Desirable" = improves design but absence does not cause failure.
Common Problems
  • Specifications are a wish list ("it should be comfortable") with no measurable targets.
  • No column linking each specification to its source in Criterion A.
  • All specifications marked "Essential" when some are clearly preferences.
  • Specifications are not actually tested against in Criteria C or E.

Generate three genuinely different design directions, then evaluate all three against your specification using a structured matrix. The goal is to show you explored options before committing to one.

Two Strands

1 Three Design Ideas ~6 pages

Three distinct directions, each shown with annotated sketches or models.

2 Evaluation Matrix ~2 pages

Structured evaluation of all ideas against every specification point, with a clear final selection.

Mark Scheme

BandWhat This Looks Like
1–2Ideas are similar variations. Evaluation is personal opinion without reference to the specification.
3–4Three reasonably distinct ideas. Partial evaluation against the specification but not all points tested.
5–6Three genuinely distinct ideas. Structured matrix covers ALL ideas against EVERY specification point. Selected idea clearly identified and justified by evaluation evidence.

Each idea must be a genuinely different approach — different mechanism, material, configuration, or interaction method. Not just the same idea with a different colour or shape.

Idea Presentation Template — Copy This

DESIGN IDEA [#]: [Give the idea a descriptive name]

CONCEPT DESCRIPTION
- [2–3 sentences describing the design approach and how it differs from the others]

KEY FEATURES
- Feature 1: [Describe and annotate on your drawing]
- Feature 2: [Describe and annotate on your drawing]
- Feature 3: [Describe and annotate on your drawing]

HOW IT ADDRESSES THE PROBLEM
- [Link to a specific persona frustration or storyboard finding]

PROPOSED MATERIALS
- Primary material:
- Why this material:

INITIAL FEASIBILITY
- Can this be made within your project constraints?
- Any risks or difficulties?

[Annotated sketches, drawings, or photographs of a quick model]
Common Problems
  • Three ideas that are the same concept with minor differences.
  • Ideas that do not connect to the specification or persona frustrations.
  • Sketches without annotations — the ideas must be explained, not just shown.
  • Ideas that introduce completely new products unrelated to the original problem.
Key Insight — Prosthetics Project (6/6)

The Prosthetics project earned full marks in Criterion C by creating a complete evaluation matrix covering ALL three ideas against EVERY specification point, then stating clearly which idea was selected with specific justification from the matrix results — not personal preference.

Evaluation Matrix Template — Copy This

EVALUATION MATRIX
Key: ✓ = meets specification   ~ = partially meets   ✗ = does not meet

Spec # | Specification (abbreviated) | Idea 1 | Idea 2 | Idea 3
-------|-----------------------------|--------|--------|--------
1      | [e.g., One-hand operation]  |   ✓    |   ✓    |   ✗
2      | [e.g., Handle Ø 32–38mm]   |   ✓    |   ~    |   ✓
3      | [Spec point]                |        |        |
...    | [Continue for all spec points] |      |        |

TOTALS:  ✓__ ~__ ✗__    ✓__ ~__ ✗__    ✓__ ~__ ✗__

SELECTION
Selected idea: Idea [#] — [Name]
Justification: [Explain using the matrix results. Why does this idea best satisfy the most important specification points? Did you consult your user in this decision?]
Common Problems
  • Evaluation based on personal opinion ("I prefer Idea 2") rather than the specification.
  • Matrix does not include all specification points.
  • No clear conclusion identifying which idea was selected.
  • The selected idea contradicts the matrix results.
  • No evidence the user was consulted during evaluation.

Criterion D is about showing your development process. You document multiple models or prototypes, show what each test revealed, and demonstrate how you changed the design in response. Then you produce formal technical drawings.

Two Strands

1 Iterative Models ~6 pages

Multiple prototypes at increasing fidelity, each tested, results documented, changes made.

2 Technical Drawings ~4 pages

Formal orthographic, assembled, and exploded views with dimensions and Bill of Materials.

Mark Scheme

BandWhat This Looks Like
1–2One prototype shown, or models without testing evidence. Technical drawings missing or incomplete.
3–4Some iteration evident. Testing documented but changes between prototypes not clearly explained. Technical drawings partially complete.
5–6Clear model–test–refine cycle across multiple prototypes. Each test result directly drives the next change. Testing involves the user. Technical drawings complete: orthographic, assembled, exploded, dimensions, Bill of Materials.
Key Insight — Prosthetics Project

The Prosthetics project documented each prototype in a structured table: Prototype → Testing Result → How to Improve. This format makes iteration evidence clear and easy to follow.

Iteration Log Template — Copy This

ITERATIVE DEVELOPMENT LOG

PROTOTYPE 1 — [Name, e.g., "Low-fidelity foam model"]
- Material/method:
- Specification points tested:
- Testing method: [How tested? With the user? With measurements?]
- Result: [Be specific. Measurements or user quotes.]
- Decision for next prototype: [What will you change and why?]
- [Photograph of the model]

PROTOTYPE 2 — [Name, e.g., "Revised grip — 3D printed"]
- Material/method:
- Specification points tested:
- Testing method:
- Result:
- Decision for next prototype:
- [Photograph]

PROTOTYPE 3 — [Final pre-production model]
- Material/method:
- Specification points tested:
- Result:
- Final decision: [Is the design ready? Any remaining refinements?]
- [Photograph]
Common Problems
  • One polished prototype with no evidence of earlier, rougher models.
  • Models shown but no testing results or changes documented.
  • Development that does not address the original specification.
  • No involvement of the real user in testing.
  • Changes between prototypes not explained — showing two different models is not enough.

Technical drawings must be formal — use instruments or CAD. Sketches are not acceptable here. You need:

  • Orthographic projection — Front, side, and top views with full dimensions
  • Assembled view — The complete product
  • Exploded view — All components separated, labeled, with part numbers
  • Section view (if applicable) — For internal features

Bill of Materials Template — Copy This

BILL OF MATERIALS

Part # | Part Name | Material | Qty | Dimensions | Process | Notes
-------|-----------|----------|-----|------------|---------|------
1      | [Name]    | [Material]| 1   | [L×W×H]   | [e.g., FDM print] | [Source/cost]
2      | [Name]    | [Material]| [Qty]| [Size]   | [Process] | [Notes]
3      | [Name]    | [Material]| [Qty]| [Size]   | [Process] | [Notes]
...
Common Problems
  • Drawings without dimensions.
  • Only a perspective render — no orthographic views.
  • No exploded view showing component relationships.
  • Bill of Materials missing or lists parts not shown in drawings.
  • Drawings show a different design from the one developed in the iteration stage.

The final section. Present your completed redesign with annotated key features, then compare it directly to the original product from Criterion A. The examiner wants to see clear evidence that your redesign solves the problems your research identified.

Two Strands

1 Final Solution ~2 pages

High-quality visuals with annotation callouts identifying key features and design decisions.

2 Comparison ~2 pages

Direct before-and-after comparison using photographs, feature tables, and user testing evidence.

Mark Scheme

BandWhat This Looks Like
1–2Final design shown but not annotated. No direct comparison with the original product.
3–4Annotated final design. Some comparison with the original, but not structured or evidence-based.
5–6Clearly annotated final design. Direct side-by-side comparison with the original product using photographs, a specification compliance table, and user testing evidence.

Use high-quality photographs of the final physical model (or renders). Each key feature must be annotated. Annotations explain what the feature does and which specification point it satisfies. Keep annotations to 10 words or fewer.

Final Design Annotation Structure — Copy This

FINAL DESIGN — [Product Name]

[Photograph or render — multiple angles]

ANNOTATION CALLOUTS (10 words max each)
A → [Feature name]: What it does / spec point
B → [Feature name]: What it does / spec point
C → [Feature name]: What it does / spec point
D → [Material]: Material used and reason
E → [Dimension]: Key measurement

KEY DESIGN DECISIONS
[These longer explanations count toward your word limit]

Decision 1: [Feature]
- Why: [Link to persona frustration or spec point]
- Development: [Reference prototype from Criterion D]

Decision 2: [Feature]
- Why:
- Development:

USER RESPONSE
- [Persona name]'s feedback when testing the final model:
- [Direct quote if available]
Common Problems
  • Beautiful renders with no annotation callouts — visuals alone do not earn marks.
  • Annotations that name a feature without connecting it to a specification point.
  • New features or materials introduced here that were not tested in Criterion D.
Key Insight — Trowel and Prosthetics Commentaries

Both commentaries note that comparing the redesigned product directly to the original product from Criterion A is essential. Use side-by-side photographs, a feature comparison table, and user testing evidence. Do not just describe your design — show how it improves on what came before.

Comparison Template — Copy This

BEFORE AND AFTER COMPARISON

[Side-by-side photograph: Original product | Redesigned product]

FEATURE COMPARISON TABLE

Feature | Original Product | Redesigned Product | Improvement?
--------|-----------------|-------------------|-------------
[Spec 1] | [Original status] | [New status] | ✓ / ✗ / ~
[Spec 2] | [Original status] | [New status] | ✓ / ✗ / ~
[Bold comparison showing clear difference] | | | ✓

USER TESTING COMPARISON
- [Persona name] tested both products on the same task (from storyboard)
- Original product result: [Time? Pain? Goal achieved?]
- Redesigned product result: [How did it compare?]
- User quote: "[Direct feedback]"

SPECIFICATION COMPLIANCE SUMMARY
Spec # | Requirement | Met? | Evidence
-------|-------------|------|--------
1      | [Spec point] | ✓    | [Test result]
2      | [Spec point] | ~    | [Partial — explain]
3      | [Spec point] | ✗    | [Not met — what would you change?]
Common Problems
  • No direct comparison with the original product from Criterion A — the most common mistake.
  • Comparison is written text only with no visual side-by-side evidence.
  • No user testing results.
  • Specification compliance not addressed.
  • Failing to acknowledge specification points that were not fully met — honest evaluation is expected.

Useful links, references, and resources to support your IA. This section is updated over time — check back regularly.

Useful Links

Notes from Mr. K

This space is for additional guidance that does not fit neatly into one criterion — common questions, exam session reminders, or clarifications on the guide above.

More content coming. If you have a question that should be answered here, ask in class.

Presenting Three Ideas — Example

Example student work — three distinct ideas

In the image above, three ideas are shown: a folding mechanism, a modular clip system, and a strap-mounted variant. Each is presented on its own page with annotated sketches and a short written description explaining the concept and how it differs from the others.

Notice that each idea addresses the same specification points in a genuinely different way — not just a cosmetic variation on one concept.

Evaluation Matrix — Example

Below is a sample filled-in evaluation matrix. Every specification point is tested. All three ideas are scored. The conclusion names the selected idea and explains the choice using the matrix results.

# Specification Point Idea 1
Folded grip
Idea 2
Strap mount
Idea 3
Modular sleeve
1 One-hand operation
2 Handle Ø 32–38mm ~
3 Washable materials ~
4 Under 150g total
5 Tool-free adjustment
Totals ✓3 ~1 ✗1 ✓3 ~1 ✗1 ✓4 ~0 ✗1

Selected: Idea 3 — Modular sleeve. It met 4 of 5 essential specification points and was preferred by the user during consultation, who found the modular approach most practical for her context of use.

Iterative Models — Example

Prototype 1 — low-fidelity foam model
Prototype 2 — revised grip, 3D printed

Each prototype is shown alongside a brief table documenting: what was tested, the result, and the decision made before the next model. This structure makes the test–refine cycle visible to the examiner.

PrototypeSpec testedResultNext change
1 — Foam #2 Handle Ø 35mm — user confirmed comfortable Test grip material
2 — 3D print #1, #4 One-hand ✓. Weight 162g — over limit Hollow body to reduce weight
3 — Final All 141g ✓. All essential spec points met Ready for technical drawings

Technical Drawings — Example

Orthographic projection — front, side, top views with dimensions
Assembled view — complete product
Exploded view — components numbered, Bill of Materials alongside

Every drawing must include dimensions. The exploded view should match the part numbers in the Bill of Materials table that follows the drawings.

Comparison — Example

Side-by-side photograph — original product (left) and redesign (right)

Below is a sample specification compliance table. Note that one point is marked as not fully met — honest evaluation is expected and will not be penalized if acknowledged clearly.

#RequirementOriginalRedesignMet?
1 One-hand operation
2 Handle Ø 32–38mm ✗ (28mm) ✓ (35mm)
3 Under 150g ✓ (141g)
4 Washable materials ~ (body only) ~

Spec 4 was partially met. The body is washable but the internal spring mechanism is not. In a further iteration, a sealed waterproof cap would address this.