Nathaniel Ward

The psychology of waiting in line →

Ana Swanson:

In those early days, engineers were focused solely on efficiency — how to serve as many customers as possible without cutting into a company’s profits. It wasn’t until 50 years later that researchers began to realize that there were subtler factors influencing people’s experience of waiting in line, including ideas of fairness, mismanaged expectations, and the strange and inaccurate way that most people perceive both time and pain.


Harry Roberts’ CSS guidelines →

Harry Roberts has put together a comprehensive resource to help you organize and maintain your CSS stylesheets:

CSS is not a pretty language. While it is simple to learn and get started with, it soon becomes problematic at any reasonable scale. There isn’t much we can do to change how CSS works, but we can make changes to the way we author and structure it.


Why I switched this site to Jekyll

For six years, I used WordPress to maintain this site. I hosted the whole setup with the good folks at Site5. All in all, it was a fairly standard blog setup.

Last week, I switched to a Jekyll-powered site hosted on GitHub Pages. Here’s why:

  1. Jekyll is simple. This isn’t a complex web site. It has a few hundred posts, plus a few other ancillary pages. None of the pages require dynamic content, generated on the fly. In short, this is the perfect sort of site for Jekyll, which generates static HTML pages using simple templates.
  2. It’s a fun challenge. Learning to use the tools that underpin Jekyll—Markdown, Liquid, and Git—has been an interesting challenge.
  3. GitHub is free. Maintaining my web hosting account at Site5 cost me about $70 per year. GitHub is free, and runs Jekyll natively.
  4. GitHub is secure. My WordPress site was compromised at least twice, and was subject to regular brute-force password attacks. That led me to install an increasingly complex set of security plugins—all to protect a site I maintain as a hobby. GitHub has a security system far more robust than anything I could hope to maintain on my own.

Smashing Magazine published an article earlier this month explaining static website generation, with a follow-up reviewing four popular ones.


Don’t be afraid to fail →

Ed Catmull:

If you aren’t experiencing failure, then you are making a far worse mistake: You are being driven by the desire to avoid it. And, for leaders especially, this strategy—trying to avoid failure by out-thinking it—dooms you to fail.


How I started my testing journey

I had a big problem.

The online fundraising campaign I was running had lost steam. Instead of generating thousands of dollars a day, it was generating just hundreds.

Traffic to the website, driven largely by advertising outside of our control, had fallen off sharply. But the expectations about how much money we’d make from the site hadn’t changed at all.

In short, we had to make more money from fewer website visitors. I knew something needed to change.

My first instinct was to test different elements on the page. With a little skill and a little luck, we would find a technique that would make more money and offset the decline in traffic.

Some of our early tests showed promise. For example, we found that we could boost revenue by changing the gift amount we asked for. We also found that adding an email signup option would (indirectly) get more people to donate.

But none of this made up for the decline in visitors and revenue, which was only accelerating.

The stupidest idea I had ever heard

At this point, my friend and marketing co-conspirator Tim Kachuriak came to me with the stupidest idea I had ever heard. He had just been to a conference, and had really drunk the Kool-Aid. He was extremely excited, and that made me nervous.

His big idea was to test the existing page against a completely new version of the page:

  • Instead of putting the donation form right at the top of the page where potential donors could find it, he’d bury it at the bottom of the page.
  • Instead of including a short-and-sweet paragraph making the case for giving, he’d make page visitors wade through 700 words of copy, some of it repetitive.
  • Instead of using a page layout and color scheme that matched our branding, he’d use a bland, tan-colored page with just our logo on the top.
  • Instead of leading with the website name, to allow visitors to know where they were, he wanted a big long headline.

This “radical redesign” violated just about every fundraising and website best practice on the books.

Not only that, we’d be testing a huge number of changes at once. How would we know what caused the improvement?

I immediately told him he was a fool.

Tim persisted. He explained his rationale for the changes.

The people coming to the site may not yet be convinced that donating is for them, he explained, so we need to sell them before we ask for money. That means we need a lot more copy, to do the explaining. And that means the donation form has to go at the end of all that copy, after someone has bought in.

I wasn’t convinced, but Tim wore me down. I gave in—mostly to get him to shut up about the test already.

Turns out, my gut instinct was totally wrong

It’s a good thing I eventually caved in and allowed Tim to try his harebrained idea.

Tim’s crazy, rule-breaking page performed better than the original. Much better.

It brought in 74 percent more gifts than the existing page. Not only that, the average gift was 179 percent higher.

Combine those together and revenue from the new page was up a whopping 274 percent. That’s more than triple the money.

A new, more robust approach to testing

This result started me thinking about a new, more robust approach to testing.

In our old way of thinking, we tested one page element at a time. We would swap out one image, or one change the text on one button, or modify one headline. This approach had a major upside: because we changed just one thing at a time, we knew that any difference between versions was because of that change. But this approach was also scattershot, with no real rhyme or reason to it; it took a long time to get meaningful results; and we never learned enduring lessons.

In the new way of thinking, we would test not individual elements but rather comprehensive theories of the donor. So instead of testing a red button against a blue button, we would test a page addressed to one sort of donor against a page addressed to a different sort of donor.

This approach has several advantages, as you’ll see as soon as you try it:

  • You learn a lot more. Because you are testing fundamental concepts about our donors, you can extrapolate lessons from one donation page to dozens of others. You understand more about why a page works, not just that it does.
  • You get test results a lot faster. By combining several changes into a single test, you can usually find out awfully quickly whether your concept works or not.
  • You have more fun. In part because you are always challenging the conventional wisdom, running radical tests is awfully invigorating. You aren’t just blindly following someone else’s “best practices” and hoping they’ll work.

So what are you waiting for? Start testing!