IDEA9106 Chap.2 Design Thinking as an Iterative Practice

Design Thinking as an Iterative Practice

Design Thinking as an Iterative Practice frames a decision through divergence and convergence, iteration and problem-solution coevolution.

The objective is to plan a cycle that learns before it commits to a solution, so the chapter should be read as a chain from problem definition to evidence, option comparison and accountable action.

Start with divergence and convergence and name the decision owner, affected stakeholders and time horizon.

The same fact can matter differently across those positions, so the opening frame determines which evidence is relevant.

Use iteration to explain how the present condition produces an opportunity, cost or risk. A strong mechanism states what changes, for whom and through which organisational, market or institutional process.

Apply problem-solution coevolution when comparing options.

Keep criteria distinct, test trade-offs and ask which assumption drives the recommendation. A score or matrix only helps when its criteria are justified by the case.

For the application — plan a cycle that learns before it commits to a solution — finish with an actor, action, rationale and review trigger.

This turns analysis into a recommendation while keeping the decision open to new evidence.

Build a decision ledger for Design Thinking as an Iterative Practice. Separate the current condition, the stakeholder affected, the evidence supporting divergence and convergence, the mechanism represented by iteration and the criterion supplied by problem-solution coevolution.

If a recommendation cannot point back to one of those entries, it is probably preference dressed as analysis rather than a consequence of the case.

Compare at least two feasible options against the same criteria. State who benefits, who bears cost or risk, what capability implementation requires and what evidence would reveal failure.

This comparison is essential when students need to plan a cycle that learns before it commits to a solution, because an attractive option is not yet a defensible choice until its trade-offs are made visible.

Rehearse the IDEA9106 response as a short briefing: one sentence for the decision, two for the evidence and mechanism, one for the alternative and one for the qualified recommendation.

Then expand only the move that needs more support.

This protects the argument structure when a report, presentation or timed case imposes a strict word or time limit.

A complete Design Thinking as an Iterative Practice response should make the task visible before the detail: identify what must be decided, define the relevant terms, connect the evidence to iteration, and use problem-solution coevolution to test the result.

The final sentence should answer the question actually asked rather than merely repeat the topic.

The controlling limit is specific: A named process diagram is not evidence that a team investigated the problem.

Keep that limit beside the worked example, because it separates a careful IDEA9106 answer from one that sounds confident but claims more than the task or evidence supports.

For revision, retrieve divergence and convergence, iteration and problem-solution coevolution without notes, explain their relationship aloud, then complete a changed version of the application: plan a cycle that learns before it commits to a solution.

Record the first point at which your reasoning fails and repair that move before attempting another case.

What this chapter covers

• 01

  divergence and convergence

• 02

  iteration

• 03

  problem-solution coevolution

• 04

  Applying divergence and convergence

• 05

  Limits of iteration and problem-solution coevolution

Worked example: Design Thinking as an Iterative Practice

Key terms

reframing / reframe the problem space / reframed project brief

Reframing changes the assumptions, boundaries or point of view used to define a problem, producing a revised brief that opens different design possibilities. In this chapter, use the concept when you plan a cycle that learns before it commits to a solution.

double diamond and the reframed double diamond (discover, define, develop, deliver)

The Double Diamond is a design-process model that alternates divergent and convergent work across Discover, Define, Develop and Deliver; reframed versions make iteration and repeated problem framing explicit. In this chapter, use the concept when you plan a cycle that learns before it commits to a solution.

wicked problems vs tame problems

A tame problem has a stable formulation and evaluable solution, whereas a wicked problem is contested, interconnected and changed by attempts to address it. In this chapter, use the concept when you plan a cycle that learns before it commits to a solution.

Design Thinking as an Iterative Practice FAQ

Assessment move

Reconstruct the relationship among divergence and convergence, iteration and problem-solution coevolution; complete the chapter application without notes; then test the result against this limit: A named process diagram is not evidence that a team investigated the problem.

Working through Design Thinking as an Iterative Practice in IDEA9106? Sia is AskSia’s AI Management tutor — ask any IDEA9106 Design Thinking as an Iterative Practice question and get a clear, step-by-step explanation grounded in how IDEA9106 is taught and assessed. Read this chapter free, then take your hardest questions to Sia.