I’ve attended a lot of hackathons over the past year and a half. They’re a great way to explore new technology, meet interesting people, and test your skills under pressure. As an experience designer, I attend these gatherings with a mixture of joy and frustration. Some are done beautifully. Others are genuinely painful to sit through.
Hackathons are a wonderful, under-explored format. They’re about creativity, collaboration, and people coming together to do something they wouldn’t do otherwise. I keep going because I get so much out of them. But I want them to be better designed.
Experience design can feel like a dark art. Certain people seem to have an intuitive sense for it, others really don’t, and the rest of us practice and study with rigor to get better. The first step is recognizing that it’s a discipline, something that can be learned and applied deliberately. Hackathons desperately need this. Most organizers can’t tell what really makes a difference. It’s easy to focus on the technology, the sponsors, the logistics. Those things matter, but they’re not the make-or-break components.
Whether you’re a firm exploring client problems, a tech company promoting new tools, or a community building shared identity, the experience design either serves your goal or undermines it. Having been through both fulfilling and disappointing hackathons lately, here are the design choices that consistently matter.
Craft a Quality Prompt
The prompt driving everyone’s work is one of your highest-leverage design decisions. Put it in writing. Rewrite it. Test it with people who care about the attendee experience. Make it succinct but substantive.
A good prompt acts like an arrow pointing toward interesting territory, not a bullseye with a clear target. The people writing the prompt should not feel like they already have the answer. If you do, you’re probably hosting a demo, not a hackathon.
Bad prompts fail in predictable ways:
- Too broad: “Improve healthcare” or “Help people feel more connected” gives teams nowhere to aim.
- Too much required context: “Solve a problem for migrant farmworkers” might be meaningful, but if no one in the room knows anything about migrant farmworkers and can’t learn it in the next hour, you’ve set people up to flounder or fake it.
- Tech-centric rather than challenge-centric: “Build something cool with our new API” makes the technology the star instead of the problem. People end up creating incremental, feature-level builds rather than something genuinely interesting.
- Aspirational do-goodery: “Make the world more sustainable” sounds noble but is impossible to scope and execute, especially under time pressure with new teammates. You can’t tell if what you built succeeded, and the outputs will be vague.
A good prompt gives people a challenge specific enough to orient immediately, a context they can understand or learn quickly, and something concrete enough that you’d recognize a good solution if you saw one.
Creative constraints and technical requirements belong in the prompt. Communicating these upfront gives people the best chance of embracing them. Meaningful constraints create interesting outputs.
Separate the prompt from the judging criteria. The prompt identifies the challenge and constraints. The judging criteria assess what makes the output good. Conflating these flattens the work. Separating them creates room for surprise.
For example, a prompt might be: “Build a tool that helps small business owners understand their cash flow using our API. Must incorporate at least one data visualization.” Or: “Design an experience that makes waiting in line genuinely enjoyable. No screens allowed.” The judging criteria might then evaluate creativity of approach, elegance of execution, and how well the solution addresses the challenge. The prompt sets direction; the criteria define what excellence looks like within that territory.
Before you finalize your prompt, test it. Does it immediately provoke a pile of concrete ideas? Does it create energizing fear around how to crack a worthy challenge? Either response is good. If it produces neither, just vague nodding or stumped confusion, rewrite it.
Competition as a Container, Not the Destination
For most hackathons, competition and clear results amplify the intrinsically rewarding elements: meeting new people, building under pressure, playing with unfamiliar tools, testing your own limits.
Competition provides the pressure that makes those things feel vivid. It’s important without being the point. This balance is tricky if you’re not attentive to the contradiction.
The exception is when stakes extend beyond the hackathon itself: job opportunities, funding, external recognition. In those cases, the competition genuinely matters and should be designed accordingly.
For hackathons where competition primarily serves the in-room experience, which is most of them:
- Offer prizes that are exciting and fun. Boring prizes never improved any experience. Consider something symbolic or weird over something obvious and practical.
- Get excellent judges. Choose people who play off each other, represent different values and skills, and can introduce participants to new domains of knowledge. Warm, compelling judges who are excited to be in the room trump impressive credentials attached to someone phoning it in.
- Make judging criteria meaningful and clear from the start. Use them to emphasize your organization’s values. Consider the work judges will have to do in applying the criteria, and make it easy but substantive.
Let Everyone Show Their Work
One hackathon I attended had us submit videos of our work. Those videos went to judges, and judging happened behind closed doors while everyone waited. Only the winners’ videos were shown.
This was curiously deflating.
The intrinsic rewards of a hackathon include connection, inspiration, and the sense of having challenged yourself. Seeing what everyone else created is part of that.
If you’re running a very large hackathon where time doesn’t permit full presentations from every team, think creatively. A lottery where a random subset presents. Breakout sessions where people share in smaller groups while judges review. The point is to avoid having most participants’ work disappear into a void.
Build time for teams to present, even briefly. The collective viewing is part of the payoff.
Structure What Matters, Leave the Rest Fluid
Novice organizers often over-structure the wrong things and under-structure what actually matters. This usually comes from fear of chaos and an emphasis on what’s important to them rather than to participants.
Things I’ve seen over-structured: assigning teams ahead of time, prescribing exact team sizes, dictating where people sit, mandating when groups move from one phase to the next.
Things often under-structured: on-site team formation, submission flow, presentation logistics.
If part of the draw is meeting new people, design a mixer that helps quality connections form quickly. Don’t just tell people to find a team. Create a short activity that surfaces what people are good at and interested in working on. Twenty minutes of thoughtful structure here pays off for the entire event, and it’s less work than pre-assigned teams that feel forced and strip people of agency.
Make it frictionless to submit work for judging. People just sacrificed sleep and navigated the awkwardness of working closely with strangers. Don’t let clunky logistics mar the moment they finally share what they made.
On autonomy: participants set their own challenge within your prompt. Honor that by giving them real freedom to pursue it however they see fit. Structure what creates clarity, connection, and momentum. Notice when your desire for order neuters participants’ creativity. Trust chaos in the right places.
A Quality Container
Some logistical choices quietly determine whether the hackathon feels like a special opportunity or a slog.
Space matters more than people think. Comfortable climate, enough room, acoustics that balance liveliness with focus.
Food, if you can provide it, removes friction and signals that people are being cared for.
Tools and resources make a hackathon feel worth attending. Brokering access to things people couldn’t easily get on their own (API credits, temporary software licenses, specialized equipment, a genuinely interesting venue) signals this is a rare opportunity.
You’re creating a temporary world where people can focus and build something they otherwise wouldn’t.
Optional Programming Creates Rhythm
Programming during the hackathon deserves careful thought. It sets tone and pacing for an event that can otherwise feel amorphous. And it has to feel worthwhile enough for people to step away from their work.
Optional sessions let people take a break, get inspired, and tap into content that might spark new directions. They create variety and rhythm, which matters when you’re asking people to sustain focus over many hours.
But these sessions must earn their time. Time pressure is precious at a hackathon. Anything pulling people away needs to feel worth it, either because it’s genuinely restorative and inspiring, or because it provides concrete information that advances the hacking.
A fifteen-minute talk from someone with relevant expertise can re-energize a room. A rambling panel that doesn’t connect to the work at hand will feel like theft.
Judges can be part of this programming. Interesting judges who share their perspective at various points create energy, and their presence gives them natural opportunities to be available to teams. If putting them on a brief program is what gets them in the room longer, all the better.
Program lightly. Program well. Keep it optional so teams on a roll can stay in the trenches.
Go Overnight
From a logistical standpoint, it’s tempting to cram a hackathon into a single day or an afternoon. It’s significantly easier to host a hackathon that doesn’t go overnight.
The experience pales in comparison.
The best hackathons give you time to stay up late, sleep on your ideas, get sick of what you’re working on and the people you’re working with, and then come back around to surprise yourself by putting something interesting together. You present it to a room of strangers who have become friends over the course of a shared ordeal.
The best hackathons I’ve been to span more than a day. I make more interesting things, form deeper connections, and leave more inspired. If you want the full effect, build in the overnight. The endurance and exhaustion are part of the thrill.
You don’t have to keep the space open all night. Daytime hours on both days work fine. Let teams self-organize for after-hours hacking if they want. Yes, some people will drop off between day one and day two. If you get the other elements right, enough will return, and the results will be more interesting for it.
I Will Still Keep Going
The best hackathons feel like a gift to the people who attend: a well-designed pressure cooker that leaves everyone tired, proud, connected to new people, and motivated to keep making.
I keep going because even the imperfect ones give me something.
There’s the moment after 30 hours of building when you finally get a beer with your teammates and realize you never got around to asking what they actually do for a living. There’s watching somebody struggle with a technology you also struggle with, and liking them enough that you’re still making fun of them for it years later. There’s the surprise of realizing that thing you kept hearing about, that new platform or workflow, is actually easier to implement than you thought.
Once I quit a team that ended up winning. The losing team I switched to was more fun to hang out with, and I still feel good about that decision.
Even mediocre hackathons make these good things possible. Here’s to you hosting a slightly better hackathon because you read this post, and me getting some wonderful memories out of it.