Inspire a Spark of Creativity with a UX Research Hackathon [+Template]

This might be a nerdy thing to say, but I love hackathons. There's something so fun about them. You and your team are rallying together for a few days to solve a problem innovatively. It's exciting, fresh, and re-energizing.

Unfortunately, they don't happen that often and are usually separate from work.

But what if I told you there was a magic way to mix hackathons and user research?

First, what's a hackathon?

Before we dive into my hackathon story, I want to explain what hackathons are, in case you aren't familiar with them.

Loosely defined, a hackathon is an event where people come together to "hack at" different problems. Usually, about five people in a group work together to solve a problem within a specific timeframe.

Often, hackathons are over weekends, and you work together during that time. Then, the team presents their solution and can win various prizes.

The first time I did a hackathon was back in New York City about seven years ago. I submitted a project I was working on to a hackathon event. My project idea was about an app or service that helps rehome animals more efficiently.

Once they accepted my idea, they assigned a group to the problem. That weekend, I worked with a product manager, designer, developer, and market researcher. We labored tirelessly over the weekend to prove the problem was significant and create a solution. In the end, we presented and won third place!

After that experience, I was hooked. I've done many hackathons since, joining as a user researcher. Each has been incredibly fun and rewarding.

What does this have to do with user research?

So, let's return to the initial point of mixing hackathons with user research.

About five years ago, I worked at a company with a relatively solid user research maturity level. My colleagues would listen to research sessions, try to incorporate my findings into the roadmap or sprint, and use my deliverables to help prioritize work.

To be honest, it was dreamy. I did a lot of work to activate my insights, from ideation workshops to monthly newsletters, and it was paying off. I loved watching teams use my research to make better decisions. I finally felt like I was embedded in an organization.

However, there were recurring insights that nagged at me. They didn't really "belong" to any specific team and weren't big enough to cause chaos. But it would bug me every time they came up in research sessions.

I know we had to solve them, but since they didn't fall under a particular team or cause, I didn't know how to get started.

Over the weekend, I was participating in another hackathon when it hit me. Why couldn't I use this format within the organization to solve these annoying, unowned insights?

And that's when I decided to run a user research insight hackathon.

User research insight hackathon

That Monday, I got to the office and looked back on what insights had recurred over the past two quarters that we didn't get to solve. I also looked at their priority through their impact on the user and how many people the problem impacted.

After a few hours, I had a list of about five insights that would be amazing to solve but didn't have a clear place in any roadmap. So I approached my manager with the idea of holding a company-wide hackathon to solve some of these issues.

After I got the stamp of approval, I sent an email about the hackathon, its purpose, how it would work, and for people to "apply" if interested. The application process just told me when they were free so that I could pick the best dates for as many as possible.

Once I saw how many people were interested, I knew we could tackle all five insights in the timeframe. I had people vote on their top two favorites to help me make the best teams.

With that, I chose three days for the hackathons where the participants would be fully immersed in their respective teams tackling their given insight.

The purpose over these three days was to:

1. Collect and understand previous research on the insights (we had plenty for all of them)
2. Conduct any stakeholder interviews, if necessary
3. Ideate and create a prototype that I could test with users

At the end of the third day, each team presented their insight and solution to the entire company. The company voted on the most innovative and creative idea.

The team with the most votes got a day off with a free brunch at a nice NYC restaurant, and the team in second place got Amazon vouchers. Each other team got a small prize as well for participating. We held the presentations on a Friday, so we also had a small company party to celebrate everyone's work.

Ultimately, I had multiple prototypes to test to finally get us moving in the right direction to solve some of these irritating, recurring issues!

Since then, whenever I have insights that feel stuck, I turn to my hackathon. In fact, at that company and some others, I held a user research insights hackathon every quarter.

How to set up a user research insight hackathon [+ Template]

