Learning by doing in design and technology: from the initial idea to a solution you can defend

Learning by doing does not mean replacing theory with projects. In Design and Technology, it means turning an idea into something that can be observed and tested, gathering information about its shortcomings, revising decisions and explaining why changes have been made. Learning takes place within this cycle of action, evidence, feedback and iteration, not solely in the final outcome.

The project you see is only the latest version

At the opening of an academic exhibition, in a digital portfolio or during a public presentation, the scene is usually impeccable. A final file is presented: FINAL_PROJECT_v7.pdf. Surrounding it are carefully lit images, a high-resolution photorealistic render, polished interfaces on mock-ups of state-of-the-art devices, a thirty-second animation, or a garment that has been cut and finished without any visible creases.

To the outside observer, the work seems to consist of having a good idea and executing it with technical skill. However, that final file conceals the bulk of the design education. It does not show the folder that precedes it, where a wide variety of records are accumulated:

• 01_discarded_sketch
• 03_volume_test
• 04_cannot_support_load
• 05_scale_correction
• 06_tutor’s_feedback
• 07_mechanism_change
• 08_second_test

Whoever designed that piece failed to exercise judgement when clicking the ‘export’ button for the final version. Their judgement was forged in the space between files: when a decision that seemed logical in their mind failed in practice, when an assumption was disproved by a test, and when it became necessary to work out why the intended solution didn’t hold up.

The result shows what you achieved. The earlier versions explain what you learnt. Understanding this difference is an essential step for anyone considering what to study if they are interested in design and technology, as training in these disciplines is not about accumulating self-contained exercises, but about sustaining a constant process of informed decision-making.

Learning by doing is not about producing more projects

The concept of ‘learning by doing’ or experiential learning is often subject to a misleading oversimplification: confusing continuous activity with effective learning. Producing many pieces does not guarantee a better understanding of a subject.

It is necessary to distinguish between three concepts that are often conflated:

1. Production: this involves carrying out a series of tasks or meeting specifications to deliver a commission by a set deadline.

2. Experience: describes the act of having gone through a practical situation, used software, attended a workshop or completed a piece of work.

3. Learning: this involves a deliberate change in understanding, technical judgement or the ability to solve future problems based on prior experience.

A student may spend a semester modelling ten different three-dimensional objects or laying out serial publications whilst, at the same time, systematically making the same structural errors, ignoring the hierarchy of reading, or mechanically resorting to the three compositions they have already mastered. When this happens, there is a high volume of activity, but their judgement has not shifted one millimetre. Activity alone does not generate judgement.

Similarly, we should do away with the false dichotomy between theory and practice. It is often said that theory remains in the classroom and that it is through projects that one learns what is relevant. This is a misdiagnosis:

• Theory helps us to anticipate: it provides mental models, physical or perceptual laws, syntax, historical precedents and the vocabulary to name problems before we come up against them.
• Practice compels us to test: it subjects concepts to constraints of material, context, time, scale and use, revealing gaps that the theory did not anticipate.
• Reflection connects the two: it is the analytical moment in which we examine the gap between what theory predicted and what practice yielded.

Learning by doing does not mean ignoring the theoretical foundations in order to start building aimlessly, but rather turning abstract hypotheses into tangible objects that can be subjected to scrutiny.

Four traces a project leaves behind when you have truly learnt

In rigorous methodologies such as project-based learning (PBL) or structured design processes, the journey does not follow a linear, immutable sequence where each phase is closed off forever. Project-based research progresses through dynamic back-and-forth movements:

observe ⇄ do ⇄ test ⇄ explain

An unexpected discovery whilst testing a prototype often forces you to revisit the initial context; a failed attempt to explain a proposal usually uncovers inconsistencies that require the model to be rebuilt. When this cycle generates genuine learning, it always leaves four recognisable traces throughout the process.

Something you observed changed the problem

Most projects start with an initial brief: a stated need, a simulation task or a poorly resolved problem in the environment. The first instinctive response is usually to imagine solutions straight away. Disciplinary learning begins precisely by restraining that impulse.

Observing with intention is not about compiling attractive images on a digital board or mindlessly accumulating visual references. Observing involves:

