I’ve been a “participant” at hackathons since my Yahoo! days. Back then I would help out with the very occasional interaction design solution or a bit a fancying up an otherwise average looking dev built UI.
Sadly, this hasn’t really changed despite best efforts, so I’m really thinking UX has no place in hackathons… actually neither does a UI specialist.
Hackathons, or hack days, as far as I can see are one or both of these:
- Get a quick and dirty build going to test a product idea
- Get a quick and dirty build going to experiment with data
Now, it’s realistic not to expect customer interviews or testing. But you’d think some kind of UX would fit into each of these but in reality no-one wants to include any kind of UX activities despite the obvious ones of proposition, task fulfilment or just basic heuristics in the UI.
Actually, the only thing I get asked for to help out with hack days is a quick and dirty logo design.
It’s not that UX isn’t done, its just that a specialist isn’t needed.
User Experience at hack days is automatically within the team. They are the user group, because they are generally solving a problem they are familiar with as subject matter experts. When it comes to validation, its a great way to knock up that solution as an early prototype to get folks playing with it. Just like with startups, a UX practitioner isn’t considered necessary because everyone is holding UX as a frame of mind. As they should 🙂
In the case of the data experiment, any conversations of the “who is going to use this” type are just going to get in the way. It’s entirely inappropriate to set customer/audience needs down during these kinds of hacks. If a user type or scenario is presented it seems to be reverse engineered for the end-of-day-pitch.
I know at times it doesn’t feel like it but we’ve all such done a brilliant job of evangelising UX, that hack day participants automatically consider, at the very least, the basic ideas of another person using their thing.
So from what I’ve experienced and observed, the best we can do to help out is:
- At a hack day any UX work needs to be done prior in preparation and presented as an optional inclusion because the main obstacle for UXers at hack days is of course is lack of time.
- Designers can also supply recommendations for development libraries or frameworks that have solutions in place for interactions and front end assets.
- Take time to examine the data and the hack days goals. If there is a competition, consider the criteria for qualifying. In some cases the audience isn’t someone unknown group of customers but the judges.
Thanks for your comment and question Hilary (http://pollenizer.com/what-we-learned-at-firehose-coca-colas-big-data-hackathon#comment-1155420365). I’d like to see more UX in hackathons. We always include customer validation as a major part of our judging criteria, which means that participants must have an idea on who their customer is and they must get out of the building to get them to engage with their idea. At Firehose, we spoke directly to designers (http://www.sydneyfirehose.com/why-designers-will-love-firehose/), encouraged design thinking in the event and had some great mentors to help. My goal is to have more hack teams with a UX person leading the process. All too frequently the designers are under used and bolt on something pretty at the end. Little wonder it is so hard to get designers to come.
I was really impressed by the efforts Pollenizer put towards inclusion of ux in the hack day, and would love to find out more from the designers who attended about what they learned about working in the timeframe. Sadly I couldn’t attend but really wanted to!