While they are a ton of fun, hackathons can be a lot of work to organize and run. To make it easier if you're interested, here is a step-by-step guide on how I set up and run a successful user research insight hackathon:

✔ Create a document on the hackathon

First, I always start with a document to help ground me in an idea. When I initially came up with the hackathon idea, I wrote down what it was, why I wanted to run it, the time commitment, guidelines, and the goals.

Another thing you might want to do at this step is to chat with the legal department to make sure you can do this. Some teams stayed in the office working late, and I wanted to ensure it was okay.

✔ Send out an email to gauge interest

I should have done this before I worked on which insights I'd use and got the go-ahead from my manager. I was lucky there were people interested in the idea. However, I always recommend starting with an email to see if there is interest before putting in too much work.

Within this email, I linked to the document above so everyone could understand what it was about and, most importantly, the time commitment. I then asked everyone interested to fill out a Google Form survey picking some dates they were available.

✔ Choose your insights

Once I knew who was interested, I went back and looked through those "nagging" insights. What were some issues that kept coming up that didn't seem to have a team or a roadmap?

I then used part of the RICE model (minus the “E”) to prioritize them on a table. As I mentioned, I used reach, impact, and level of complexity:

• Reach is how many users this issue affected
• Impact looks at how severe of an impact this issue has on users
• Complexity measures how easy or difficult a project is to complete

I had some help from analysts, product managers, and engineers in determining these levels.

Once I had my list, I looked at how many groups we could form. Ideally, there are about five people in a group with a mix of roles. If you don't have enough to tackle all your insights, that's okay! You can pick the top three or have the group choose.

✔ Pick the dates

I then picked the dates based on people's availability. So although some people couldn't make it, we still had enough people to tackle all the insights.

I then invited the teams to out-of-office calendar blocks. Next, I set up a few automated emails reminding them when it was happening. Finally, I invited the entire company to the presentation section. Each group got ten minutes to present their work, so, in total, I made the presentation meeting for about an hour.

✔ Map out how it will work (and gather materials)

It was time to figure out how I would get all these groups together. Since there were five groups and limited meeting rooms, I had to get creative. We had some space in a hallway outside our office. So I sectioned off the area for three groups in the hallway and booked two meeting rooms.

I then went off to get various supplies such as:

• Paper
• Pencils, pens, markers
• Glue/tape
• Highlighters
• Sticky notes
• We had several portable whiteboards that I also used
• Snacks, chocolate, and water bottles

Once I got all the materials, it was time to gather the research for each insight.

For each team, I made a slide linked to all the relevant research I knew for that particular insight. That made it easier to sift through what we already knew to create the best solution.

I then spoke with my manager to understand the budget for the prizes, and I picked them based on that!

✔ Set up a presentation for the day before

The day before the hackathon, I presented to all the teams. Within this presentation, I:

• Reiterated the goals and the expectations of each team (ex: a prototype and a 10-minute presentation)
• Gave ground rules, such as using "yes, and" and collaboration best practices
• Showed them their research-based slides
• Had them ask any questions
• Shared the prizes

✔ Start the hackathon!

Finally, let everyone go off and work on their insights. Always be ready and available for questions, so don't plan super heavy work for yourself that day.

✔ Host the presentations and vote

I kicked off the big reveal by reiterating the goals of the hackathon, the teams, and each team's respective insight.

Each team got ten minutes to present their work and the solution. After that, the company (whoever attended the presentation) voted on the best solution. I used pen and paper back then, but you could also use an online voting tool to make your life easier.

I then presented the top two teams and their prizes.

✔ Get ready to do research

That following Monday, I had five prototypes to test and got to work on setting up users for each of those. We then moved forward with several solutions and tracked their progress with those teams. One insight ended up becoming a revenue-driven product!

Every time I run one of these hackathons, I remember how much fun it is and the joy on colleagues' faces during the event. Not only is it a great way to get colleagues to collaborate, but it's also fantastic for sharing and spreading user research across an organization.