That was the first thing I got wrong. When I started designing Over the Barriers — a fully accessible gaming tournament we ran at Nokia Arena in Tampere in spring 2025 — I had a mental model of accessibility as a checklist. Physical access. Controller adaptations. Sign language interpretation. Check, check, check.
What the ethnographic work I did before, during, and after the event showed me was that accessibility is mostly about assumptions — and that the people who design events are, almost by definition, not the people whose access needs are most likely to be overlooked.
We had support. Xbox came on as a sponsor and gave us adaptive controller hardware. Nokia Arena gave us a venue with good physical access. We had a volunteer team who were enthusiastic and genuinely committed. We ran user research sessions with gamers who had physical, cognitive, and sensory disabilities. We thought we had covered the ground.
The research revealed some things we’d missed immediately: the registration form assumed all participants would arrive and leave independently; the schedule assumed a pace of play that would be exhausting for players managing fatigue conditions; the social programme we’d designed assumed a specific kind of participation that excluded players who found crowd environments difficult.
We fixed those. Or we tried to fix them. What I couldn’t fully anticipate was how the unplanned moments — the gaps between the programme — would create access problems of their own.
Three things surprised me on the day.
The noise. Nokia Arena is a large, echo-prone venue. We had noise-cancelling headsets available, but we hadn’t thought carefully enough about where sensory overwhelm would first hit players — not during the matches, but in the queue to register. The first twenty minutes of the event, before anyone was seated, was the loudest and most chaotic point of the whole day.
The waiting. Between matches, players had blocks of unstructured time. For players with cognitive disabilities or anxiety, unstructured time in a busy venue with no clear guidance on what to do next was its own kind of barrier. We hadn’t designed for the gaps.
The help-seeking friction. Players who needed assistance found it easy to ask volunteers for help with tasks they’d anticipated needing help with. They found it much harder to ask for help with things they hadn’t expected to need — because asking itself required recognising a problem, then identifying who to ask, then having a social exchange that might feel stigmatising. The easier we made it to ask for help, the more people asked.
The Academic Mindtrek 2026 paper I’m writing from this experience focuses on event design methodology — specifically, how you build adaptability into the structure of an accessible event rather than trying to anticipate every individual need in advance.
The core argument is that accessible event design needs two tracks: a designed track (the things you plan for, the hardware, the physical access, the explicit accommodations) and an adaptive track (the structures and processes that allow the event to respond to unanticipated access needs in real time, without requiring the person experiencing them to perform a high-friction help request).
We got the designed track mostly right. The adaptive track is where the real work is.
A few concrete things:
Build a quiet room in from day one, not as an afterthought. We had one, but it was added late and volunteers didn’t know about it consistently.
Design the registration queue first. It’s the most chaotic moment and the first impression. If you get that wrong, players arrive at their seats already depleted.
Give unstructured time structure. Not programming, but orientation — a clear map, a clear “you are here”, clear wayfinding. The gap between matches shouldn’t be a puzzle.
Train volunteers on the difference between anticipated and unanticipated help requests. The second kind is more common and harder to catch.
The tournament worked. Players had a good time. We’re doing it again. But the ethnographic record is honest about what didn’t work, and that honesty is what makes it worth writing up.
]]>Bubblift is the game we made. It’s an environmental awareness puzzle game where you guide bubbles through ocean layers — clean bubbles rise naturally, polluted ones need help, and the deeper you go the more hostile the water chemistry. Simple mechanic, legible theme, shipped in 48 hours.
Here’s how it went.
Three people. Me, a graphic design student, and a computer science student who had never used Godot but could write C# quickly. The composition matters: we had skills that didn’t overlap much, which meant we covered more ground but also meant there was almost no redundancy. When one person got stuck, the whole thing slowed down.
If I was doing it again, I’d want at least two people with overlapping technical skills so you can unstick each other faster.
The first six hours of a jam are the most important and the most likely to go wrong. This is when you agree on the game — the mechanic, the scope, the vibe — and the decisions you make here echo for the next 42 hours.
We made one good decision and one bad one.
Good: we scoped aggressively. Our first instinct was a multi-level puzzle game with unlockable characters and a narrative. We cut it to one mechanic, no characters, three levels. This was the right call. By hour 36 we were glad we had.
Bad: we spent two hours on art direction before we had a working prototype. The visual language of the game was decided before we knew if the core mechanic was fun. When the mechanic turned out to need adjustment — the physics felt wrong at the bubble density we’d planned — the visual decisions were already entangled with it.
Prototype first. Always.
Hours 6-36 were the real work. The mechanic is simple in concept: bubbles have properties (clean, polluted, heavy, light), the ocean has layers with different physics, and you apply force to bubbles to route them to the surface. The Godot physics engine handles most of this naturally, which saved us.
What didn’t save us was scope creep in small pieces. A particle effect here. A sound effect there. A slightly more complex collision shape. None of these were wrong individually; collectively they pushed us toward hour 40 before we had a complete, playable loop.
The lesson: if you’re adding something that will take more than 30 minutes, cut it. The game doesn’t need it. You need the sleep.
Hour 36 to hour 48 was not fun. This is the part that people who describe game jams as “magical creative experiences” are maybe not fully remembering.
We had a working game. It was not polished. The sound design was incomplete. The tutorial didn’t exist. The title screen was a placeholder. We had 12 hours.
We finished with 45 minutes to spare. The tutorial existed but wasn’t good. The sound design was minimal but present. The title screen was no longer a placeholder.
I submitted and went to sleep.
A few things I took away:
The mechanic has to be intrinsically interesting. Bubblift works because the physics of bubbles is naturally satisfying — they wobble, they resist, they cluster. If your core mechanic isn’t interesting to play before you add any game structure, the structure won’t save it.
Accessibility in games isn’t an afterthought. We didn’t design Bubblift with accessibility in mind, and looking back at it through the lens of the research I was doing for Over the Barriers, there are things I’d do differently — clearer visual contrast, adjustable game speed, better colour-coding that isn’t just hue-based.
Shipping is the skill. Making something complete, in the time you have, with what you know — that’s the hard part. The technical skills you can look up. The decision-making under time pressure, the willingness to cut things, the discipline to say “this is done” — that’s what jams teach you.
I’m doing it again next year.
]]>I’d done research. I’d read the guides. I knew about the dark winters, the quiet public culture, the sauna etiquette. What I hadn’t understood was how much of settling into a new country is not the things you prepare for, but the things that catch you sideways.
This is not a complaints post. Moving to Finland is one of the better decisions I’ve made. But I think the guides written for international students tend toward reassurance in a way that isn’t always useful. So here’s an honest version.
The cold isn’t the problem. I prepared for the cold. I bought the right layers, I learned the rules about dressing in threes, I understood intellectually that there would be days when it didn’t get light.
The problem is the short days. In December, in Tampere, sunrise is around 9am and sunset is around 3pm. That’s six hours of daylight on a clear day. In practice, between cloud cover and the time you spend indoors, you can go several days without seeing the sun.
This is manageable. It’s also genuinely strange, and the strangeness doesn’t fully go away by January. You adapt to it, but you don’t stop noticing it.
I bought a daylight lamp in November. It helped more than I expected.
Finnish culture has a reputation for reserve, and it’s not inaccurate. This is not coldness — it is a different calibration of what social interaction is for, and at what pace it develops.
What I found was that people were, almost without exception, kind when asked for help. The difficulty was that the help-offering that feels natural to me — the preemptive check-in, the small talk — isn’t how things work here. You’re not going to make friends at the bus stop.
The friendships I’ve made in Tampere have been slower to start and more solid once they exist than in most other contexts I’ve been in. I think that’s the trade-off. It takes longer to get there, and when you do, there’s more there.
International student networks help enormously — ESN in particular. But if you come expecting the social density of, say, a West African city, you will need to recalibrate your expectations and your patience.
Finnish bureaucracy for immigrants involves a number of moving parts: the residence permit, the personal identity code (henkilötunnus), bank account access, Kela (the social insurance system), and the tax card. Each one has dependencies on the others, and the order matters.
The good news is that the systems are clear and the people working in them are, in my experience, patient and helpful. The bad news is that you can easily lose six to eight weeks to the sequence — particularly the bank account, which some banks won’t open until you have a henkilötunnus, which takes time to process.
If you’re coming to Finland for a programme, sort your banking before you arrive if you can. N26 or Wise can bridge the gap while you wait for a Finnish account.
Tampere University is good. The resources, the research environment, the supervisors I’ve worked with — all good. PIRG has been a place where I’ve actually been able to do the work I came here to do, which is not always guaranteed in academic environments.
The student culture is quieter than I expected — less of the social intensity I associated with university in Malawi — but the academic engagement is serious and the expectations are clear.
One thing I wasn’t prepared for: the independence. Finnish academic culture assumes you can manage your own time, set your own pace, identify your own problems, and ask for help when you need it rather than waiting to be guided. If you’re used to a more structured environment, this is an adjustment.
I found it suits me, once I stopped waiting for someone to tell me what to do next.
The part that nobody fully prepares you for is being far from home in a way that is genuinely irreducible.
I left Malawi at 28. I have a family there. I have friendships that are fifteen years old. None of them are here. Zoom calls work, but they don’t fully work, and the time difference between Tampere and Lilongwe is two hours — close enough that you should be able to overlap, far enough that you often don’t.
This isn’t a reason not to go. It’s a real cost. Naming it honestly isn’t pessimism; it’s just accurate accounting.
The work is good. The environment is good. I don’t regret it. I also don’t pretend it’s cost-free.
If you’re thinking about it — come. But pack the good headphones, buy the lamp, and make peace with the fact that some things take longer here than you expect.
]]>Let me explain.
When I was Marketing Manager at Beehive Centre for Social Enterprises, the job was nominally about brand strategy, digital campaigns, and multi-platform content. And it was those things. But the actual work — the work that determined whether the campaigns worked — was understanding people.
Why do parents in a particular area choose one school over another? What information do they trust and from whom? What does “quality education” mean to someone in Lilongwe in 2022, and how do you communicate that a new school has it, when the school doesn’t have history to point to yet?
These are research questions. Qualitative, messy, people-centred research questions. I was doing informal user research long before I knew what user research was.
The brand launches I led — four schools from scratch — worked because I spent time talking to parents, to teachers, to students, before I touched a design tool or a social media platform. The grand opening worked because I understood what the community needed from it, not just what made logistical sense.
When I arrived at Tampere University and started studying Human-Computer Interaction, a few things clicked into place quickly.
The vocabulary was new. The methodology was formalised. The rigour was higher. But the fundamental activity — asking “what does this person need, what do they experience, and what gets in the way?” — was the same activity I’d been doing in a less structured way for years.
What the academic training gave me was precision. The difference between an observation and an interpretation. The difference between what someone says they want and what they actually do. The difference between a pattern and an anecdote. These distinctions matter enormously when the work is published and other people are going to build on it.
Not everything translates cleanly from commercial communications into academic research. But a few things transferred directly.
Stakeholder communication. Research findings that aren’t communicated well don’t get used. The skills I developed writing for a CEO and a board — clear, structured, action-oriented — translate directly into writing research papers that committees actually read.
Cross-cultural sensitivity. My background in Sub-Saharan Africa, and the international NGO work with IBE, gave me a perspective on technology access that a lot of HCI research doesn’t have. The work I’m doing on AI accessibility in education in low-resource settings is possible partly because I know what those settings actually look like.
Project execution. Academic environments are good at thinking. They are sometimes less good at doing. The event management skills I brought from Malawi — coordinating logistics, managing volunteers, working with sponsors, meeting deadlines — were immediately useful when we started planning Over the Barriers.
The things I had to learn were mostly about slowing down.
Commercial communications moves fast. The instinct is always toward the next thing — the next campaign, the next platform, the next audience insight. Academic research requires sitting with uncertainty for much longer, asking whether what you think you’re seeing is actually what you’re seeing, being comfortable with “I don’t know yet.”
I also had to learn to read academic literature, which is a skill people assume you have if you’re at university, but which nobody actually teaches. The ability to scan a paper for its contribution, identify its methodology, evaluate its limitations — this took me most of the first semester to develop.
I’m writing a thesis on how teams navigate the integration of agentic AI systems — the friction, the adaptation, the ways people push back or embrace AI that acts on their behalf.
This is a question I care about partly because of the academic framing, and partly because I watched it happen in commercial environments. The Beehive’s adoption of digital tools. The IBE’s content strategy workflows. The way organisations adapt — or don’t — to technologies that change what their work is.
The research and the practice are in conversation. I don’t think I’d be asking the questions I’m asking if I hadn’t spent three years doing the work first.
That’s the thing about non-linear careers. The transitions look like breaks. From the inside, they’re continuations.
]]>