Zach Johnson
Boilermake.org is the central hub for hackers before and throughout the event. What do hackers need from our web application, and how do we build such an app using our visual identity?
Boilermake.org is the central hub for hackers before and throughout the event. What do hackers need from our web application, and how do we build such an app using our pre-established visual identity?
Design Team Lead, Designer
August - October, 2019
Max Cherbak, designer
CJ Enright, developer
Peter Kfoury, copy
Affinity Designer, Sketch
Boilermake.org is the central hub for hackers — they use our web app to learn more about the event, apply, RSVP, and receive important information throughout the event. It acts as a resource for hackers to find information, an advertisement to display the awesomeness of BoilerMake, and a space for potential sponsors to learn more about us as an organization.
Our goal was to design a beneficial user experience that uses our visual identity to convey our values: we are space where hackers — experienced and new, alike — can learn and create amazing projects.
The homepage of our web app acts as an advertisement. It needs to represent our values and the benefits people receive from coming to our event. Max and I completed some research to find out exactly what information people need to see in order to apply, and how to represent it.
After countless conversations, we found that people want to explicitly see the information we're trying to visually represent in our designs. Similar to the information we found while creating our branding, people want to know the following:
We want people to be able to quickly and easily see the benefits of attending BoilerMake. We brainstormed ways to represent this information, trying to find a way to both add depth and scanability to the information. We selected the icon route, because we can add scanable visual queues with in-depth textual context.
Many people decide whether they want to attend our hackathon based on the schedule of events taking place throughout the weekend. Though it would not initially display at the launch of the website, we wanted to have a plan for how to represent this information.
After brainstorming multiple ways to represent the data, we selected the 'Whole Event Overview' route because, through conversations with people, we decided that most people want a general glimpse of the events taking place. The descriptions seemed redundant until they were at the event and wanted to know more.
We want people to feel comfortable and excited to be attending BoilerMake. Testimonies offer the perfect chance to inform users of the impact that BoilerMake can have for someone, so we began to brainstorm how to represent the data. We knew that it needed to include a picture, name, and quote.
We decided to move forward with a card view so that testimonies are present, and it fits the overall design since its consistent with our decision for the schedule.
At this point, we had the visual identity for BoilerMake VII created. Our sponsorship packet was sent to companies in an email donned with a themed header. Our website design needed to reflect this visual identity.
BoilerMake VII's mantra is "Hack Your Own Adventure". We wanted our website to visually display the countless adventures and paths people could take at our event.
We quickly realized that this design style was incredibly limiting. Upcoming projects like advertising posters, social media campaigns, swag design, and everything else we design would look similar and negate our "Hack Your Own Adventure" theme, because every adventure would, from a distance, look the same.
We asked ourselves — how can we represent different adventures, while still using the same cohesive style and visual identity? To be honest, inspiration struck rather quickly.
Using our goals throughout the design process, we came to this final result.
So we have the front page designed. Terrific! Next, we needed to create the user flow for how people will actually apply to come to our event. After people finished their application, each applicant needs:
Working with the constraints from dev, we created the following user flow for submitting an application:
For BoilerMake VI, I created an application form. (You can read about that design process in my archived case study.) We made some minor tweaks to the design, both to fit the theme and increase overall usability.
Our first design followed a similar layout to the second page of our sponsorship packet. The screen would fill with the post card, and the user would complete the appropriate form inputs.
After some research and feedback, we discovered that people were confused by the multi-column behavior. They often missed required inputs.
As an attempt to remedy the multi-column friction, we did what any rational design team would do: extend the postcard so that it was as long as the form and put everything into a single column. The users would scroll through like any other website.
Additionally, we tweaked the form inputs, themselves. Research indicated that people were not aware that the line indicated a form input. To remedy, we moved the form title to the left and created a filled background for the input. This is closer to the look people expect from a form input, and helps separate the sections into more manageable chunks for users to fill out.
We decided to step away from the postcard idea, altogether. Any resemblance of a post card disappeared with the extended screen, and it isn't quite consistent with our "Hack Your Own Adventure" mantra.
We went back to basics. The form needs to be accessible with high contrast. We need users to quickly and easily determine any errors in their form. We decided to go with a white container surrounded by the ocean-blue we used in our hero illustration. This allowed us to stay visually consistent, while also keeping usability at its highest.
At this point, we passed the initial design off to CJ and the development team. The dev team was in the process of redoing the entirety of the front and backend for the web app, so they had their work cut out for them.
We met numerous times to refine the home page, fixing CSS, layouts, and interactions that were lost in the handoff. Call to actions were too small, illustrations did not align, the Frequently Asked Questions consumed the page, to name a few fixes that needed to be made.
With less than a week to the website and advertisement campaign launch, we showed the website to other members of the team and potential hackers for our event. We received overall positive feedback — hackers loved the theming, illustrations, and information, but they wanted more in-depth context to some of our claims.
We decided to expand the website to include additional pages with a video and more information about what they can do at BoilerMake. To be honest, these pages already exist on the generic site, so our last-minute design solution involved putting a coat of makeup on the already-existing generic site to help them match our new theming. It's less than ideal, but it solved the problem under our impending design constraints.
I'll be honest. There were definitely times throughout this process that I wanted to throw the designs away and start from scratch, or design decisions we made seemed to be obtuse, or the impact we wanted our design to have was non-existent.
But, the web app is live: http://www.boilermake.org We've already received hundreds of applications, and we've received incredibly positive feedback about our design. It's not perfect, but it appears that our design decisions and countless hours of designing, iterating, and bug testing paid off.
I learned many, many lessons from this experience. First, Affinity Designer is not a great tool for designing a web app. It made passing files between designers and developers easy, because we all owned the software, but it does not have pixel-perfect accuracy, and very few platforms exist to display the subtle details in a design for a developer's eye.
The process of passing a design to the development team is strenuous, and communication is integral. I don't think we communicated with the development team enough to fully convey our intentions. We got there, but we could've saved a lot of time and headache had we communicated clearly from the start.
The web app exists — it's live on the internet for people to visit and apply for our event. Next, we need to design the functionality for the day-of site, where hackers interact with us throughout the event. Needless to say, we're going to take the lessons we learned and apply them to this future design process.