Case Study: Local Training

Goal: To improve the connection with the local markets, our company wanted to create localised landing pages for the trainings and workshops within a country, making it feel we are available near you.

Who: Hackages, a tech edu startup in Brussels, Belgium

When: Spring 2019

When the whole team was in Tokyo in February, we created an iteration on an existing static page with 2 designers: I designed a single landing page in Figma, and my colleague integrated it into html. It had a limited scope and all information was hard-coded. It was quickly put live to test the water and get feedback.


Back in Belgium, we started working on v3 with a small team (1 designer + 1 frontend engineer for design and integration, 1 backend engineer + 2 interns for payments and database, and a facilitator).

The new version had to improve on the initial version while also extending the scope:

  • summary and detailed information for each training within a technology
  • translated into languages of the country
  • list of upcoming trainings
  • payment flow for buying tickets
  • navigation: country → tech → trainings → payment
  • all data in resources or database for easy/automatic updating

My role in this team

  • research, log book, documenting (Notion)
  • wireframes (Figma)
  • prototypes (Figma, InVision, CodePen)
  • defining user tests
  • visual design (Figma)
  • 1st integration (html, css)
  • 2nd integration (React, styled-components) together with engineer
  • testing & bug fixing (React, git)

We started with a wireframe that is roughly based on the v2 landing page.

One of the early ux decisions we had to make was how to layout the hierarchy of content. Do we continue with 1 long scrolling page or implement a horizontal tab system for the main content?

To make this decision, I created two prototypes and we did user testing in our offices and in the co-working space in the building.

Wireframe with expanded horizontal sections
Wireframe with expanded horizontal sections

Wireframe: horizontal vs. vertical
Wireframe: horizontal vs. vertical

There were some remarks on the horizontal version (people didn't notice the tabs and thus missed that information), while the long vertical page did not result in any problems. So we opted for the vertical one, as this would likely result in an easier to implement mobile version too.

Another design decision to be made: on a tech page (e.g. JavaScript) we want to highlight and explain the different trainings we have for that tech. However, we do not want to have 1 long general text for all trainings, nor do we want to list all of them on 1 page.

A navigation bar at the top or a dropdown selector could work, but might easily be missed by visitors scrolling down and not paying attention.

We came up with the idea of big cards in the hero section to make it really easy to choose a training, and see that the content below reflects that choice.

Wireframe for training cards in hero section. When scrolling down, the hero section could shrink to make room for the content.
Wireframe for training cards in hero section. When scrolling down, the hero section could shrink to make room for the content.

I created a codepen to test the interactivity of training cards with users. I added some design so that the test would feel as a real webpage. You can open the codepen below in a new window and click the cards.

Click on Original to open the CodePen in a new window.

User tests showed us that the concept worked as expected. However, there were some remarks about not immediately noticing that the content had changed based on the card.

At this stage, the design direction was based on the idea of each tech page as standalone: i.e. you google for "javascript training Belgium" and you'd end up on that tech page. That's why we opted to use the tech colours throughout the design.

Here you can see the full tech page design, including some tech branding and the various screens for the payment flow.


We finished the design of the tech page with a prototype that was then tested with several users. Overall there were very few problems to note, except that some people didn't get the concept of the tech colours → they expected to see the Hackages (teal) colour everywhere.

We realised that we assumed tech people were familiar with the logos of these technologies, but that turned out to be wrong. Additionally, a portion of our audience would be team leads and business people buying trainings for their team members. They are definitely not familiar with these colours.

The team decided that in a future update we would change the design to be more tech neutral and more branded with the company's colour.

With the tech page done (and put live), we started working on the other content: pages for mentors, detailed training information and country landing page.

Here you can see the design for the mentor page. The idea was to include snippets from around the web to illustrate the contributions to the community, tweets from students, videos and podcasts, etc.

Mentor page - desktop and mobile design
Mentor page - desktop and mobile design

Detailed information page for a training. The main goal was to make it easy to find and consume the necessary info → the day overview visually shows how the hackcamp is taking place, before diving into the details of each day.

Training Detail - Desktop
Training Detail - Desktop

Training Detail - Mobile
Training Detail - Mobile

As the other pages were not related to tech, they were designed with a neutral design that relied on the Hackages colour for branding and the action blue for CTA's.

After the integration of these pages, we tackled the design problem from earlier: the tech landing page was updated to match the detail pages. The tech colour is now only used in the hero section (the design of the cards).

Design update for the tech page
Design update for the tech page

Tech page live (wip):

Mentor page live (wip):

What I learned from this project

  • Agree on the approach and outcomes before you start. It will save you from a lot of discussion and problems.
  • Assumptions about your audience can speed up the process but can backfire when the assumptions were wrong → have some team members validate these assumptions while others continue.
  • Even small missions have a lot of details to handle → don't underestimate the amount of work to be done. I believe we made a good decision on breaking up the project to deliver in chunks instead of waiting one massive release.
  • Teamwork needs careful coordination and lots of communication. Friction is not always visible, not every team member speaks up about disagreement with decisions that were taken. Halfway the project we had some discussions about choices made and the way forward. This turned out to be necessary to deliver the project within time & scope.