Crisis relief app

Project links

Click here to open the live project in a new tab

Click here to open the source code in a new tab

Joining the Hackathon

While grinding on Pluralsight, waiting on the bench for my next contract, a familiar email notified me to do the hackathon. It had probably been the 10th time this email had come to my inbox, but I had been avoiding it. The first time I saw the announcement I was busy with my last contract and with being in the middle of lent, I was all but in the right mood to commit to doing the typical all-nighters hackathons I was used to during my university days.

But as I sat on the bench with my brain frying from watching training videos, I thought doing the hackathon would help put forth what I had learned. And feeling too old for all-nighters, to my relief I found out this was not the case. So I was resolved to participate.

Choosing a Project

Per the email instructions, I followed a link to a website listing all the project proposals where I was supposed to contact the project leads.

I found two that I was interested in: a project that simplified sharing files between devices and a crisis management app emerging as a need from the Ukraine war.

Being late to the party, I composed two emails with my qualifications and sent them away. Within the hour, I got a reply on the first one, and it was negative; the project lead said he had it handled.

As the days went by, I had forgotten about the hackathon, even though emails never seemed to have stopped telling me to do it.

Joining the Team

A week passed, and I got a reply to the second email I had sent. This time it was positive, I got an invite from Thomasz Michniewicz to the meetings, and the same day I was introduced to my other team members, Veena Mathews and Jaime Castillo.

I found out that the team was not set on their crisis management idea during the meeting. The team had a proposal and even an initial draft, but there were a lot of directions lacking overall focus.

Implementing the Lean Business Model

Having worked on business startup ideas, I had recently learned the "Lean Business Model." This model is where you summarize the project on a single page together as a team, leaving no ambiguity on where we need to put our efforts.

We identified the top three problems to solve with our Crisis Management app, which helped us stay focused throughout the hackathon.

Developing the Prototype

We often thought about a feature only to realize that the feature did not address our top three problems, which was our only way to empathize. As per Design Thinking principles, we needed user interviews to empathize, but in our case, the lean business model was a great alternative when short on time and resources.

We figured that our end-user is likely a mobile user and focused our MVP on a mobile prototype.

We chose Material Design due to its implementation in the Angular library, which was necessary as the team was most knowledgeable with the framework, but also because it had a nice Adobe XD file to wireframe from and was Android design language.

The backend was done in node.js / express for rapid development.

The app relied on filtering big data from Telegram API, and we used OpenAI to parse location and other metadata from the feeds. For example a message such as this:

A sample mockup message

Hello! I live in Leipzig, would like to help refugees from Ukraine. I'm a nurse with 10 years of experience. I'm available after 4pm on weekends. My email: alice@example.com

The sample mockup message would get parsed like so:

Iterating on Wireframes

The initial wireframes weren't going to win the beauty contest, but persistence is vital. Progress can be seen below after taking the feedback from our daily meetings and iterating on it:

Overcoming Challenges

We were all happy with the last iteration, but now time was running short as we needed to convert the wireframes into the prototype. In addition to lack of time, some complications, such as nonexistent components in the Angular Material Design library prevented us from developing the wireframes, so we improvised and adapted.

Our focus was on an MVP that we could demo to others to understand people using this in action. Even without an exact copy of the wireframes in our prototype, we still have achieved what we came here for. The idea is to use the prototype to identify possible gaps in our knowledge when doing usability testing with people, which certainly would have required another iteration or potentially have rendered our wireframes useless based on new findings.

I would have liked to have had the prototype closer to the designs, but since UX had a major weight in the contest our strategy was to divide and conquer in areas we were efficient working in. This led to a bit of divergence at the expense of trying to maximize the score we got, which we hope paid off but, I am glad I pushed myself and did this hackathon. Stepping out of my comfort zone and being challenged, I sharpened my skills, met new amazing people, and worked on a meaningful project. I definitely will be coming in next time around.