Interact with Axure Prototype

Project Overview: This project aims to provide a toolkit to enable hackathon organizers to make gender inclusive decisions when planning their event. Information is presented in a scaffolded manner and is chunked along different stages of hackathon planning.

Motivation: I was once at a developer meet and the topic of under-representation of women in tech in the industry came up and someone commented that the place they worked at largely recruited during Hackathons and that there was ‘lack of female talent’ at such events. Although they were referring to the relatively low number of female participants at hackathons, the phrasing of the sentence struck a chord with me. Having gotten an internship by way of networking at a hackathon and attended a talk on ‘Inspiring Women to Join the Maker Community through Hackathon Participation’ by Grace Metri(Intel) at Grace Hopper 2015, I saw the virtues of  attending such an event and pitched the idea to my Education Technology team for our Design Project.

Design Process:

Research and Brainstorming:

We did preliminary research on why women do not attend hackathons and  during our research, which comprised reading blogs, papers, informal talks with friends, we found a number of anecdotal reasons for this underrepresentation –

-stereotyping of female participants by male participants

-competitive, possibly, hostile environment

-lack of confidence about skills because of the ‘brogrammer’ stereotype, self­ theories

-predominantly male environment

-women from being relegated to a secondary role

-unsociable nature of the events, such as lack of sleep

-even affirmative action can backfire sometimes as some women feel patronized

IMG_20151119_194847375We identified a general framework(image alongside) for a Hackathon and proposed to teach women about the benefits of going to a Hackathon by conducting a shorter workshop that followed the same framework. Our rationale was that it could be overwhelming for a first-time goer to spend 24+ hours in a competitive environment and hence a shorter design-jam like workshop might serve as a stepping stone and also address some mental-blocks that participants may have about not being able to contribute to a hackathon.


  1.  A 50/50 representation hackathon/design-jam such as Spotify’s hackathon.
  2. Open ended social impact hackathons – focusing more on impact rather than quality of tech / software created or Wearable Technology Hackathon based on Lilypad platform

Possible strategies/ tactics for Design Intervention-

  1. Conducting a ‘design jam’ workshop in the same space as an actual hackathon to simultaneously expose participants to the envirornment of a hackathon and keep them away from the (sometimes agressive) competitiveness of the environment. Reduce pressure cooker environment; make it less stressful, food – bathrooms – space considerations
  2. Design a curriculum which involves project based work along the lines of the framework we identified + some sort of Mentorship program  where a student is paired up with a mentor, who can be another girl who has some experience in hackathons. Once they have gone through the process they may feel more confident about being able to contribute. Design decision-should it be all female ? select 50-50 participant?
  3. Make an information resource for organizers and participants based on our findings


Pitch idea to other teams: We pitched our ideas to the rest of the class and discussed benefits of going to a hackathon, why women do not go, our design intervention ideas.

Here is a summary of the Critique we received from the rest of the class:

  1. Unclear about learning goals– was it to teach the design process from brainstorming an idea to demo? or was it to teach women benefits of going to a hackathon? or was it to give them confidence of being able to attend a hackathon?
  2. Why Hackathons in the first place? Why can’t we take the learnings from a hackathon and teach them in a different environment?
  3. To our point that some women do not attend hackathons because of the sleepless environment- it is not so much that they can’t as much as they do choose not to
  4. Liked our research on prior affirmative action- use activities that are meaningful to women as basis for hackathon

There some major takeaways from having presented to the class and I suppose one of the most valuable learnings was to be mindful of how you phrase something especially when talking about sensitive issues such as gender. You may have the best intentions but still come off sounding patronizing!

All of this feedback took us back to the drawing board.

We read some more literature that lead to the following insights-

Digital Innovation: The Hackathon Phenomenon suggested that its not that hackathons are less gender inclusive, it is just that they are no better at gender inclusivity than CS education and the tech industry. This seemed reasonable and so we read more papers on the problems with largely male dominated CS culture.

“Culture and environment as determinants of women’s participation in computing: revealing the women-CS fit.” (Frieze et al.) was perhaps the most insightful paper I read on the topic which discussed how as opposed to handholding women with CS classes one could try and address culture problems in CS. A good quote from their abstract that summarizes this is-

“The reasons for women participating in — or not participating in — the field of computer science have little to do with gender and a lot to do with culture. In other words, we need to recognize that this is a cultural issue, and an issue that concerns us all. Appropriate local interventions in the micro-culture can have large effect.”

With this new information in mind we decided to make a Toolkit for hackathon organizers to make better decisions about making the hackathon culture gender inclusive.

I then made a roadmap of various steps of a hackathon and how a micro-intervention could be made at those steps for a better friendlier culture.


Our final design is a toolkit that allows organizers to simulate the hackathon planning experience using a problem-based approach. There are scaffolds for steps involved as well as for designing with gender-inclusivity in mind.