• Recording how people interact with a physical or digital system without intervening with explanations.
• Analysing the technical and thermal limitations of a material before selecting it.
• Measuring traffic flows in a real interior space and comparing them with the layout plan.
• Studying the historical precedents of a type of object to understand why previous solutions failed.

The question that reveals this first step is straightforward: what do you now know about the problem that you did not know before analysing it in depth? If the research does not change the formulation of the challenge, redefine the constraints or alter your design priorities, then it has not been useful research; it has merely been an aesthetic exercise in compilation.

You built something early enough to be able to make mistakes

Keeping an idea locked away in your mind allows you to maintain an illusion of absolute coherence. In the imagination, materials have no weight, users grasp the interface straight away, and the software never clashes with the hardware.

To make something is to force that idea to confront real constraints. And for that test to be instructive, the first prototype must be built early on and with a controlled level of fidelity. The aim is not a polished render or a production-ready piece. The aim is a rapid prototype that answers a specific question:

• A structural sketch or a wireframe model to check whether a form works in space.
• A toile made from cheap cotton twill to assess the drape and ease of a pattern before cutting the final fabric.
• An animatic based on static shots to gauge the narrative tempo of a sequence before animating frame by frame.
• An isolated code function to check whether the data architecture supports the intended interaction logic.

The purpose of the first artefact is never to impress the evaluator; its technical aim is to formulate a clear question and withstand the clash with reality without the cost of discarding it proving paralysing.

Some evidence contradicted an assumption

Doing things without subjecting them to scrutiny is not design: it is decorating or producing blindly. The third footprint is left when you subject your artefact to a test that you do not fully control.

Testing a proposal is not the same as showing a mock-up to three close friends and asking if they find it appealing. Opinions on taste are subjective, volatile and offer little value for design purposes. Testing involves setting up an experiment with observable variables:

• Subjecting a product structure to a specific physical load and recording at which millimetre a deformation occurs.
• Asking a user to complete a task on an interface without giving them any clues, and documenting on which screen they hesitate or stop.
• Printing a full-scale typographic proof and checking its legibility from a distance of three metres under grazing light.
• Carry out a fitting on a moving body to see whether the armhole or the inseam allow for natural movement.

The key question in this phase is: what did you think would happen, and what actually happened? The moment the evidence contradicts the initial assumption, unfounded intuition is dispelled and true iteration begins.

You can explain why the next version is different

Changing aspects of a design at random until it appears more visually balanced is not iteration; it is aimless trial and error. The fourth hallmark of learning manifests itself in the designer’s ability to reason.

Explaining a technical decision does not involve embellishing it with conceptual jargon or inventing a poetic narrative after the event to justify an accidental result. It involves being able to map out the chain of cause and effect that guides the modification:

• “I adjusted the centre of gravity because, in the first stability test, the base tipped over at a tilt of twelve degrees.”
• “I removed this branch in the flow because three out of four users tried to click on the non-clickable element.”
• “I restructured the cutting pattern because the original fabric exhibited lower tensile strength in the warp than anticipated.”

When a student cannot clearly explain why version 03 replaced version 02 and what empirical data necessitated that change, it is highly likely that they have not yet processed what that iteration was intended to teach them.

If a first version cannot fail, it probably cannot teach you very much either

One of the most common mistakes when starting out in creative and technological fields is to invest weeks of work in a finished model without first validating its fundamental premises. Hours are spent texturing a 3D model whose basic anatomy is flawed, or designing dozens of screens for an app whose navigation scheme is incomprehensible.

This is where the pedagogical principle of ‘appropriate fidelity’ comes into play: the complexity of an intermediate representation must be proportional to the question that needs answering.

Prototyping is not about creating a scaled-down, aesthetically pleasing model for a display case. Prototyping involves building a representation that is concrete enough to answer a question before fully committing to a solution.

The cheaper a decision is—in terms of time invested, material resources and emotional attachment—the sooner and more rigorously it can be put to the test. If an initial version is so costly or sophisticated that its creator does not dare to break it, discard it or start again from scratch at the first sign of evidence against it, that version ceases to function as a learning tool and becomes an obstacle.

Not all disciplines test their ideas in the same way

Active methodologies and reflective design share an underlying structure, but their empirical validation takes place in radically different ways depending on the rules governing each technical field. Testing varies because the consequences of failure are of different natures:

