Debriefing

When a client, teacher, or stakeholder presents you with a project brief or challenge, it's rarely clear from the start what exactly needs to be made, tested, or explored. As a creative technologist, your job is not to jump straight into building mode. First, you need to understand what the core question is, what the expectations are, and how your process might address them.

A debrief helps you unpack the original question, clarify the scope, and identify which parts are fixed, which are open, and where you need to investigate further. This makes your process smarter, your solutions more relevant, and your team more aligned.

Starting Point

• Ask yourself: What is this challenge really about? Is the client looking for a prototype, a test, a new perspective, or a functional product?
• Break the initial brief into parts: Who is the user or system? What is the context or environment? Are there technical constraints? What kind of output is expected?
• Use tools like the 5 Whys technique to find out what's behind the request.
• Rewrite the original brief in your own words and list any uncertainties, assumptions, or dependencies.

Key Points

• A good debrief is exploratory and collaborative. Talk to the stakeholder and check if your interpretation of the challenge matches their intent.
• Clarify vague terms. If someone says “It should be user-friendly,” ask “What does that mean in your context?” or “Can you show an example?”
• Reframe the brief into a working challenge that fits your process. For example: “How can we prototype a system that helps people navigate a space without a screen?”
• Identify what you still need to know: user behavior, technical feasibility, ethical constraints, etc.
• Your debrief should result in a clear working brief — a statement of what you are trying to explore, build, or test, for whom, and under what conditions.