I attended a Hackathon last weekend and learnt a very important lesson about the role of proper user interface design in communicating one's message.
We built some cool stuff, had an eloquent presenter and a solution to a real problem. However we failed to get attention. I would say "What we've got here is (a) failure to communicate"..
Let me tell you about our experience.
Although I have been to a few Hackathons and Startup weekends, this was the first time I competed in one.
The event started on a Saturday morning. Because of flight delays, I reached a little late and missed some networking opportunities at the beginning.
Around noon, I walked into a slightly chaotic and noisy room where groups of people were having busy conversations.
Fortunately for me, two of my colleagues were there with whom I could collaborate. After some discussion, we decided to compete in the "wearables" track.
Our idea, (we called it SquadMate) was to design a system which virtually groups first responders and sends alert messages to fellow officers and the command center if anyone drifts away from the group.
Every officer is equipped with a Gimbal beacon, mobile phone and a Pebble watch. The mobile phone collects proximity information from beacons and sends that information to a cloud service, which aggregates the information and determines if anybody is far from the group.
For example, if an officer A drifts away from the group, three things will happen. Every officer's Pebble watch will vibrate, light up and show the name of the officer who is out of range. The Command center dashboard will indicate the proximity information of each officer. Finally an SMS message is sent to officer A prompting him/her to get closer to the group.
Also, any officer will be able to indicate that he/she is in a distress condition by clicking a button on the Pebble. This information is instantly relayed to the Command center dashboard.
Once we got a grip of the idea, we dove straight into implementation. We tested Gimbal beacons and modified the iPhone app to send notifications to the cloud service. Luckily there were people from both Qualcomm and Pebble (Thanks Cherrie!) to help us.
We got the core functionality working by 3 AM the next day. After getting a few hours of sleep, we started working on triggering alerts from Pebble, and the Command center interface.
We used a simple Bootstrap theme for the command center . A table format was used to show the status of each user. The interface looked liked this:
Time was very limited but we got most of it done by the deadline, which was 2PM on Sunday.
We had a perfectly working product that is targeted to a real problem in the public safety space. Our presenter was eloquent and the demo worked without any glitches. We had even used some AT&T APIs which was required to get 25% of grading.
Why did we not win?
I wanted to get some feedback from judges especially since the team that ultimately won the competition had the exact same idea applied to a consumer situation.
I had the opportunity to meet one of the judges and he was kind enough give us feedback. From his notes, he explained the idea as he understood it. He thought the idea was remotely tracking the location of officers. However, our idea was ensuring the proximity of officers in a group.
Thinking further about it, I came up with an alternate interface which is shown below. This interface shows people in a group and outside a group. We could also make it more personal by showing the pictures of officers.
I do not know if we would've won the Hackathon with this interface change. I 'm sure it would have conveyed the message in a much better way than our original table format.
In a competitive Hackathon, the presentation remains the biggest challenge.
Hackathon shows how innovation really works. The holy grail of innovation is combining idea, engineering, design, marketing and a story so that your product cuts through the noise and makes an impact in society.
In a Hackathon, we need to be able to give a convincing pitch so that our idea stands out from the hundreds of others.
The answer lies in making the pitch and presentation a crucial part of your effort. The right flow is start with an idea, build a story, try a pitch and then get down to the implementation.
In a nutshell - think, visualize, pitch and build!
Do you have any instances where your presentation fell short of the execution? Please share in the comments section.
We built some cool stuff, had an eloquent presenter and a solution to a real problem. However we failed to get attention. I would say "What we've got here is (a) failure to communicate"..
Let me tell you about our experience.
How it started?
The 24 hour Hackathon was part of the AT&T Developer summit.Although I have been to a few Hackathons and Startup weekends, this was the first time I competed in one.
The event started on a Saturday morning. Because of flight delays, I reached a little late and missed some networking opportunities at the beginning.
Around noon, I walked into a slightly chaotic and noisy room where groups of people were having busy conversations.
Fortunately for me, two of my colleagues were there with whom I could collaborate. After some discussion, we decided to compete in the "wearables" track.
Idea
In public emergency situations such as a fire, it is important to keep a group of first responders in close proximity for safety of the officers as well as for the success of the mission.Our idea, (we called it SquadMate) was to design a system which virtually groups first responders and sends alert messages to fellow officers and the command center if anyone drifts away from the group.
Architecture
SquadMate has five components - Gimbal proximity beacons, Mobile phones, Pebble smart watches, a cloud service and a command center dashboard. |
| SquadMate - Architecture |
Every officer is equipped with a Gimbal beacon, mobile phone and a Pebble watch. The mobile phone collects proximity information from beacons and sends that information to a cloud service, which aggregates the information and determines if anybody is far from the group.
For example, if an officer A drifts away from the group, three things will happen. Every officer's Pebble watch will vibrate, light up and show the name of the officer who is out of range. The Command center dashboard will indicate the proximity information of each officer. Finally an SMS message is sent to officer A prompting him/her to get closer to the group.
Also, any officer will be able to indicate that he/she is in a distress condition by clicking a button on the Pebble. This information is instantly relayed to the Command center dashboard.
Team
Our team had two developers and one idea person. We didn't actively seek out more developers or user interface designers due to lack of time.Once we got a grip of the idea, we dove straight into implementation. We tested Gimbal beacons and modified the iPhone app to send notifications to the cloud service. Luckily there were people from both Qualcomm and Pebble (Thanks Cherrie!) to help us.
We got the core functionality working by 3 AM the next day. After getting a few hours of sleep, we started working on triggering alerts from Pebble, and the Command center interface.
We used a simple Bootstrap theme for the command center . A table format was used to show the status of each user. The interface looked liked this:
 |