None of these disciplines validates its hypotheses through rhetorical armchair debates. In every case, a verifiable artefact is constructed to be subjected to the laws of its own environment: gravity, the human body, optical perception or computational capacity. In the transition from the first sketch to the actual prototype, it becomes clear that a screen-based representation conceals friction, play and weight that only physical matter brings to the surface.

Making a mistake teaches you nothing until you can interpret the error

There is a superficial trend that romanticises failure in creative processes. Clichés that encourage constant failure overlook a basic pedagogical reality: making a mistake, in and of itself, is merely an interruption to the planned course of action. A mistake does not lead to learning until the student develops the analytical capacity to interpret why it happened and what decision to make next.

In project-based learning, three very different types of error coexist:

1. Informative error: one that arises when testing a well-formulated hypothesis against an unknown limit. It provides technical data not found in the initial manuals and broadens the designer’s perspective.

2. Repeated error: one that occurs when there was already sufficient prior evidence or theoretical grounds to anticipate it, but these were not consulted or were ignored through negligence. It does not contribute new knowledge; it reveals a lack of method or rigour in the research.

3. Accidental error: a typographical error, an isolated rendering fault or an accidental breakage in the workshop due to carelessness. It contains no transferable disciplinary lesson.

The question that distinguishes a pointless setback from rigorous learning is always the same: what new information has the failure produced that you did not previously possess? If the answer is none, the error must be corrected without unnecessary celebration.

This is where the concept of iteration makes sense. Iterating does not mean duplicating a file and making random, superficial modifications in the hope that the whole will improve by chance. Iterating means producing a new version based on verified information that modifies a previous decision.

Version 1 + Empirical evidence + Technical judgement = Defensible Version 2

If this cycle is broken and the intermediate evidence is discarded, there can be no iteration, only a scattered series of disconnected attempts.

Before modifying your project, ask yourself just one question:

What specific evidence is forcing me to change this decision?

If you cannot point to an observable piece of data, a failed test or a real operational constraint, you are not iterating: you are improvising as you go along.

Useful feedback does not replace your decision

At a university of Design and Technology, project critique sessions and workshop feedback do not function as panels judging personal taste. The purpose of academic review is not to validate whether a proposal is ‘liked’ or ‘disliked’, but to assess the internal coherence of the decisions made by the student.

A rigorous feedback process is recognisable because the reviewers pose structured questions and highlight objective inconsistencies:

• They point out contradictions: “ You have defined a product for people with arthritis, but the opening mechanism requires a torque greater than twenty newtons.”
• They challenge the assumptions: “ You assume the user will read this introductory text, but in the screen tests everyone skips that section.”
• They demand evidence: “You claim that this assembly will withstand continuous outdoor use, but you have not carried out any tensile tests or checked the material’s fatigue resistance.”

The greatest danger for a student in training is to delegate their judgement to the person supervising the project. Anyone who hears a criticism and simply follows to the letter what they believe the tutor prefers, in order to avoid conflict, is shirking the learning process. The aim of formative feedback is never for someone else to make the design decisions for you, but to force you to refine the technical and analytical rigour with which you argue for and defend those decisions.

Explaining a project can also change the project

Traditionally, the presentation phase is seen as taking place at the end of the process, reduced to the role of a marketing pitch or an oral defence of the final submission. However, in project-based learning, the act of verbalising and structuring the reasons behind a proposal acts as a catalyst for internal verification.

When a designer sits in front of a blank panel and forces themselves to answer concisely:

• What specific problem they were trying to address.
• What technical, material or budgetary constraints did they work within?
• Which three alternatives did they rule out before settling on the current one, and for what reasons?
• What empirical data support their solution compared with existing models.

A revealing phenomenon often occurs: the process of articulating the argument exposes the project’s weaknesses. In the effort to put into logical words what until then had been merely a visual intuition or a functional model, the designer themselves detects logical contradictions that had previously gone unnoticed. If a technical decision cannot be defended on the basis of verifiable causes, effects and constraints, it is usually because it was not a well-founded design decision, but an arbitrary preference. Justifying a project is not merely about communicating a result; it is about subjecting one’s own judgement to a final stress test.

The Criterion Change Form

