Email marketing at priceline.com was all about the data. The content we sent, design decisions, etc, which were all based around our research. There came a point, however, where we seemed to reach a bottleneck when it came to innovation and also to our ability to collect data.

We decided a new platform was needed to replace our promotional send and management processes. This became a massive project and a complete re-platforming of our technology stack.which of course meant we had to adopt a new way of thinking about how we design for our content and data. It was also an opportunity to take a step back and reassess the five w’s of our program:

1. 1Who do we send to?
2. 2What do we send?
3. 3When do we send?
4. 4Where are we sending?
5. 5Why are we sending?
6. 6How are we sending?

We had a current system in place, called Spawner, to handle sending our promotional email, but it was very slow. It was a simple PHP webapp where templates had to be built in PHP modules using vim to modify everything, source control wasn't handled in a clean manner, and it was really easy to make mistakes (especially if you weren't familiar with PHP). On top of it, sends took hours and testing wasn't any better. These were the first major issues we identified as KPIs for our next platform.

I suggested the UI and overall idea of Archer after going out and demoing some CMS platforms. From my perspective, as the end-user, something in the CMS wheelhouse seemed like it would be a great fit. I boiled it down to one term: drag and drop. After talking it over with the engineers on the team, a suggestion was made that the system should be simple enough that anyone could figure it out within 5-10 minutes. In an absolutely perfect scenario the process of building a template, sending a test, and queuing the production-ready send should be able to take someone under 10 minutes on any given day. That was our goal.

While the design and build portion of the templates was important, a decision was made to make Archer even more robust. Archer also became a data management platform. As a team, we decided that there would be no value to building a new system if it didn't have all the features we thought we'd need. So aside from just building templates and sending to lists, the UI had to mirror some backend initiatives to support building and testing queries and list segmentation, handling a more robust content library, supporting an archive that allowed us to view past sends and get some quick historical data for each individual send, a small dashboard with administrative tools for monitoring jobs and health, and changes to our sending micro-app to handle different ways and means to send our our production and test campaigns. All that came on top of concurrent feature improvements and having to manage our regular deadlines, so I decided that the front-end of Archer should be built in Sass as opposed to vanilla CSS because Sass partials would allow us to make changes and add new CSS much more easily and seamlessly.

Over time, the goal was to shift the initial burden of sending off of just our engineering team. By building a functional UI that was not as ambiguous as our previous system, we aimed to acheive that. It would allow for our team to be more flexible and also function in unison because of a shared responsibility, rather than just squarely on the shoulders of a few.

As most projects started, I sat with the lead engineer, Luciano, and my PM, Justin, and we began conceptualizing initial features. Initial features then became low-fi wireframes that we would mark up on a whiteboard or directly in Sketch. Once I was on page with the engineering phase and got the green light, I started by creating a moodboard of UI elements until we found the right combo. I scoured services like YesMail, Mailchimp, ExactTarget, and even out to Drupal dashboards, WordPress dashboards. Once a shell was assembled out of dozens of screenshots, it was time to start the Sketch documentation...and also to fire up Yeoman for a project scaffold.

Even from the beginning we all sensed that the project was going to be much larger than the initial scale for v0.1.0, so my first approach was to create a simple system. By having a system in place with documentation, it'd hopefully mean there would be less shooting from the hip for designs and also, should I not be able to do so, Luciano and the rest of the engineers could add elements to an app without potentially breaking the page. Sass allowed me to build UI snippets very rapidly and since the Archer UI was primarily an AngularJS app, the modular concept of Sass partials fit right in with new module and feature development. Plus, Sass saved me loads of time on a project for a team that never had any spare time, ever.

Archer became a monster fairly quickly. The process for building, testing, and sending was much more streamlined, but we noticed limitations immediately. It took several months to reach the milestone of sending our first production campaign and nailing down that process, but we eventually made it. We made it, but of course that meant we still weren't done. Archer required several major updates to handle some new features to handle more variants per segment, some archiving functions, and some new testing functions, but because of how we designed the application (front- and back-end) the time to release new features was measured in hours rather than days. Business decisions, user research pointing to some new conclusions and test ideas; many things started rearing themselves almost immediately.

The remedy came in the form of an agile framework. It was a late-bloomer in our organization, but we adopted one to meet the demand of the business, our customers, and our own ideas.

The application is still a monster, much larger than I originaly thought it might be, but it was very fulfilling to work on it. The amount of positive impact it drove was incredible and it allowed me to learn so much in the process.

If I can recall correctly, in about 2 year's time, Archer went through 6 major version releases, at least 400 new feature and minor releases, and an insurmountable amount of minor updates. Examples of major features added since v0.1.0 that became huge wins:

• —Dummy API calling to test content more rapidly
• —Full export of campaign historical data and variant HTML
• —Time testing; ability to schedule a send for a future time while still segmenting a list in the present
• —Sending 1:1 vs sending at scale, for more personalized content
• —Bucket sending; ability to segment customers into buckets based on specific parameters on a daily basis
• —More robust version control of HTML/CSS modules

As I said, those are only examples...specifically it's a really really small sample set of what we built. We gathered data from our customers and from other endpoints and used it to our advantage. All decisions we made, and the ones made going forward, are made with the customer in mind and with the goal of delivering the best experience to them. I can't help but use the cliché: Archer hit it's target.