Designing and building recruitment websites

Since 2016, I have led the design and development of our recruitment site. Since identifying a problem with the original recruitment process, I built a site which brought about and continued to gain much greater engagement

Design team

Ranging from just me to 3 designers


2016 – 2020

My Role

Lead design and sole dev


I love this project as it really demonstrates my growth, not only as a designer, but also as as front-end developer. Both the quality of the design improved and the tech became more advanced with each one. Going from a static HTML/CSS, to a JS infused site, all the way to the latest which was a complete Gatsby build, utilising raw Carbon components.


Myself and another designer were approached to see if we wanted to get involved with hiring the next batch of interns.

We were initially just asked to create a job application form on the internal IBM portal, and send this out to universities. However, as designers, we were extremely disappointed with how the portal worked and figured it wasn't going to be a good representation of IBM Design, and wouldn't convince potential designers to join.

Starting with a PDF

We decided to pull together a PDF, which we'd host on IBM Cloud. This was so that we could add the necessary metadata to enable social media previews for the content. The plan was to email this to universities and lecturers, and to share it on our social channels.

We both ran through the process of how a potential candidate would apply, and although this PDF made the job role, and the benefits more clear, as well as giving a clear instruction on where to apply (to the portal), we were both still severely disappointed with the process as our applicants would still have to go through the less than adequate portal experience.

The mandatory application form was awful. It contained a huge number of required inputs, very few of which were necessary for designers at that point in their application.

As an aside

Maybe this was why very few applications were received in previous years (only around 15 per year).

The plan was to only require an applicant to go through the application portal once an offer had been made.

To remedy this I decided to see if I could code the PDF into a website, and instead of directing an applicant to the portal to apply, they would complete a form on the site itself.

Note this is from early IBM design. The design language was in its infancy so there are lots of things I dislike about the above.
Note this is from early IBM design. The design language was in its infancy so there are lots of things I dislike about the above.
What we got wrong

Looking back on this site, there is so much that I would change. The design process here was effectively just taking the PDF design and making that into a responsive webpage. Also the site definitely wouldn't have passed accessibility requirements, which at the time (early grad) I was unaware of.

A google sheets back-end

Design critique aside, what I had added to the website that I think proved extremely valuable, was a data entry form which pumped data into a Google sheet. This allowed us to be in control of what we asked applicants to fill in, ensuring that we were only asking them the most necessary things (a complete shift from the previous IBM portal). This means that the barrier for entry on our application process was pretty low.

As an aside

Over the next two years we actually removed more and more of the above inputs. I also really improved the back-end to have more advanced levels of validation, error state and custom server responses.

The proof

The year before the other designer and I gained control of the process, we were told about 15 candidates per year applied for these roles. In 2016, using our new website and not forcing candidates to go through the IBM portal we managed to get just over 200 applications, which we were not expecting. Whilst we have no hard evidence that this was as a result of our changes, an increase of roughly 550% is significant, at a time when the only changes were the ones that we'd implemented.


The previous year we were just asked to improve the process. We didn't know we were going to build a full website and back-end to handle applications. By 2017 we'd already done the leg work so we were able to put significantly more effort into the design of the site. We also got to utilise some of the new colours that were introduced into the IBM Design language, and also gave the new typeface an early trial run.

User interviews with the previous (2016) interns

Aside from the new visual updates, we did some pretty casual interviews/meetings with the newest interns. They critiqued their entry process and few things became evident...

What we learned

The interns were unclear as to what roles were actually available and how relevant they were to the placement.

The 2016 site was too basic and not intriguing enough. It didn't feel like a "cool design placement".

"What are we actually going to do on the placement?"

The other designer and I also did our own critique of the experience:

  • Why did we ask for phone numbers… we didn't use them at all!
  • Why did we offer a PDF?
  • There was nothing 'fun' about it, which didn't reflect our studio culture.

The new site:

Of course it was also fully responsive
Of course it was also fully responsive


We contacted slightly fewer universities, but still managed to get 146 applications. Although this was down on our 2016 numbers, it was still a significant number and enough to find some suitable candidates for the roles.


Unfortunately the designer I had been working with on recruitment left in 2017 and so for this year I enlisted the help of the 2017 interns. Together we produced the following wireframes which eventually went on to inform the final design.

When building, I did make quite a few changes to the wires in a bid to be more playful with the design, again trying to build upon the improvements made in the last couple of iterations.


Just under 200 applications! A fantastic result.

A new back-end system. Node JS + Cloudant.

