TL;DR
- Context: I first saw the Data Thinking method at a conference, then traveled to Berlin for the full training with its creator.
- Problem: SWPS students had a weekend UX hackathon coming up and knew Design Thinking, but had no framework for thinking about data.
- What I did: Ran a pro bono, original workshop for ~20 teams (40–60 students), with my own worksheets instead of the ready-made template.
- Result: Very positive feedback from participants; the workshop prepared them for the weekend hackathon.
Diagnosis
Design Thinking teaches you to design around user needs. Data Thinking teaches the same thing, but around data: what you already have, what’s missing, and how to use it to solve a problem. I first saw the method at a conference (a talk by Tizian Kronsbein), then traveled to Berlin for the full training with him. When SWPS University was preparing a weekend UX hackathon, I ran a pro bono prep workshop for ~20 student teams. I didn’t use the ready-made template (the Data Innovation Board); I designed my own worksheets so participants would uncover each stage gradually, instead of seeing the whole process upfront.
flowchart LR
A["Stakeholder groups<br/>and their tasks"] --> B["User<br/>needs"]
B --> C["Types of data<br/>sensors, APIs, systems"]
C --> D["AI/ML solutions<br/>segmentation, scoring, anomalies, prediction"]
classDef neutral fill:#f0f0f1,stroke:none,color:#3f3f46,rx:14,ry:14
classDef accent fill:#27272a,stroke:#3f3f46,stroke-width:1px,color:#fafafa,rx:14,ry:14
class A,B,C neutral
class D accent
linkStyle default stroke:#a8a8b3,stroke-width:1.5px
What I did
- Designed the workshop scenario: students played the role of managers of a modern building (apartments, restaurants, offices, shops), with every team working from the same context.
- Built my own worksheets across four modules: stakeholder groups and their tasks, user needs, types of data (sensors, APIs, internal systems), AI/ML solutions (segmentation, scoring, anomaly detection, prediction).
- Explained the basics of HTTP and APIs: for many students, their first exposure to how you pull data automatically from external sources.
- Ran the workshop solo, pro bono, for ~20 teams of 2–3 students (~40–60 people), in the summer of 2023.
Results
- ~20 student teams (~40–60 people) went through the full workshop.
- Very positive feedback from participants.
- The workshop prepared students for the weekend UX hackathon.
- Method adapted from Berlin: my own worksheets instead of the ready-made Data Innovation Board.
The problem
Why did students need a workshop before the hackathon?
Because they knew Design Thinking, but had no framework for thinking about what data they had access to and how to use it in a solution. Without that, many teams would have gone into the hackathon with an interface idea first, without stopping to ask what data actually drives the decision they’re designing for.
Why not just use the ready-made Data Innovation Board?
Because showing the whole template upfront would have disrupted the thought process I was aiming for. I wanted participants to uncover each question gradually: first who’s involved and what they do, then what they need, and only then what data and what AI/ML solutions could help. My own worksheets gave me control over that pacing.
My role / scope
- Solo facilitator, pro bono, while working full-time (as a Product Manager at an e-commerce company).
- Designed the scenario, the worksheets, and the entire flow of the workshop, from researching the method at its source to facilitating it in the room.
Process
- Learned the method at its source: a conference talk, then a full training in Berlin with Tizian Kronsbein.
- Adapted it for the group: gradual reveal of each stage instead of showing the whole template upfront.
- Built a shared scenario (managing a building) for every team, so approaches could be compared and facilitation was easier.
- Ran it once, in the summer of 2023, right before the weekend hackathon.
Key decisions & trade-offs
- My own worksheets instead of the ready-made Data Innovation Board. Cost time to design from scratch, but bought me a gradual reveal matched to the workshop’s length, something the ready-made template couldn’t give me.
| Approach | Trade-off | Decision |
|---|---|---|
| Ready-made Data Innovation Board | faster to set up, but the whole process visible immediately | rejected |
| Custom worksheets | more design work upfront, but control over the pacing of discovery | chosen |
- A shared scenario for every team. Less freedom for teams to pick their own topic, but every team started from the same context, which made it easier to compare approaches and help teams that got stuck.
- Honestly: the workshop was never repeated. A one-off, pro bono, alongside a full-time job. There was no room to turn it into a recurring format.
How it turned out
The workshop ran once, in the summer of 2023, and got very positive feedback from participants, but it was never repeated because I ran it pro bono alongside a full-time job. Today, with access to vibe-coding tools, I’d add a fifth module: taking the AI/ML worksheet all the way to a working prototype in Google AI Studio or a similar tool, so students could see how close an idea actually is to something clickable.
What I took away
- Gradual reveal beats showing the whole framework upfront. Participants focus on the step they’re on instead of trying to skip ahead to the end.
- A shared scenario for every group makes facilitation easier. It’s easier to help a team that’s stuck when you know the context they’re stuck in.
- A method learned at its source transfers well to a different group. From company employees to students, the underlying skeleton of thinking about data is universal; only the scenario changes.
- The format fits business in the AI era. Connecting data sources with AI agents can nearly automate building the tool, testing it, and monitoring it, with a UX person driving that from needs research through to rollout.