To make this reflective process visible and prevent learning from being lost in disorganised folders, there is a practical tool that allows us to record how a student’s judgement evolves when faced with a complex problem: the ‘change of criteria’ form.

This sheet is not a generic to-do list. It is a documentation tool that records the trajectory of a technical decision from its initial conception to its finalisation:

• Initial decision: what solution did you propose to implement at first?
• Underlying assumption: what did you take for granted, or what untested hypothesis underpinned that idea?
• Test carried out: through which physical artefact or functional test did you put that decision to the test?
• Evidence obtained: what objective data, measurements or observable behaviours did the test reveal?
• Change implemented: what dimensional, material, structural or logical modifications did you apply based on the data?
• Consolidated criterion: why does the new solution provide a technically better response to the project’s constraints?
• Open question: Which aspect of the problem remains unresolved and will require a new iteration?

Practical example: development of a desk lamp

To understand how this analysis tool works in a practical case, let us look at the log of a team designing an articulated light fitting for shared study environments:

• Initial decision: to incorporate a capacitive touch control panel integrated into the flat surface of the lamp’s base.
• Underlying assumption: it was taken for granted that the base is the surface most accessible to the hand and that a flat touch interface conveys visual cleanliness and functional modernity.
• Test carried out: A scale model was produced showing the spatial layout of the components, and five users were asked to perform a reading task and switch on the light whilst consulting documentation.
• Evidence obtained: the users did not look at the base; they instinctively ran their hand along the cable or touched the metal shade, searching for a physical switch without taking their eyes off the book. Two users accidentally covered the touch control when placing folders on the base.
• Change implemented: the capacitive interface on the base was removed and a mechanical rotary switch was integrated directly into the lamp head, with perceptible tactile resistance.
• Established principle: in a task requiring high visual concentration, controls must be recognisable and operable by haptic memory, without forcing the user to look away or encroach on the usable work surface.
• Open question: Does the torque of the new mechanical selector allow for smooth, one-handed operation without destabilising the angle of the articulated arm?

A project has two outcomes

Upon completion of any project submission, a student usually looks at the resulting object: the printed report, the deployed code, the finished model or the photographed collection. This is, without doubt, one result of their work. But from the perspective of experiential learning, it is the less important of the two.

Every practical exercise simultaneously produces two parallel outcomes:

COMPLETE PROJECT

1. The object produced (specific, transient, non-repeatable)

2. The transferable skill (method, analytical ability and judgement)

The first outcome is local and specific: a plywood chair, an interface for an urban mobility service or a rendering engine for an independent video game. That object will remain in a file or a digital portfolio. It is highly unlikely that the student will ever design exactly that same chair or that identical application again.

The second outcome is the disciplinary knowledge that takes root in the student’s mind:

• The ability to anticipate tolerances and clearances before sending a cut to a CNC machine.
• The agility to recognise when an initial hypothesis is not supported by the data and must be abandoned without frustration.
• The rigour to interpret demanding feedback without taking it as a personal rejection.
• The skill to build rapid validation models before committing the team’s time.

The project comes to an end. The judgement should remain. The object produced reflects what the student achieved in a specific term under given conditions. The judgement acquired is the only technical tool that will accompany them towards their next professional challenge.

What ‘learning by doing’ really means at UDIT

At UDIT, the concept of ‘learning by doing’ does not function as a promotional slogan open to interpretation, nor as an excuse to accumulate workshop hours without a conceptual direction. It forms part of a structured university learning method designed to demand of students the same methodological rigour they will encounter in design and advanced technology ecosystems.

Learning by doing in this context means working on challenges that impose complex constraints: technical specifications, the dynamics of multidisciplinary teamwork, material feasibility, fixed deadlines and direct contact with industrial and social realities. It means conducting in-depth research before proposing the first design, subjecting prototypes to tests where the material or code may well fail, and appearing periodically before lecturers and professional committees to defend every design decision based on evidence, rather than mere whims.

Your next project should help you develop better judgement

Choosing a discipline tells you what sort of problems you’ll be exploring. Understanding how learning takes place allows you to ask a second question: do I want to study in an environment where my ideas have to become decisions that I can test, review and defend? Explore UDIT’s projects and degree programmes and look not only at the results, but also at the process behind them.