When Requirements And Design Lose The Sale

Here’s a great example of how feature requirements and design have combined to cause a lost sale. Some background: This is the donation page for the Presidential candidate I support. I’m not getting into who it is; those who know me personally can probably guess, and those readers who don’t can visit candidates’ donation pages until they find this example.

I’m your typical semi-involved voter: I care a bit about local policitics, I try to vote in every election, but don’t always make the smaller or off-year ones. But I do care about state and national politics, and since I live in *the* quintessential swing state, I feel like my vote actually matters.

This morning I received a call-to-action email asking me to donate, and followed the link, landing at the page you see (in part). I noticed the “Make this a monthly recurring donation” checkbox, and immediately thought “Awesome! That’s what I want to do!” I figured it would be easier for me to just automagically kick in $25 per month until the general election was over. So I ticked the box, expecting to get one of those “For how many months?” dialog or AJAX partial page update. Nope. Nothing. Which sucks for the candidate and party, because I – and I suspect many, many other small donors – only want to make a recurring donation until the general election is over. And if I can’t do this – or easily figure out how to do this – there is no way I’m setting up an autopayment.

This is a classic failure of the product managers and designers to understand the customer. They may *want* me to set up an autopay in perpetuity. But I guarantee that most small, semi-involved donors most certainly do not want to do this.

Lesson: Learn what your customers want from your product and what their motivations are when they use it. Wishful thinking about user behavior is not a good way to meet their wants and needs.