🪶 Design boundary. Ākonga may design the process — evidence, stakeholders, consent, safeguards, governance, and accountability — but they may not invent tikanga or speak for Māori communities. Ground the challenge in a named, public source from the affected mana whenua, iwi, hapū, or Māori-led organisation. A classroom concept must not be presented as culturally responsive until the people with authority have shaped and approved it. Do not ask Māori or Indigenous learners to supply or validate the cultural position.
Inquiry & Design Studio · Lesson 4
Studio checkpoint: prototype and seek critique
Teams prototype the design brief created in Lesson 3, then conduct a critique with explicit checks for source scope, community authority, data governance, accessibility, and stop conditions. Feedback must change at least one design decision.
Scaffold: Prototype storyboard and critique protocol
Studio output: Annotated prototype plus a design-change log
Use a named source to identify a documented technology need or governance requirement
Separate source evidence, design inference, uncertainty, and decisions held by others
Design a bounded prototype without claiming that it represents a community
Evaluate proposals through consent, provenance, benefit, access, accountability, and stop conditions
📚 Key Concepts
Source scope: The people, project, place, and purpose a source can truthfully represent
Co-design: Affected people sharing real decision-making power, not merely being consulted after design
Data governance: The permissions, roles, controls, and accountability governing data across its life cycle
Stop condition: A clear point at which missing evidence, consent, safety, or authority halts the proposal
🚀 Lesson Structure
Part 1: Source Check - 10 minutes
Opening rule: A project’s own published account can establish its stated purpose and governance approach; it cannot stand for every Māori or Indigenous community.
Activator: Read or preview one primary-source account:
Te Hiku Media — Papa Reo: A Māori-led language-technology project developing speech-recognition and natural-language-processing capability beginning with te reo Māori. Papa Reo states that smaller Indigenous language communities should retain sovereignty over their data and receive the benefits produced from it. Under Te Hiku Media’s Kaitiakitanga Licence, data is cared for rather than owned, and decisions about its use must respect the people from whom it comes. Read Papa Reo’s own account.
Discussion: According to Papa Reo’s own account, who governs the project and its data, who should receive the benefit, and what limits are stated? Cite the source; do not infer a generic Indigenous model.
Part 2: Source and Authority Design Framework - 15 minutes
Kaiako preparation: Provide a named, public Māori-led source that states the affected community or project’s own design requirements. The source’s scope must remain visible; it does not stand for all Māori.
Authority and design questions:
Who names the need and intended benefit?
Who has authority over the relevant data, knowledge, and decisions?
What consent is required, and how can it be withdrawn?
What must not be collected, digitised, or shared?
How will the affected people govern, test, change, or stop the technology?
Discussion Questions:
Which requirement is stated directly by the supplied source?
Which proposed feature would still require evidence, co-design, or approval?
Part 3: Evidence Extraction - 15 minutes
Group task: Extract one documented need or governance requirement from the supplied source. Do not brainstorm deficits for a community.
Evidence questions:
What exact words in the source identify the need or intended benefit?
Whose perspective does the source carry, and whose perspective is absent?
What data, language, or knowledge would the concept involve?
Who may approve, change, challenge, or stop the proposal?
What claim remains unverified?
Part 4: Design Sprint - 25 minutes
Group Design Challenge: Using a need explicitly identified in the supplied source, students work in groups to design an authority-aware concept. They must distinguish features they can propose from cultural or governance decisions that require community co-design and approval.
Design Prototype Components:
Problem Statement: What specific problem are we solving? Who is affected?
Source Requirements: Which requirement comes directly from the named source?
User Experience: How will people actually use this? (Sketch interface/flow)
Data & Privacy: What data is collected? Who controls it? How is it protected?
Intended Benefit: What benefit does the source identify, for whom, and within what scope?
Sustainability: How is this maintained and governed over time?
Deliverable: Simple prototype sketch (paper or digital) + brief explanation of design rationale
Part 5: Pitch Presentations - 15 minutes
Activity: Each group presents their design prototype (3 minutes per group)
Feedback Protocol: Using the source-and-authority framework, students evaluate each presentation:
Evidence: Which design requirement is genuinely supported by the named source?
Boundary: What assumption, permission, or perspective is missing?
Revision: What should change now, and what must wait for co-design or approval?
Part 6: Whakamutunga (Closing) - 10 minutes
Reflection: Students complete individual reflection:
What changed when I separated source evidence from my own design assumptions?
How has this changed how I think about the apps/tools I use daily?
Which part of the concept may be prototyped now, and which part must remain with the relevant authority?
Exit check: one sourced requirement, one explicit uncertainty, one named decision-holder.
🎬 Media Anchor
Use this general inclusive-design clip to identify one design method; do not treat it as a source for Māori or Indigenous governance.
Video anchor: inclusive design principles
Pause and discuss: Which general inclusive-design method does the clip demonstrate?
Transfer task: Update the prototype with that method, then keep all source-specific governance requirements attached to the relevant project source.
📊 Assessment
Formative: Observation of source use, scope control, and authority-aware design decisions
Source and authority: Uses a named source accurately, keeps within its scope, and identifies the people who must co-design or approve the next stage
Problem/Solution Fit: Responds to a need established by the named source without enlarging its scope
User Experience: Thoughtful consideration of how people will actually use this
Data Ethics: Clear protocols for consent, access, care, correction, withdrawal, and accountability
Next decision: Identifies what requires co-design, approval, or a stop condition
🎓 Teacher Notes
Preparation:
Prepare the named primary source and verify every project claim against it
Prepare design template handouts or digital files
Set up space for group work (tables, whiteboards, materials)
Differentiation:
Support: Provide more structured template with prompts for each section
Extension: Students create functional prototype using no-code tools (Figma, Bubble.io)
Digital Literacy: Pair confident designers with those less familiar with tech terminology
Cultural Considerations:
Offer leadership roles by choice and do not position Māori or Indigenous students as the group’s cultural authority
Do not ask learners to identify community needs from personal identity or presumed cultural knowledge
Use only public material; restricted knowledge and unapproved cultural content stay out of digital tools
Extension/Homework:
Students annotate one public project source: one documented need, one stated governance requirement, one uncertainty, and one decision that remains with the project or community.
💬 Whānau Connection
Students may share their evidence map with whānau and ask: “Which claim is supported, which is still an assumption, and whose permission would be needed before this idea went further?” Sharing is optional and does not seek cultural validation.