Persona: Pamela Black, 25, a software engineer at a local Atlanta based company, wants to promote STEM among undergraduates, particularly women by means of a hackathon. She has been to plenty of hackathons when she was younger and remembers the boxes of greasy pizza, Red Bull and co-ed bathrooms very vividly. She knows this, combined with the long nights and often times, unnecessarily competitive environment, was a major reason she stopped going. But she also recollects the friends she made, recruiters she met as well as the sheer joy of creating something that could have a social impact and she doesn’t want anyone to miss out on those aspects.

She goes online and finds the Design a Hackathon tool to help her create an inclusive and inviting hackathon environment for everyone. The screen presents the breadth of tasks available to the her. Since it is her first time, she clicks on Let’s Get Going.

On the Experience page, she realizes that although she’s been an avid participant, she’s never organized such a large scale event – she chooses the beginner option, hoping to be walked through the steps – at least the first time.

Step by step, the tool guides her through choosing each aspect of her event. The next screen allows her to select the type or theme of the hackathon. She sees some custom templates with a rating. After clicking on the green button with a number on it on the event type page, she realizes it is an Inclusivity Score and can help her identify the best fit for her event.

Note: inclusivity score depends on gender-inclusivity of the plan, although some weightage is also given to including non-tech audiences at hackathons. Note: yet to think of a robust algorithm, could also be expert-rated or community-rated.

She can view each templates details and understand why certain types are more women-friendly as opposed to others.

She can even use tools such as Compare all to see similarities and contrasts between templates or the slider option to filter based on rating.

Note: As the tool adaptively scaffolds, the user will be able to Add their own custom templates.  The user will also be able to self-rate these based on self-reflection. This process would be scaffolded by means of a questionnaire/checklist which is discussed in the Assessment section.

Naming Step-

Notice the Naming tip in the bottom for our ‘new organizer’.

Every time she makes a selection, she sees it get added to a side-panel with her selections with a running calculation of the inclusivity score of her event, which is the overall score for her event.

Recruitment Step-

On the recruitment page, she sees helpful hints on what to avoid and what to ensure while promoting the hackathon. By keeping the language, color scheme and other branding gender neutral, she can ensure maximum inclusivity.

Note: Contrasting and similar examples

She goes through more steps and reaches a page about Ice-breaker events to ease Team Formation. She realizes how much smoother it would have made it for her when she went as a participant and people doubted her skills or relegated her to a secondary design role despite her experience with development.


Source:Microsoft’s ‘International Women’s Hackathon Kit’

At the end, she confirms all of her choices and gets a personalized timeline / checklist with an inventory of what she should do, buy, and delegate as well as when. She follows the timeline and her event is a great success.

The second time around, no longer a “Newbie”and the software adapts to that. The next time she creates an event she is happy to see that the hints, while still helpful, are a lot more concise. She can also create her own custom template and using the knowledge gained from the beginner track, learns to rate her template using a self-guided assessment.


The design of our toolkit allows the user to customize their own hackathon planning and one could choose to design a traditional software development oriented hackathon or a more socially oriented hackathon. The tool, however, does provide a metric for inclusivity for the information cards it provides. For the purposes of our toolkit, we are only considering Gender-Inclusivity, although some weightage is also given to including non-tech audiences at hackathons. Based on all the choices that the user has made in their journey, the tool also calculates an overall inclusivity score for their entire Plan of Action. This score could be a weighted average of all the individual inclusivity scores the user has achieved in individual units. This is the first piece that allows the user to take charge of their own assessment of gender-inclusive design principles. The idea is for it to trigger a metacognitive process where the user is thinking about different decisions along the way and how they could have been improved. Not only does the organizer reflect about their decisions as he or she is planning a particular module, but also at the end of the journey when the entire action plan is ready. There are also tools to facilitate this metacognition such as the compare tool or the filter by score tool which allows the organizer to explore many choices.

Another piece of metacognition reveals itself to advanced and intermediate users by way of adaptive scaffolding. These users can make their own templates for each unit and at the end of their design, they can give their template an inclusivity score. Even though they are performing a self assessment, a questionnaire is provided to them so they can engage in self-reflection by asking some relevant questions such as:

-Does your design include multiple types of computer-scientists beyond the “geek” stereotype?

-Does your design consider computing in context?

-Does your design consider people with varying levels of experience with computer-science?

-Does your design consider people with non-technical backgrounds?

These are just some sample questions and the list could be much longer. The idea is to provide some scaffold to the metacognitive processes involved in self-assessment.

Another useful thing to assess could be shift in perspective about gender-gap issues in STEM. This however, seems like a hard problem to solve. It is far simpler to measure if someone has understood the rationale behind the tools inclusive design considerations rather than if they actually buy into them. And so for now, we will stick with our toolkit being a self-assessment tool helping users think about gender-inclusivity issues in hackathon planning.


The gender-gap in STEM and related events is a complex social issue. By creating this toolkit, we do not hope to solve the problem of underrepresentation of women at hackathons, but rather hope that it will empower organizers with some information to be able to make gender-inclusive design decisions and make progress towards changing the ‘brogrammer’ Hackathon Culture.