This year I decided that rather than using a 3rd party system to handle the actual process of sending the application data, I would produced my own solution using Node.js, storing data in an IBM Cloud instance of Cloudant. This went extremely well and actually owning the code more than I have done in the previous years allowed me to produce a site with a much better user experience, for example:

Custom Validation

Because I was in control of where the data was throughout the entire form flow, I was able to write our own validation rules, such as warning a user when they were linking to a local file, which of course we can't access (yes, people really did this!).

In both the previous years we had at least 5 people send us local links which we then had to chase up. This year we had 0!

A backup

Because I was the single source of failure for the back-end, I decided to add an extra level of protection to avoid potential errors with my code! If for whatever reason the server returned an error code, I provided a link to either try again, or a button to send an email. When clicking 'Send your Application via Email', this automatically compiled the user's data into an email 'mailTo:', which when clicked opened the user's default email client with a pre-populated email ready to send with a single click.

I was very proud of this fallback!
I was very proud of this fallback!

I actually hoped that nobody would ever see this, however due to IBM Cloud revoking support for a previous TLS version (I've no idea what this means!) there was a Sunday afternoon where submitting the form actually restarted the server and meant we didn't receive the data. That afternoon we had 4 applications come in via email, proving that the back up system worked.

No JS? No problem!

My Node.js system initially used javascript to compile the form, perform the necessary validation, and then send the data to the server with AJAX. Using Express, the Node app then stored this data in the database, or returns an error code.

If however the user has JS disabled, the form would simply submit with only basic browser validation and not my additional ones, the user would be shown a blank page even though in the back-end this would have errored. I would imagine most people would understand this to mean that the form was sent, however, this wasn't the case, we wouldn't have received their data and they would never have heard back from us.

In the end I changed the node app to default to a browser redirect which sent to either success.html, or error.html. If however JS was able to run on the browser, then it would intercept the form and use the flashy JS version.

100% keyboard friendly

Despite multiple interactions on the site, I worked hard to ensure that the entire site could be navigated with a keyboard.

2018 + 2019 Extreme blue

Extreme Blue. Extreme Deadlines.

I was told at 18:00 on a Wednesday that Extreme Blue (the name for a 12 week internship at IBM) needed a website to advertise the placement to designers for the first time. By this point I seemed to be the go-to person for recruitment websites, and was asked to do something in the same fashion as the other recruitment sites I had set up. I fought back on the brief and argued that the previous intern placement sites weren't the right kind of style.

Because the site wasn't representing IBM Design I felt I could be a little more experimental in the style and be much less corporate.

There was however a catch… I had less than 24 hours. The site was required to be online by the end of the next working day.

I just called it a hackathon to make myself feel better.

Early in the day, I set myself 1 hour to design as much of the site as I could in Sketch. I decided to go extremely typographic with this in order to make the development a breeze.

This is what I ended up with in Sketch:

My first iteration was simple, with the intention of adding interactions later.

I had the main bulk of the site completed by 15:00.

I made it my mission to get some more fun pieces in, such as the scrolling title and the sketchy circles that highlight some of the text. This is because I felt there was too much text and so actually highlighting the key bits seemed like a good idea, whilst also adding to the brand.

I also wanted to add a 'countdown'. This was designed to reinforce the 'extreme' nature of the internship and the website whilst also adding function.

Fortunately the new Node.JS back-end that I had created together from the 2018 Intern Placement site was relatively easy to lift from that project and put into this new one. I was also able to adapt the code to make JS an enhancement, so again if for any reason a user didn't have JS enabled (accessibility, security etc) then they could still apply and use the site as intended.


The site was live for only 15 days, and in that time we managed to get 97 applications, which came as quite a shock. This was the first time designers were invited to join this internship and to get such a large applicant pool was fantastic!


This was a hectic year and I didn't have time to rebuild the site. We therefore decided just to update the dates and use the site from the previous year.


This year given new laws around GDPR, we opted to rebuild the site to remove the 'Peter-created back-end'. Instead IBM had provided a new portal that could be used to apply. As we didn't want to undo all the hard work we'd put in to make the application process a really low effort experience, we worked with the recruitment team so that the application form wasn't asking applicants for irrelevant data.

I updated the site to use Gatsby. This uses React which I became familiar with on the starter app project. Doing this from scratch, I learned a huge amount.

I also bundled the Extreme Blue internship into this site. Unfortunately I didn't have time to make two sites this year, so removing the tailored approach seemed sensible.