AWeber's Web Form Generator

This is one of my favorite projects because it kind of set the bar for the type of work expected from the AWeber team.

Designing a tool that allows customers to design and publish sign up forms. Fun.

Travel back in time with me to 2009.

They say that imitation is the sincerest form of flattery and this is a pretty hilarious example.

We did such a good job building this tool that a few months later one of our major competitors blatantly copied it.

Before we go down that road, let's look at the editor itself.

Note: Eric and I lost 30+ lbs since the filming of this video... those catered lunches totally got us.

The Team

Bob Ricca

Russ Pusluszny

Eric Centeno

Dan Deming

Objectives & Goals

Provide an easy way for customers to customize sign up forms.
Provide a library of templates that are easily manipulated.
Make it easy for people to publish their new form.
Improve the way our customers think about their sign up forms.

Evaluating Success

Dramatically improve the quality of form our customers create.

About the "Minimum Viable Product"

There is a time for iterative development and there is a time for a fresh start. The concept of iterative development is pretty simple: deploy incremental changes, that over time, ramp up to a better user experience. This reduces risk when deploying and avoids alienating loyal customers who have developed usage patterns.

It wasn't uncommon to hear the term "minimum viable product" thrown around at various meetings.

Part of developing a solid product is carefully crafting which new features to pursue. It's also important to recognize that your success depends on people WANTING to use your product.

Just because you built something doesn't mean people care and as software engineers we need to constantly remind ourselves to focus on making a VIABLE product.

Let's Look At The Old Version

Gorgeous, I know...

As a team we had to make a decision:

Do we improve what is there or do we go the extra mile and create something remarkable.

We ultimately decided to start from scratch and I'm glad we did.

Identifying Pain Points

At the beginning of this project I did a lot of talking with variety teams around AWeber.

Talking with our Customer Solutions team helped bring a plethora of challenges and pain points that our customers encountered when using the interface.

They mostly found it confusing and overly technical.

I mean honestly, let's face it:

Building a web form isn't the most exciting thing.

But does it have to suck SO bad?

Some customers went as far as creating their own instructional YouTube videos to teach others how to customize their web form.

When speaking with developers around our office they would often say things like "Well if a customer would like to have a prettier web form they can always hire a web designer".

It was a mediocre customer experience at best.

Assembling the Killah Team

I feel like developing a product team has a lot of the same dynamics as starting a band.

When Eric, Russ, Matte, Dan and I worked together life was good... (even if at times we wanted to throw things at each other).

This same team went on to build our Drag & Drop Message editor a couple years later.

We all shared a vision for what web form creation could be. Communication was at an all time high and we worked together quickly.

Each morning we would have a Stand Up Meeting before we even realized what a "SUM" was.

We were also one of the first teams to utilize a kanban like system at AWeber (Pivotal Tracker). We'd work in one week sprints and host a demo at the end.

Through demoing I've learned how to prepare and present the information that matters most to key stakeholders.

Over the years I've done many product demos at AWeber. It's really quite easy when you intimately know the product.

Designing The Product

At that point in time this was definitely one of the biggest projects I've ever worked on.

Beyond creating an interface that allows a customer to design their web form to their liking, their were a lot of careful considerations we had to make behind the scenes.

Collecting Information

Creating a new form field is deceptively complicated.

Each form comes with a standard "Name" and "Email".

Beyond that, customers have the freedom to create anything they want.

This led to dig into what types of information customers might want to collect and the formate they would prefer to collect it.

For example here is what it would be like to collect information via a select box:

Here are the various states for changing the "Name" input:

Customers can pick from a variety of form inputs (e.g. text area, text input, radio buttons, select box, etc.) to do the job.

We dove into each type of input, making each intuitive to use when building a web form.

Mapping Information

So beyond the means of collecting information, what happens when the form is submitted?

Better yet, what happens if I have two web forms, each collecting the same information in a different way?

How can we make sure the data from both forms maps to the same database column?

We implemented our UI in a way that made it easier for customers to reuse the same form elements they had used in the past.

This is a win-win for both us and our customers.

By referencing a bank of previously used form elements customers have a "starting point" when building their forms, we don't have duplicate information in our database and know exactly where to store the information.

As we built the web form generator we encountered many scenarios that a customer could run into and we tackled each of them one by one.

Making Forms Look Good

At the time none of our competitors had anything remotely like our web form generator.

We knew that if our customers could generate an attractive looking web form they could ultimately attract more subscribers.

Therefore, much like our Drag & Drop message editor, templates were the backbone of our system.

We built a tool, leveraging the same interface we were giving customers, that allowed designers at AWeber to create and publish web form templates for the masses.

On the customer facing side people could pick from a variety of templates through an interface like this: