Learning how to UX through tight deadlines, lack of ideas, and lots of sugar
This is a story about how Hackathons are a great way to learn about teamwork, ideation, and refining the process.
Chapter 1: Planning Ahead is Recommended
During my three month stint in San Francisco, I decided to take part in my first hackathon. Lacking coding skills was not an issue as this was a code-free Hackathon, but I chose a couple of my Hacker Housemates, Michal and Jake- a web developer and a mobile developer respectively- as my teammates as I knew that I would be working with developers in the future.
Some teams came with products already partially built, or at least a good idea of what they wanted to create. Our team did not.
We spent several hours going over different ideas for apps- we tossed out dating and shopping apps right away as there are a plethora of them already, and really wanted to focus on something that was useful and relevant to people in the tech industry. I watched the clock incessantly, realizing that our time was slowly but surely slipping away.
Our minds kept circling around networking events. The first idea we came up with was a search engine that would look up people that you met at the event, but couldn’t remember their name. The app would use data from LinkedIn, as well as keywords that were used in conjunction with the user, so each search would build up a profile for the user based on the keywords that users used to search out that individual. Unfortunately, this would rely too much on already existing information and user base.
Eventually, we decided to break down the pain points that attendees experience at networking events:
- Users aren’t sure who to speak to at the event
- Other attendees goals and reasons for attending the event aren’t always clear
- Handing out business cards to many people, but not hearing back from any of the other attendees
On the flip side of things, we thought about the event organizers themselves and the challenges that they face. This is something fascinating that I have noticed in regards to app building: There are often two distinct types of users- those who are using the content, and those who are creating it. In this case, event organizers also have important pain points that should be addressed, such as making sure the event attendees are getting the most out of the event, encouraging event attendees to come to future events, and how to have their event stand out compared with other networking events.
There are often two distinct types of users- those who are using the content, and those who are creating it.
Researching for Solutions
With these thoughts in mind, our team began brainstorming ideas about how these issues could be solved:
Was it possible to create an app that could identify the right people in a room?
How would a user know that another user was the right person to talk to?
What role could the event organizer play in this process?
Were there any apps already in existence that solved this problem? How did they accomplish it?
This conundrum reminded me of a challenge I had run into with one of my other app ideas- was it possible to track people indoors and send them information to their mobile devices? We searched around online and found a solution- IndoorAtlas. If people could be tracked, that meant we could identify them to our users (with permission, of course).
The second challenge was how to present it to the users in the space. Once again, I was inspired by other work I had done recently- an article I had written about Pokemon Go and the increasing use of Virtual and Augmented Reality. What if we could apply the same principle to networking- allow people to identify people in an augmented environment through their smartphone?
We all looked at each other, grinning. We had our app idea!
Chapter 2: The Birth of Tribe, and Learning How to Present It
Tribe would network attendees to sign in with their LinkedIn account and choose the reasons they are attending this particular event, whether it be to meet clients, find a job, hire an employee, working on a project together, or just learn from the lecturers. The app would then take that information and “pin” other attendees as good or fair matches.
The “pins” would be shown through an augmented reality filter. When an attendee enters the networking space, they are given a code by the event organizer that lets them sign in to that particular event. Looking at the event through their smart phone or tablet, other attendees have either a green or a yellow “pin” to indicate whether they are a fair- yellow- or good- green- match. Clicking on the pin connects the attendee to the person’s LinkedIn profile. Now that they know a person- or several people- are looking for corresponding outcomes of the event, approaching them in the space is easier, and results in better connections at events.
This benefits not only the attendees, but also the event organizer, who is able to see where connections between people are made, and be able to show a tangible ROI on their events!
We had spent nearly half the day coming up with a decent idea, so we went into high gear to flesh it out and make it marketable. Luckily, Protohack gave us some tools to help us with this process. Earlier in the day they had introduced us to a fairly new product called Adobe Experience Design, which allowed us to easily build high fidelity prototypes with no need for coding! This made our task easier, especially since I was the ‘Designer’ of the group and was tasked with the creation.
While I worked on the screens, my teammates worked on our presentation. As part of the Protohack, we were expected to create a 90-second pitch for our app, and would be judged on the following criteria:
Protohack was supporting us on that front as well- they provided mentors from both the tech industry and also angel investors who could give us feedback on our ideas and tips on how to present to different types of people.
Our team signed up for both types of mentors- those who would evaluate our app concept and someone who could give us advice on our presentation. If there was one aspect of this hackathon that made it worth the time and money, this was definitely it! We discussed marketability, feasibility, who are users were, and a breakdown of how to discuss the app with others. With the second mentor, we spoke about how exactly one presents a successful presentation in only 90 seconds. While this was obviously an unrealistic time frame, it was good to learn how to reduce talking points down to minimalist levels- easier to add later than to take away!
We scribbled our notes furiously, taking in as much information from the mentors as we could. We decided that Jake would be our speaker, I would change the screens, and Michal would field questions. All three of us worked together to craft the contents of the keynote and the speech that Jake would say, using all that we had learned from our mentors as a guide.
Chapter 3: Presentations and Lessons Learned
When we returned from our mentoring, it was all about finishing our prototype, presentation, and speech before time ran out. Protohack gave us a countdown to submit our work, and then drew the names randomly to see who would be presenting in what order. Our team was one of the later ones to present, giving Jake time to prepare his speech, and also giving us the opportunity to see what all of the other teams had been working on all day.
As mentioned before, some people came in with full-fledged ideas (or even partially built apps), so their presentations were filled with notes on their target markets, statistics, and beautiful graphics, but even they struggled with staying within the 90 second time limit. All of us silently encouraged them, hoping they would get to their points faster, watching as the time slipped away from them.
I was quite impressed with some of the presentations- they really knew their product and how to sell it. Even some of the presentations that weren’t as good had really interesting app ideas, but I’ll admit that I thought our app had a better value than some that were presented (hooray for spending so much time thinking about feasibility!)
Our presentation ran into similar problems as many of our fellow teams- nerves, losing track of where we were in the speech, and getting cut off near the end, but overall, we believe they liked our app idea, even though we didn’t move onto the next round. To be honest, I would’ve felt bad if we had been chosen for the next round as that was for people who really wanted to develop their app into a real product. Ours, on the other hand, was created on the fly and had no real research behind it. It was purely a proof of concept specifically for the hackathon.
My first hackathon was a great success, thanks in no small part to my awesome teammates. Creating Tribe was a slower, methodical process that focused a little too much on creating the best app. This is a great idea when creating an app with plenty of time on your hands, but not so much when you have a time limit.
1st Lesson learned: Come up with an idea ahead of time.
Part of what slowed down our choosing of the app was disagreement between us on which app to work on- the networking search engine or Tribe. This happens in the real world as well. There will always be disagreements, but there needs to be a point where discussion is over and work must begin.
2nd Lesson learned: Speed up the process by comparing the ideas, pro’s and con’s, and having another non-involved party choose the winner
Lastly, our app focused on how to help two different types of users- event organizers and event attendees- and we figured out the feasibility through research, but what helped us enormously was the feedback and advice from the mentors.
3rd Lesson learned: Don’t be afraid to show your ideas to experienced people in the industry. They will help you to improve your ideas and your process.