Tips for Being a Hackathon Design Mentor

I recently had my first experience in a mentor role at a hackathon. I’m sharing my top takeaways to help other designers be more prepared for their first time as a design mentor:

• Focus on the hackathon.
• Share what you know. Don’t be afraid to say when you don’t know. Try really hard to not design FOR teams.
• Don’t forget to network!

First things first.

I’m in UX. I’d only been to one other hackathon before this one, a techforgood-type hack to help solve municipal problems. And I had such a bad experience that I left before midnight on the first night. In a nutshell, I joined a team that had already worked together at previous hackathons, had no interest in working with anyone new, and even worked separately from each other in different areas of the huge room that all the teams were hacking in. I was coming down with a cold, and after getting the cold shoulder from this team for a few hours, I ultimately decided to just pack up and go home. (In hindsight, if that ever happened again, I’d probably just go try to find another team to join or offer up myself in a mentor capacity.) That was many years ago, and since then, I’ve been turned off by the thought of going to hackathons.

When I saw the Atlanta Chapter of Women Who Code tweet about their second-annual WWC Hackathon, I briefly considered participating. I’d gone to a WWC event a few years before and was impressed by the smarts, personalities, and professional drive of these ladies, so I felt like I’d have a much better hackathon experience this time around. But then I saw the APB for mentors they needed. I applied to be a UX/UI design mentor because I felt that would be a less-intense way to dip my toes back into that scene. I ended up only being able to participate for one of the three days the hackathon was going on, but it was still worth it. Here are some things to think about if you ever want to volunteer as a design mentor for a hackathon.

Focus on the hackathon.

Don’t go out drinking with friends the night before. Don’t stay out late the night before. (Actually, just avoid doing both of those.) It’s probably in your best interest to NOT commit to anything else for the hackathon duration. You want to have a clear head when you’re mentoring since you’re not going to be intimately familiar with each project’s details, and that tequila from the night before probably isn’t gonna contribute to that clarity.

Since I had some weekend plans already before I was confirmed to be a mentor, I could only do the Saturday afternoon/night of the hackathon (about 10 hours). If I could have made it work, I would have been there for the whole thing. It would have been best if I went Friday night (the first night) to meet the teams, organizers, and other mentors. Hearing the project pitches that night would also have provided with me more context around team direction and goals when I did actually provide help on Saturday. And honestly, I wish I could have been at the hackathon even earlier that second day — because that’s when the teams were planning their product vision, business strategy, and high-level features (AKA the “big-picture, strategy stuff” I love thinking through).

Even though I was only at the hackathon for a relatively short time, I still had a lot of fun helping teams think through design problems. My project work IRL these days seems mostly about trying to create shared understanding (internally and externally), defining and documenting interaction details for design handoffs, and generally making sure the holistic design of a digital experience isn’t janky. Because I’m a senior practitioner and work with other, cross-functional senior practitioners, seldom do I need to verbalize my design process. So, it was a little awkward at first trying to coach non-designers. I quickly learned that my design process and critique is generally the same whether I’m doing billable work for a client or volunteering at a hackathon. Create shared understanding, ask questions, suggest best practices, suggest things to think about, communicate potential tradeoffs. SSDD.

Create shared understanding, ask questions, suggest best practices, suggest things to think about, communicate potential tradeoffs.

Share what you know. Try really hard to not design FOR teams. Don’t be afraid to say when you DON’T know.

If you suffer from “imposter syndrome,” then you should totally volunteer to be a design mentor at a hackathon. Regardless of how you think you stack up at work, if your paid job is UX, then you’re going to automatically have tools and frameworks at your disposal that non-UXers just don’t have. I’m not necessarily talking about actual tools like Sketch, Bootstrap, etc. I’m talking about design thinking, design patterns, interaction design principles, color theory, information design, guerrilla user testing…all the things we UXers have in our back pockets that come second-nature to us. These things probably won’t be second-nature to your hackathon teams, so you can help coach them to make better design decisions by sharing your knowledge about how to approach design problems.

Which brings me to another point: Try your best not to DO the work for your teams. Guide them, share best practices (think iOS Human Interface Design Guidelines), prod them, offer up choices. Try really hard to NOT pick up a marker unless you really need to whiteboard something to help communicate. (Again, this was my first time being a design mentor, so who knows how anyone else approaches this! My instinct was to teach them how to fish.)

Guide them, share best practices…, prod them, offer up choices… My instinct was to teach them how to fish.

There will probably be times when you don’t have the answer(s) or can’t give a team what they need. Here’s an example: One team needed help with logo creation. I suck at illustration, but another design mentor did not. This mentor didn’t like the process of getting to a logo concept, so we split the task of helping the team with logo creation. I brainstormed word associations with the team, introduced them to the Noun Project (rabbit holes for days; you’ve been warned) for further inspiration, and then the other design mentor took over when it was time to actually design some concepts. Being an effective coach means being honest about what you can and can’t offer in terms of help.

Being an effective coach means being honest about what you can and can’t offer in terms of help.

Don’t forget to network!

One really surprising part of my mentor experience was connecting with all of the other mentors. It had been a couple of years since I worked in the software or startup space. I had basically stopped going to tech meetups altogether, so the kinds of conversations I had at the hackathon were the kinds I hadn’t even realized I was missing. Sharing stories about local startups, founders, connections in the SaaS space, dev tools, APIs, DesignOps, whaaa?! I forgot how much I loved talking shop like that with people who nerd out as hard as I do about that stuff.

It was equally as cool to connect with the hackathon participants during breaks. It’s always fun to hear people’s stories about how they came into tech. I met a chick who started out in marketing and is now a legit coder who specializes in data analytics; a front-end dev who turned her focus from UI to to the UX of dev tools; and a student who still has some college left but now just wants to hit the ground running in order to make an impact and continue learning in the real world (because doing is better than watching).

All in all, I had a pretty damn good time, and I can’t wait for the next one!

Women Who Code has a great write-up about why women should get more involved in hackathons. You should read it.