Your Users Don’t Know Their Requirements Until They See Them

In my previous post, I explored the dilemma of a service organization creating a website or web application: while you’re the one whose goals the site has to support, you aren’t the ultimate user of the site. This isn’t unique to nonprofits and government, but it is harder because there’s no easy metric like sales to let you know how well you’re doing. If you’ve figured this out, congratulations! You’ve gone a long way toward making your site successful by focusing on the end user. But there’s a problem: your users can’t often tell you what they need, and when they tell you what they want, they’re likely to unintentionally lie.

Humans are notoriously bad at predicting what they will respond to. That simple fact has given rise to parts or all of the fields of behaviorism, psychology, user experience, efficiency, human factors design, and psychometrics. It turns out that we often state what we’d like to be true of ourselves and then do something different when forced to act. Economists have a term for this: revealed preference. The upshot is that we’re really bad at doing something like looking at a wireframe or design for a website and accurately predicting how we’d use it and if it will solve our problems.

Agile methodology illustrationSo how do you create a successful website if you can’t test it on yourself and you can’t simply ask users what will work for them? There are of course general principles of user experience, and any good developer should steer you toward them. But those principles are notoriously hard to apply perfectly in every case. Fortunately, the software world has been aware of these problems for some time and has developed several methodologies to help, collectively known as Agile.

Even though details vary, all agile processes share one insight in common: users don’t know what they need until they try working software and their requirements change quickly over time. The goal is to quickly get out the most important features to users and let them begin working with them, and use metrics and usability tests to assess how well that version is working. By doing this over and over (iteratively, in Agile terminology), you can make small changes, measure their impact, and change accordingly until you get the feedback you want.

This is a big mind-shift from how nonprofits are used to operating, but it’s one that can make the difference between a website that you can demonstrate to funders actually fulfills its mission versus one you simply hope gives you good results by the next grant application. I’ll explore some of the challenges in adopting it unique to nonprofits in a future post, but meanwhile, Google and this article can get you started on understanding how selecting a developer who uses an agile methodology will make your project more successful.

This month, be sure to check out my company’s Kickstarter campaign and consider backing us: we’re developing two new productivity tools that will help non-profits.

Help Kickstart BubbleSorter and GridSorter

I’ve always been careful to say that my new company, Musketeers.me, is a consulting and product company. Today we’re getting closer to the second (but to us, first) part of our mission. We’re launching a Kickstarter campaign to build two products: GridSorter and BubbleSorter.

GridSorter

GridSorter is best explained by relating the story of how Eli White first created the prototype: ever have a list of things that need doing around the house? Or worse, a honey-do list? Eli had that problem, and he’d already ranked everything by most important to least important. The problem was that when he had some spare time, he would look at the first thing on the list, which was a weekend-long project. So he’d put it down, and go do something else instead, and nothing was getting done. He quickly realized that he needed to categorize his tasks by both how long they’d take and how important they were.

Being a programmer, he naturally sat down and hacked out a solution: put his tasks on a grid, with one axis being importance and the other axis being time required. So now when he had an evening, he could simply look down the “takes an evening” column and grab the first task off the list, knowing he was getting the most important thing he could do with that time.

We’ve realized that a lot of you might have that problem, and the principle is even more powerful than just tasks versus time: you might have any number of things you need to sort by two different categories: for mojoLive we categorized our last push of features by importance versus user engagement, and picked the most important features that would also engage users. So the final product will have the ability to pick your two categories and drag and drop your list accordingly.

BubbleSorterBut what if you’re having trouble figuring out what’s important? Once I was trying to get a client to give us a prioritized list of tasks so we could ensure we did the most important things first, since the budget was tight and the list was long. They came back and said, “Well, everything here is Priority 1.” Not too helpful. But when I started asking, “Would you like to put more effort into Feature A or Feature B?” the client would quickly reply, “Feature B.” Out of that inspiration comes BubbleSorter.

While even just bringing in a list and prioritizing it is useful—and we’re going to give you that for free—it’s really useful when you have groups of people who are having trouble agreeing on a list of priorities. So for a low yearly subscription, you’ll be able to invite others to come in and perform the same ranking, and then using an algorithm we’ll be able to tell you what the group’s collective priorities are. This is really powerful if you’re regularly trying to get consensus in teams.

So help us make these products a reality: watch the video, see what you will get for each backing level, and join our Kickstarter.