5 things I learned at the RBC Next Great Innovator hackathon

This past weekend, I participated in RBC’s Next Great Innovator hackathon. It’s Thursday and I’m still exhausted, but it was worth it for a really enriching weekend — not to mention a third place win with my team, Team Athene! (Named after this owl because Mari thought it was cute, and because its name references Athena, the goddess of wisdom.)

I wanted to post this week while my memory is fresh to reflect on some of the many lessons learned I took away from participating in my first full-fledged hackathon. So without further introduction, here are 5 hackathon tips I learned over the weekend!

1. If you can, come in with a concept.

We received a slide deck containing the challenge about two weeks prior to the hackathon. In the time leading up to the event, we pored over the information provided and bounced ideas off each other. When we arrived at the hackathon, our concept was rough — but we had a strong starting point and were able to hit the ground running with coding and design. Coming in with a plan gave our devs the time they needed to create a visually striking demo, while the rest of us continued to iterate on the concept throughout the day. 

2. Talk to coaches early and often.

Throughout the day, RBC made business, technical and pitch coaches available for teams to direct questions to and share ideas with. Within the first hour, we started talking our idea through with coaches, and we kept at it all day. Their input helped us better understand and articulate our concept, and, in several cases, added to and strengthened our product. So if any experts took the time on a weekend to be at a hackathon, take the time to talk to them! They’re an invaluable resource.

3. Two semi-controversial ideas: sketch, and sleep.

Okay, this one is really two pieces of advice for the price of one. But I’m letting it slide because alliteration! Early in the day, someone came up to our team and commented that he had never seen so much physical sketching and writing at a hackathon before. But sketching is a really easy, low time cost way to share and test ideas with teammates before committing them to code. Paper is a really powerful communication tool, particularly in the pressure cooker hackathon environment where so many ideas are flying around the table that it can be difficult to really understand one another.

And slipping this one in here — get some sleep. We decided to end our night a bit earlier, and meet the next morning a bit earlier to make up time. Sleeping gives your brain the opportunity to reboot — when my alarm went off around 5:00 am, my writer’s block on our pitch from the night before was far gone and I was able to hammer out a rough draft in 10 minutes.

4. Practice your public speaking.

It all comes down to the pitch. You may come up with a remarkably innovative idea — but if the pitch doesn’t sell it, your product will struggle to speak for itself. I don’t have much experience with public speaking and I really felt that this weekend. I understood the challenge and believed strongly in our product, but when it came time to talk about it with a microphone in my hand, I was struck by how nervous I felt.

Throughout the weekend, and ideally leading up to it, practice some form of a pitch — even if it’s just talking through the idea in front of some peers. Get comfortable talking about it, and when the moment comes to present and the requisite nerves come around, take a deep breath and meet the judges with the same confidence you’ve shown others.

5. Act like you’re the winning team from hour one.

I’ve saved what I think is the most important takeaway I have for last: behave like you’re number one from hour one! No, not to motivate yourselves (though it can’t hurt for that reason) — to make sure that, should you move on to the final round of judging, you’re ready for it.

In our case, in the first round of pitching, we only had to present a two minute pitch. We didn’t expect to advance to the next round, but we did! That was wonderful, but then we were left with about an hour to turn our two minutes into ten minutes. Somehow we pulled it off, and we were happy with what we presented, but had we acted like we were going to be a final five team throughout the weekend, we would have put together the long pitch alongside the short one, and just had to practice in that hour, rather than write, too.

It was a gruelling weekend, but I learned so much about myself as a leader, a designer, and a project manager from my experience at the NGI. I also got to work with a really talented team, and to see the work of talented students from across Canada. There may yet be more hackathons in my future! But not this weekend — this weekend, sleep!

Why you didn’t read the terms and conditions

I recently worked a project for one of my courses on the usability of privacy policies. Our hypothesis? Privacy policies are nearly impossible to read. There are snarky commentaries online making fun of users for never reading privacy policies and instead accepting them, point blank. And it’s true that most of us are guilty of just that — but I don’t think it’s because we don’t care about the way people use our information.

