UX designers need to go to hackathons
The second weekend of March, a group of practicioners from Tradecraft went to the Philips Health Suite Hackathon in downtown SF. We broke into 3 subgroups based on our interests in some of the unique personas which Philips created to target certain capabilities in their Health Suite APIs. The group that I was in included someone from each vertical at Tradecraft: 1 Growth, 1 Sales/BD, 1 Engineer, and 2 UX/Product designers. During the first night, we also managed to grab an outside developer for some help tapping into the APIs.
And then the realizations started.
1. UX design methods can make or break even hackathon products
In the beginning of the process, we pulled back from the list of facts about the fictional user whose data we’d been given and brought it back to who he would be as an individual, what his problem was, and how he would use the product we were designing to solve that specific problem. In other words, before designing the look and feel, we designed the whole experience:
We focused on the young guy who’s competing with friends to get healthier and doing more than just counting steps. We looked at a way to incorporate friends as well as workplace incentives for healthier behavior since a healthy, engaged employee is one who’ll stick around, and because it’s easier to grow healthy habits with support.
2. I have room to be more authoritative as a UX designer, even at hackathons
Aside from the user, as a UX designer, I also consider the goals and metrics of the businesses I’m working with. For that reason, some of us UX designers also dip our toes into things like conversion funnels and business canvases. Because of our product vision and broad perspective, we can see the roadmap of product development, and that helps us focus on things like which features to build when.
During our brainstorming session, we spent A LOT OF OUR TIME deciding on the minimum viable product, what core features we could use in a demo, and what we could produce in a couple of days. The actual build time was pretty short because of all the time we spent deciding, and I think we could have been more strict with timeboxing. However, we were focused on the MVP instead of arguing about silly details, so the time spent actually making stuff was way more efficient than I expected . Seeing how productive we were after so little time made me more confident in my UX methods .
3. We can make awesome prototypes that help people “get it”
With 2 designers collaborating on our team, we were able to knock out a really kick-ass prototype that led to one of the better presentations of the evening. We were able to show functionality and a typical flow through the different tasks a user like our persona would take.
Also, the developers built a working business dashboard that showed some of the health results from the data Philips gave us. Eventually, it would also include things like reduced HR acquisition costs, employee engagement, and reduced use of employer-sponsored healthcare (in the long run).
Hackathons need UX designers
So, UX designers: hackathons are great as skill incubators where you can practice communicating with technical teams, clients, and stakeholders. Developers need people who’ll challenge them and make sure they’re building something that make sense (designers need someone to rope them in, too). And everybody needs to agree on the big picture instead of getting tunnel vision for cool features or visuals.
So search for meetups and hackathons in your area, because your skills are as necessary there as they are in your day jobs. And developers: rope in some of your designer friends because it’s great practice for them and you’ll have a better cross-functional team. Maybe we can set up a Slack channel for you.