No sleep weekend - Building tech solutions for the public good 👨‍💻

Given that we love a good challenge and creating tech solutions that improve the quality of life and address real issues, we participated in Hackl - the Hackathon for Open Zagreb at the end of November.

The theme of the Hackathon was the reservation and overview of available city spaces in Zagreb. 

Zagreb has 225 public spaces across 17 neighborhoods that aren’t optimally utilized. A significant number of citizens aren’t aware they can book city space, the ones they are facing significant challenges trying to do so.

The current presentation of space information is poor. It does not help in finding spaces and available time slots, the process of booking is manual and inefficient. 

Therefore, Ivan Mikuličić , Ivan Livić, Kresimir Certic Misch, and I attempted to solve this problem within the given timeframe of about 40 hours.

Hackathon task was to develop two functional interfaces - with improved usability and transparency:

1. User interface - To enable Citizens to find spaces and submit booking requests easily

2. Admin interface (with several different levels of permissions) - To enable City employees to monitor, approve, reject requests, and add new spaces with relevant details

Cross-functional teamwork - The diversity in our backgrounds and experiences helped foster a dynamic exchange of ideas, leading to innovative solutions and approaches

We started by:

• Briefly analyzing and discussing the functionalities specified in the application requirements (there were indeed many – precisely 12!)

• Brainstorming initial ideas and challenges we foresee based on our experience 

• Assigning responsibilities based on personal skills

The first major dilemma - how to bring the solution to a functional level in just about 16 hours of work

Given the very limited timeframe, coding the solution "from scratch" was unrealistic.

To find a potentially workable solution, we decided to explore no-code and low-code platforms. Ivan Mikuličić and Ivan Livić analyzed several platforms, including Coda, Notion, Airtable, and Bubble.

After a quick evaluation, we decided to use Airtable - due to its user-friendly interface, logic, and functionalities it supports. It seemed like a platform that supported everything we needed to implement.

Advantages of Airtable:

1. Speed and ease of developing no-code applications
2. Ease and intuitiveness of use – for both developers and end-users
3. Wide Range of integrations (for future enhancements) - including calendars, email, Google Drive, Google Docs, Stripe for online payments, and many others

Airtable limitations and second major decision point - exploring a custom design 

Since we couldn't figure out how to brand the Airtable application and create a custom UI in a short timeframe, I proposed to design another solution in Figma.

This solution was a vision for what we could do in the future - if we were given the chance to execute this project.

I decided to start with the experience from the Citizen’s point of view. Assuming that they would be searching for spaces and submitting requests 'on the go,' I focused on a mobile web solution. 

Custom design is powerful because it allows us to:

• Brand the product
• Build scalable solutions as customer and business needs evolve - adding new, complex functionalities
• Excellent UX and UI, addressing real user needs

Misch helped give the solution more personality by creating initial branding

A few hours into the project we had an application name, logo, colors, and icons in the making. It was slowly coming to life!

6 pm - my first crisis. I don’t believe we can finish in time

The clock was ticking, we were all busy working, but somehow the progress seemed slow. We were in the problem-solving, solution-building phase, going somewhere but very unsure if we would reach our destination.

I started feeling tired, losing focus, and not sure of my priorities. Not having the time to play with potential solutions and explore different directions before setting to one was frustrating.

We did a first round of internal review and feedback. I have to say - I didn't like what I heard 🙂 I generally handle the feedback fine as a designer. But this time it frustrated me. I knew the output wasn’t great, I had the vision for what I wanted to do - but the time was so short. I felt a bit defeated.

11 PM - do we have a functional solution??

Once Ivan Mikuličić was clear on the requirements he isolated himself as much as possible from the noise and focused on execution. (good call! :D)

He managed to achieve what I thought was impossible – in 12 hours he developed all the required functionalities for the user and admin interfaces on Airtable.

We tested the solution several times, and with minimal changes to colors and component positions, it looked really good!

It's an understatement to say that we were amazed by the possibilities and usability of Airtable.

I designed the mobile responsive web application for the Citizens in Figma and linked it to a clickable prototype.

Video of the Figma design

The final decision - did we win??

No, we didn't win. But we are genuinely proud of the solution we managed to create during the Hackathon! Until this Hackathon, we haven't fully explored the possibilities of low-code and no-code applications in creating digital products.

We are now convinced that they are indeed a good potential alternative to coding from scratch (for certain purposes of course).

What we could have done better

• Timing the presentation - we didn't help Ivan with timing while he was rehearsing so he ran out of time during the presentation, not being able to show the last few slides
• I probably should have designed a desktop solution rather than a mobile one - as it seemed the audience was slightly confused with the connection between Airtable and Figma solutions
• To enhance the power of the team - Ivan should have quickly introduced everyone at the beginning of the presentation and we should have gotten involved in the Q&A.

What I believe would improve the Hackathon experience

• The main thing we have never experienced at any Hackathon so far was allowing participants to use existing code and solutions. (if they had an open-source license). I believe this contradicts the core idea of the Hackathon as a short-form competition where solutions are created during the event.
• 5-minute presentations are too short to successfully demonstrate and prove the functionality of a solution, especially considering that judges didn't test the applications themselves.
• Without testing each solution, I'm not sure how judges could confidently rate the usefulness, UX, and UI (which were some of the criteria) based on a presentation-only.
• "Usefulness" as one of the criteria was not clearly defined and overlapped with the UX/UI criterion. Usefulness is one of the main goals of UX design. It is achieved by optimizing the functionality and usability. Functionality as what the system provides to users was specified by the organizers (through the requirements for the application). Usability (or how easy it is to use a system - essentially UX and UI) is something we did influence on, but it was also a separate criterion.
• To avoid potential bias, I believe mentors should not have been part of the judging panel.

We have spent an intense but rewarding weekend, connecting as a team, brainstorming, and building solutions for a real problem. We learned about each other's strengths and how to work together towards a common goal in an extremely short deadline. No matter the outcome - it was awesome!