My experience as a first-time hackathon designer
Health 2.0 SF Code-a-thon 2014
The idea of going to a hackathon intimidated me. To my uninitiated mind, a hackathon was a place where computer science pros stayed up all night, chugging caffeinated energy drinks while slamming away on their mechanical keyboards. Then came pitching time when the idea and product you worked on all night would be judged in front of everybody.
That was still my impression in the early morning of Saturday 9/20/2014, when I found myself on a plane headed to San Francisco from Los Angeles, to join my fellow EdgeInterns members for the Health 2.0 SF Code-a-thon, where “developers, designers, health care professionals, biz dev and entrepreneurs will join forces for 2 days of rapid prototyping and creative health-hacking.” I was only armed with this knowledge: the event was sponsored by several health tech companies, who required us to use their APIs in our product.
Not knowing exactly what an API even was (sorry, team), I was super glad when my teammates suggested that I be the team designer. I assumed the role of design lead, and started hacking away with my fellow designer Evan Pun. (The rest of the team is listed at the end).
Our brainstorming session (and after several iterations throughout the event… up till the very last hour) resulted in:
Diabetes & Depression
Winner of the Validic/iHealth Track
- Health topic: Comorbidity of Diabetes Mellitus and Depression
- Platform: Gamification of mobile health data tracking
- APIs used: Allscripts, BetterDoctor, Validic
- Audience: Primary — Type 2 diabetes patients (see personas below); Secondary—Care-givers, or health experts, for educational or training purposes.
- General concept: Our app rewards XP points for each health data point recorded, whether manually by the user via task (or quest) completion, or by automatic input from wearables. Besides data tracking, D&D also motivates the user to improve his mood as needed through certain social tasks. D&D can pull in medication and doctor’s appointment data (via Allscript), vitals such as blood glucose or weight (via Validic and iHealth devices), or, when the threshold for depression is triggered, offer to look for a doctor with appropriate rankings (via BetterDoctor).
The design process
While the market research team read up on Google Scholar and PubMed, and the programming team worked on implementing the APIs, we designers created:
User personas → Wireframes → Colored mockups
User personas
We started with identifying our consumer users. From our research, we found that low income minorities made up the most of diabetic patients who also had depression. To stay focused, we specified income range, age range, and ethnicity to create 3 user personas.
It was very helpful to put a face on each persona, along with detailed stories pertaining to their medical, social conditions and familiarity with technology. By the end of the day, we all knew exactly who “Marqus” was, and he would always be there as we designed our user experience.
Wireframes
For the first 12 hours, using moqups.com, I was able to generate many wireframe prototypes rapidly, while Evan focused on creating a color palette for our app.
Starting from a blank canvas, as always, was the most difficult, until the first rectangle was drawn. After that, I went through several iterations, presented to the team, and revised some more — it was a continuously evolving process. But we had to put a stop at one point to move onto the next step. (OK, the venue closed early and kicked us out.)
Colored mockups
We didn’t have time to come up with a proper style guide, so we just went straight to recreating the wireframes in Adobe Illustrator to fine tune elements and utilize color swatches. We also replaced all lorem ipsum text and place holder images with meaningful content.
The bulk of the work was split among the team as the end drew near. I focused on the master Illustrator file, while others worked on creating art assets (logo, colored icons, avatars, etc.) or exporting completed art boards to hand off to our front-end developers and the pitch team. Thanks to this workflow, we were able to put together a presentation and squeezed in a small demo in time for our pitch session.
User experience for the diabetic patient
Not a single element of the user interface was designed without careful consideration of the experience. Most notably was the decision to bring tasks to the home screen, instead of leaving them accessible on a task list residing on the 2nd or 3rd screen.
Diabetic patients need to take their blood sugar multiple times a day before each meal, so it was essential that this specific task appeared at app launch. Whenever possible, input screens for frequent tasks like this appeared immediately on top of the main screen to reduce navigational steps and maintain context for the older patients. Additionally, to minimize tedium, only 3 tasks would show up on the main screen at one time, chosen by importance and at random. (See previous mockup screens.)
The results
We won several iHealth devices from Validic. The API makes it simple to extract data from various wearable devices on the market, including blood glucose readers to weight and sleep monitors. The latter can provide clues to potential mood problems.
Some lessons
I learned a great deal in the short 36 hours as the design lead for the team. Not only did I gain new perspectives on the hackathon culture, I also gained confidence in working with others towards actualizing a product. Here are some specific lessons:
- Personas are useful. Creating detailed user personas early on helped us narrow down our target audience. This definitely played a role in deciding how complex the app architecture would be and how much gamification we needed for the health data interface.
- Use great freemium apps with care. Instead of using paper or Illustrator for our wireframes, I used moqups.com. It worked like a charm: just drag and drop. Unfortunately, the free version could not export workable vector files, and did not allow multiple users.
- Delegate. Others had time to help with the wireframes, but couldn’t. I quickly remedied this by delegating new tasks that could be performed in parallel with the wireframe, including creating color palettes and graphics to be used in the final prototype.
- Trust. Having just recently completed my Master’s thesis project all by myself for a year, I didn’t have much of a chance to work with other designers. By allowing others to work on their tasks independently and autonomously, I was able to focus on mine in the short allotted time. We thus worked in parallel instead of in serial. This increased work flow efficiency tremendously. By the time I moved onto final mockups, I didn’t have to make the decision on colors and usable graphics.
- Design is important. Through our design process, we were able to identify our users and focused on designing the interface and experience for those specific users. I noticed many competing teams with great APIs implementation ideas lacked a real target audience. In other words, it’s great that you can capture all these data points, then what, and more importantly, for what context?
Final words
I have usually relished in the complete experience of front-end development and design, but I had great team members who were good at back-end programming and front-end coding. This event allowed me to focus solely on the design.
If you are still intimidated by hackathons and think you don’t have enough experience to contribute, just do it. Trust me, there’s something for everyone, from pitching the product, market research and development, to the usual hacking.
And for me? I’ve finally come to terms that I am a designer at heart.