Rather, privacy policies are designed for us to fail — there’s a reason most websites aren’t set up as massive walls of text. Most privacy policies simply aren’t readable. They’re written in inaccessible, jargon-filled language; they contain no tools for navigation; they’re not designed to scan; and they’re presented to us when we’re in the middle of trying to achieve a task, like signing up for an account, and are fixated on getting that done over anything else. (Check out NNGroup for a great readability primer.)

For this project, my partner and I did a literature review on research observing whether people read privacy policies and why they do or do not. Afterwards, we came up with a set of design principles for creating human readable privacy policies. 


These principles deal with the concept of consent, emphasizing that users should not have to give blanket consent all at once for a massive document. Rather, consent should be flexible and ongoing, and users should be able to accept certain parts of a given policy and reject others (as per Facebook’s privacy settings, for example).

1. Flexible/active consent: Users should be able to easily opt in and out of different aspects of the policy.

2. Ongoing visibility: Users should be able to view the policy throughout the site.

3. Ongoing consent: Users should be able to opt in and out of different aspects of the policy over time.

4. Just-in-time information: Sites should provide JIT privacy information to users during key tasks on the site involving use of their information to ensure clear comprehension is ongoing. (Fortunately, this is an emergency trend in privacy policy design.)

5. Update notifications: Upon landing on the site, users should be notified of any recent updates to the policy and able to view them in isolation.

Readability & legibility

These principles deal with basic concepts of readability.

6. Refined policies: Policies should be as concise as possible and employ short sentences and paragraphs. Similar policies should also be grouped together.

7. Simple design: Policies should be designed in a minimalist fashion and employ a clean Serif typeface presented in a large size that can be changed.

8. Plain language: Policies should employ plain language to express terms. (The research showed a strong consensus that natural language, though comprehensible to users, was often misleading and allowed organizations to sneak branding into policies. Plain language is a preferred alternative to express complex ideas clearly, without obscuring their meaning.)

9. Navigation: Users should be able to navigate through the policy through layered notices. (Layered notices is a term used in relevant literature to presenting policies using standardized headings.)

10. Consistency: Policies should, where possible, be presented in consistent formats across different sites. (This is an ambitious one, that would require standardization across industries! But some measure of consistency would greatly increase readability by allowing users to learn to read policies better over time as they encounter similar ones.)


Related to the above principles, these last four serve to address other means of supporting user comprehension by providing robust support mechanisms and using visual texture to present information more effectively where appropriate.

11. Support tools: Policies should employ support tools such as hints, summaries, and links to relevant documentation.

12. Explanations: Where necessary to express specificity, policies should employ relevant “jargon” terms but provide plain language explanations as well. (Twitter does a nice job of this.)

13. Textured presentation: Where appropriate, policies should employ visual texture to aid in comprehension, including but not limited to colours, visualizations, icons, and tables.

14. Mobile usability: Policies for use on mobile devices should be unique from website versions, employing textured presentation to improve comprehension. (This last one is meant as a nod to the unique problems posed by reading privacy policies on mobile devices, which warrant a set of design principles of their own.)

Future challenges

After presenting these findings to our class, we had them evaluate the privacy policies of some prominent sites with these principles in mind, as well as their own perspectives on design. We also discussed some future challenges for privacy policy design, like how consistency in design could be enforced, and whether people would read policies even if they reflected design principles like these.

Perhaps optimistically, I think they would (though also with good reason, since research shows that people in general are concerned about online privacy, even though their behaviour doesn’t always reflect that concern.) And regardless, organizations have a responsibility to users to create readable policies that allow them to make conscious choices about the way their information is used online.


Related links:

Some of the best (and some of the worst) – TIME rated privacy policies on some of the most popular sites online

What information is missing from those privacy policies no one reads, and why tech companies need to do better on Slate

Easy-to-read permissions from apps on the Google Play Store via Pew Internet