| SquadMate command center |
Time was very limited but we got most of it done by the deadline, which was 2PM on Sunday.
Presentation
There were close to 110 teams and each team had 90 seconds to pitch their idea. Our idea person talked about the problem and the idea. We used one screen to show the command center and the other one to show the projected images of Pebble watch and the mobile phone app.
We started with the command center view showing four people in the group. Then one person walked out of the room. This triggered an alert on the Pebble watch as well as an update on the command center.
We demonstrated how an officer can indicate "distress situation" by clicking the "down" key of the Pebble watch and then reset it by clicking the "up" key.
We demonstrated how an officer can indicate "distress situation" by clicking the "down" key of the Pebble watch and then reset it by clicking the "up" key.
Finally, the capability to send SMS from the command center was demonstrated.
The demo went perfectly without a glitch.
Results
After two hours of presentations, the results were announced. We didn't win in any of the categories.We had a perfectly working product that is targeted to a real problem in the public safety space. Our presenter was eloquent and the demo worked without any glitches. We had even used some AT&T APIs which was required to get 25% of grading.
Why did we not win?
I wanted to get some feedback from judges especially since the team that ultimately won the competition had the exact same idea applied to a consumer situation.
I had the opportunity to meet one of the judges and he was kind enough give us feedback. From his notes, he explained the idea as he understood it. He thought the idea was remotely tracking the location of officers. However, our idea was ensuring the proximity of officers in a group.
User Interface
When I heard the feedback, a light bulb instantly went on! We've got our user interface totally wrong. We used a flat table to show the status which gave an impression that our application is all about remotely tracking the location of first responders.Thinking further about it, I came up with an alternate interface which is shown below. This interface shows people in a group and outside a group. We could also make it more personal by showing the pictures of officers.
 |
| All officers are in range |
 |
| Two officers are outside the required proximity |
I do not know if we would've won the Hackathon with this interface change. I 'm sure it would have conveyed the message in a much better way than our original table format.
Conclusion
I am happy with the experience and learning that happened at the Hackathon. I walked in knowing little about Gimbal or Pebble; but at the end built a useful product with these devices.In a competitive Hackathon, the presentation remains the biggest challenge.
Hackathon shows how innovation really works. The holy grail of innovation is combining idea, engineering, design, marketing and a story so that your product cuts through the noise and makes an impact in society.
In a Hackathon, we need to be able to give a convincing pitch so that our idea stands out from the hundreds of others.
The answer lies in making the pitch and presentation a crucial part of your effort. The right flow is start with an idea, build a story, try a pitch and then get down to the implementation.
In a nutshell - think, visualize, pitch and build!
Do you have any instances where your presentation fell short of the execution? Please share in the comments section.
This comment has been removed by a blog administrator.
ReplyDeleteHi Michelle,
ReplyDeleteWe could have done better if we had more time but definitely we lacked a UI person in the team. I tend to think that UI skills are very different from developer skills but with enough practice, anyone can develop a keen sense on good UI design.
Thanks for checking out the blog.