Date
Jun 2020
Client
Internal Project
Very Good Ventures
Role
Lead Designer
Full Application Design
Hack 20
Every year, a community of developers meet around the world to celebrate their passion for a front end mobile app UI framework called Flutter, by going head to head with a hackathon. The format mimics a startup pitch competition where people create “startup” teams, build a UI with a pitch, and then compete for the votes of the audience.
This event traditionally takes place in many cities around the globe. In 2019, 70 meetups took place across the world, and the largest meetup had about 250 attendees. But in 2020… you know the story.
Because of the pandemic, the hackathon could not move forward in the same way, and the competition would need to be done virtually if it were to continue. My company, Very Good Ventures, decided to help out by using their knowledge to make a virtual hackathon platform for the event. My role was to research the competitions of the past, and design the entire UI for the new competition system. We had to design and build it in 2 weeks.
Because time was limited, I needed to prioritize my efforts differently than I would in a normal project. This was my process for designing the app.
Time would not allow for research of past years participants, but we did have access to the experienced organizers of the event. This was where I began.
The first person I talked to was Simon Lightfoot; he worked to organize competitions in the past and knew what worked and what didn’t. I worked with him to understand the structure of past competitions.
This is what I tried to understand from Simon.
Before getting started on any design work, I defined the users, their metrics of success, and any boundaries of development. I did this by interviewing Simon, and creating two documents from our learnings.
Here I documented each potential user, and defined what will make our application successful for them.
Now that we understood the users of the competition, and the use cases, I wanted to create a user flow of the competition from start to finish. To do this I went through the structure of past competitions with Simon.
This document allows us to start with the desired user experience and work backwards to the design.
This competition was broken down into stages
I also defined what would make each stage successful.In the registration view, for example:
In my experience, I have seen quite a few designers produce work, only for the development team to tell them that it will be too costly. I have an understanding of basic database structures, and I find it useful to establish what the model should look like before I start designing.
The point of a graphic interface is essentially to “express” a data model, so I think more designers should put effort into understanding that aspect of their software.
The user model for hack20 wasn’t too complicated. A team consists of up to 5 users, and submits one project. Then when voting comes around, a user will provide ratings to multiple projects.
In discussions with the developers, an argument was made to have a menu that allowed users to choose between the different sections of the application accessible at all times.
I argued that this was a mistake of temporal design. Once the user submits a project, there is no need to change the members of the team, so why show features that the user couldn’t even use.
At the same time, it would still be important for the user to have an understanding of how the competition works and have context on where they were in the process. We decided on a verbose progress indicator, always available at the bottom of the app, that described each stage of the competition.
For the registration page, we wanted to make sure everyone would be able to join a team, so there were many discussions of creating an auto matching system. Due to the 2 week time frame, most solutions discussed were not feasible.
Instead we decided to make a simple system where the captain of a team could add and remove individuals by email.
We set up a Discord server for the competitors, with channels for finding team members. We could see the members of the teams on the backend, and we would help stragglers find teams if they were unable to find one themselves.
The team screen would have the following logic:
The hacking portion of the app was mostly informational. In this phase, members would spend time coding in a different application. All we added was the live stream and tweets about the competition.
For submission, users would add all the information people would need to rate their app, including a link to the GitHub repository and a quick video pitching their app.
The biggest dilemma in the voting section was that there would likely be upwards of 500 projects, and there was no way the users could sort through this number of entries. In addition, users would need time to view the pitches and explore the UI before making their decisions.
The key goals in the voting system were:
We decided that before making the full selection of apps available to every competitor, we would filter the selection to the best creations.
To do this, we randomly showed a single project to a single individual and asked questions that focused them on our desired metrics of success: design, originality, and cleanliness of code.
After each competitor rated 2 different apps, we presented the filtered selection to everyone, and asked them to vote for their 3 favorite apps.
A key goal here was for the user to get a full picture of each app, while making navigation between entries easy. To accomplish this, we created a split screen view, with thumbnail previews of each entry on the left and the materials of the pitch displayed on the right.
To make their selection clear, we added a highlighted row with their selected apps above the rest of the entries. Only after the user added 3 apps, the submit button showed.
Since this entire app had to be designed, developed, and released within a short 2 week period, the development team wasn’t able to build everything I designed. That being said, we got immensely positive feedback, especially for a product designed entirely from scratch.
Upon reflecting with the developers, and reviewing the feedback in slack, we came up with some wins and shortcomings of the final product.
In my original design, I wanted all unused phases of the competition to be hidden from the user, to keep the user focused on the stage. The developers ended up making a side navigation bar that allowed users to instantly navigate between all the stages of the app.
At first I had a strong opinion against this, and the final feedback proved in my favor. Certain users did express confusion around the navigation, but none to the point of rage-quitting the competition.
That being said, after discussing the change with the developers, I realized the hidden value of the extra navigation. Changing between the different stages of the competition using a back-end flag would have made the app incredibly difficult to test, and would have slowed down development when we couldn’t afford any loss of time.
A big part of my journey as a designer has been learning to accept technical trade offs, and working to benefit the user within those constraints. Had my designs been followed, the whole project would have ultimately suffered more, given our time constraint. This reminded me of the importance of being mindful of the team process, and being willing to be flexible with your expectations for the benefit of the project.
I thought that the registration, and submission were pretty clear and straightforward, and didn’t think too much about it. When users actually started filling in the forms, it became apparent that more direction was needed. For example, when asked to enter their name, users would enter their team name rather than their personal name. My theory was that we did not properly communicate the data model of the competition, so the information they entered reflected their confusion.
The competition had an international audience, and I am typically weary of instructions, but I could have made the labels much more specific, and provided an overview of how the whole competition would work at the beginning.
When reading contracts, you want to have the mindset of “How could this be mis-interpreted?” Perhaps it would make sense to adopt that mantra when checking the copy of designs.
If the registration screen could have used an overview, voting really could have used an overview screen. Users generally were able to get through the voting process and follow all the steps, but they didn’t really understand the full concept of the system.
Looking back, I would have made a simple diagram, and showed it to users before the voting process started.
The filtering screens (with the three questions) were simple enough that most users easily figured out how to provide their feedback.
The development team did not have the time to create the palette of three selections, and indeed users found selecting their 3 favorite projects a little confusing, which was compounded by their lack of understanding of the whole system.
This ultimately would also have been easier had we had time to test our designs, which makes me more motivated to test.
In our retrospective the development team came up with a number of improvements that could have been made to the design and the process, but of course, each one had an added technical cost. Our developer Dominik summed it up well; if you have unrealistic time frames, you should start anticipating tradeoffs, and make sure everyone is mentally prepared for compromise.
However, even though we had so much we wanted to do, the competitors were still happy to be part of the competition, and they found what we made much better than YouTube. They were happy to engage in the community, and our imperfect software helped orchestrate that. We provided value, and that’s all that counts.
As mentioned earlier, voting was split into two sections, one for filtering, and one for selecting the votes. The results from voting were bitter sweet.
The team found that the filtering process pretty smoothly, and it did a good job of reducing the 250 projects submitted to a shorter selection of 50 for the last round.
One of the additions I could have included in the design was more transparency around the voting process. The three stage voting process was effective in selection, but the actual process unclear to users, it was difficult for them to understand how to bring the rest of the team up to the .
The final voting screen, unfortunately had some features that were omitted for the sake of time. For example, with the voting screen, we wanted to add a palette section at the top, making the selection clear to users, and a different type of display for the pitches, that sat next to the choices horizontally. However, since the team had built an existing pop up of the pitch for a different section of the site, the dev team opted for reuse of that component over a new component to cut time.
Without the palette of votes, users could only visualize their selection by looking through a list of 50 different squares, and selecting the items with the right color. This was made much more difficult by the fact that many of the startup images had gifs as covers, which were much more visually strong than
This shows the (perhaps obvious) lesson, that when you are restricted for time, there are simply a number of tradeoffs you have to accept. The designs definitely could have been more verbose and put together, but ultimately more time spent on design, would have meant less time spent on development. So, we think we hit the sweet spot of speed and quality.
With that in mind, we still did a ton of work for 2 weeks, and had a generally positive outcome, which tends to happen when you work with an amazing team like VGV.
