A modular system for testing landing pages

Lately I had to design quite a few landing pages for a client project aimed at validating a number of product propositions. Now, I don’t know about you, but I really hate web services like Unbounce (sorry), with their clunky editors and drag and drop system which always feel like a bad compromise between fine control and ease of use.

A second way

A good alternative if you are happy to code a little, is building your own templates from scratch. Pick your favourite framework, and start putting it together. Fun right? Well, it depends.
In my case, we had to test really different concepts and consequently the landing pages needed quite different layouts, looks and feel. So coding each of them from scratch while certainly possible, wasn’t ideal. If in the past you have been creating enough different templates over time you might have enough of them to pick from, but chances you haven’t (I’m sure I didn’t). So back to the drawing board.

A third way

Now hear me out. What if you could have a set of building blocks that define the different parts of a landing page and all you need to do is pick the one you need and dump them in a loose HTML layout? What if those blocks where designed to be multipurpose and reusable so that the same component can be applied across the page with very different results?

Cool right?

Mapping it all out

I started looking online for examples of different landing pages, collecting them on Pinterest in order to then deconstruct them into possible building blocks I could try to recreate in my modular system. When selecting examples I was following 2 key principles:

1. Layouts need to be rather simple
   If you are creating a landing page specifically for click testing, fancy looking layouts are actually counter productive. You want to gauge people’s opinion of your offering, and not judge your (incredible) design skills. The message is what counts not the looks.
2. It needs to be some kind of digital product or service
   Sorry for the bias, I work in digital so there you go. In my experience there are some unspoken rules about designing landing pages for click testing. A clear message at the top, probably some sort of feature list, things it can do, maybe some social proof and definitely a pricing section.

Deconstruct and understand

With enough examples to draw from I started deconstructing the pages into high level sections and their blocks.

Section are what define the architecture of a landing page. It’s how you tell the story of your product and how your user-tester discovers your proposition. Starting from that I then derived some building blocks that make those sections.

So, for example, a landing page will probably start with and introduction of some kind, setting the scene and introducing your main proposition. Looking at the examples collected you can say that an INTRO section is usually composed on one, if not all of the following components:

• A headline
• A subhead
• One or two CTA (no, you can’t have three)
• An image of some kind

By playing around with these three you can replicate pretty much all ‘introduction’ section of most of the landing pages around.

Example of of some INTRO sections

A introduction could be then followed by a section showing some very important features or benefit the product has to offer. A KEY section could have:

• Two or more icons/screens/visuals of some type of features or key benefit
• A short block of text for each icon/screen/visuals
• A CTA to find out more or a similar action for each

Examples of KEY sections

I went through this process using the examples collected as a base until I had enough to start building things out.

Building it out

To begin I needed a system with which I could code the individual building blocks that make up the sections, so that I could then put them together into a loose HTML template. That template would then be assembled into the final landing page. In nutshell I needed:

• a web framework (Zurb Foundation) on top of which I could create my building blocks (Handlebars).
• a way to fill those blocks with the right content (JSON).
• a way to assemble automatically the pages and spit out an HTML page (Gulp.js).

With those tools ready I started prototyping a landing page based on a design I previously worked on for VETS, a veteran employment online platform.
If you look at the layout of VETS landing page you can see its section structure.

The INTRO section

The INTRO is a pretty straightforward component to build. Looking at it from a design perspective I figured you need to be able to set the component the way you want and that means deciding if you want one or two buttons, a header or even if you want everything to be aligned left, right or centre.

And this is where JSON and Handlebar do the real magic. By controlling the classes of each HTML element you can control the way each block looks (using CSS classes) and the way it’s organised on the page (using Foundation classes).
Finally Handlebars also allow us to inject any text we so choose in the page.

See where this is going?

In this example JSON is feeding Foundation classes for grid alignment as well as specific copy for a header to Handlebars

Going back to the INTRO section I am designing, by use of Foundation and CSS classes I can create 12 different building block from the same component. It’s all about putting the JSON data in the way I want it and that’s it.

What’s really cool about this setup is that by omitting a line of code you can have a component of the building block disappear. So if you want to have no sub-header simply leave it empty and it won’t render once assembled with Gulp.js. How cool is that???

The KEY section

To show you what I mean let’s try with the KEY section. The building block I coded in Handlebars has space for a header, an image with some text and a button. But for VETS I want the buttons and the header to go. So I put the text I want to appear in JSON, select the classes I need to align stuff around, ignore the buttons and header’s parameters and I what I get is three nice looking key benefit of the VETS platform.

Let’s take this further. I want to have the following section showing some companies logos. I take the same building block, keep the header and just give it some images. With the same identical component I got a new section and you wouldn’t even noticed it’s the same block of code if not for the fact I just told you.

As a matter of fact almost all of this landing page is built using this very same building block (aside from the carousel and the nav which are they own separate components).

Conclusions

This is an ongoing side project I started to put together after sketching some ideas down on my notebook. The VETS page was a first attempt at putting some of these ideas to practice. The next steps for me are:

1. Building more components and testing them with some new landing pages.
2. Making the Handlebars components even more modular, with more control on classes and so forth. Basically figure out how much flexibility and control can I get just by using JSON with Handlebars.

If you read this and have some comments I’d love to hear it from you, so comment here or contact me directly.