Creating 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?

Creating 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?

My Role

Design Team Lead, Designer


August - October, 2019


Max Cherbak, designer
CJ Enright, developer
Peter Kfoury, copy


Affinity Designer, Sketch

Getting Started 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.

What information do people need, and how do we represent it?

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:

  • The benefits of attending the event
  • A schedule of events taking place throughout the weekend
  • Testimonies from previous hackers
  • A list of sponsors they'll be able to interact with

The Benefits of Attending

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.

Translating Design Standards to a Website Design

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.

Initial Design Ideas

  • Expand the ocean surrounding BoilerMake island throughout the page
  • Create numerous islands for each section, each representing a different adventure
  • Use the text and islands to flow about the page.

Some Struggles

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.

A Whole New Website Design

  • Create completely unique "adventure" illustrations
  • Each section of the website hosts its own adventure
  • These adventures represent a range of interests — from pink, magical forests to red, extraterrestrial deserts
  • Create a cohesive visual identity using the same illustration style, replicating filler objects, and using a similar color palette
  • On the larger scale, use these individual adventure themes to break-up the larger gym space into smaller, cozier hacking spaces.

There was quite a bit of experimentation....

But we landed here.

Using our goals throughout the design process, we came to this final result.

  • People should quickly and easily be able to apply. We placed the call-to-actions front and center in the hero image, as well as in the navigation bar so it's always present.
  • People can quickly scan through the benefits of attending BoilerMake.
  • For those who want a more in-depth analysis, we've created a secondary call to action for them to learn more.
  • This section is not initially live with the website, which is why it lacks an illustration. Nonetheless, once we have a schedule, people want to easily view the activities they can partake in at the event.
  • People want to see testimonials from people with their same perspective.
  • People have a lot of questions. We've made the most asked questions visible on the home page, but also link to a page with more in-depth answers.

Creating the Application

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:

  • A account to access relevant information and edit their application
  • A completed application with relevant criteria to help us with admission decisions

Working with the constraints from dev, we created the following user flow for submitting an application:

UI Design

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.

Design #1: Postcard

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.

Design #2: Long Postcard

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.

Design #2: Back to Basics

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.

Design, Code, Feedback, Repeat

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.

Last-Minute Layout Changes

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.

Lessons Learned, and Moving Forward

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: 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.

You bet I would change some things about this process.

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.

There's still work to be done!

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.