Best Practices

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

/ Sandy Smith / Leave a comment

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.

More Unicorns: Prototypes

/ Sandy Smith / Leave a comment

Here’s an interesting post about that rarest of all creatures, the Unicorn prototype.

I’d say that in the nonprofit world, it’s more a Flying Magic Unicorn Pony, as it essentially never happens in agency contracts with nonprofits. There are several reasons: often deliverables are spelled out in advance, budgets are unbelievably tight, and there’s a lack of trust if an answer isn’t immediately available–”I don’t know” isn’t accepted, by and large. That lack of trust extends to the idea that prototyping time is “wasted” if it’s not to be used in the final product.

What works better is an agile process where an idea can be tried out in a sprint. That requires some preconditions and a mindset that I’ll expand on in a future post.

In the meantime, prototypes can work in nonprofit engagements under very specific circumstances:

  1. The requirement wasn’t in the initial discussions for the engagement, so it’s a legitimate surprise to the agency.
  2. The prototype is incredibly focused to answer a yes/no “will this work with the technologies we’ve selected” or “will this work within the budget we have” question, rather than a “do you like it” or “will users respond to it” question.
  3. The prototype can be done in less than a day’s time.
  4. Resources exist to do the prototype immediately.

Ideally, the prototyping can be done internally to the web team without involving the larger circle of stakeholders.

Given those requirements, it’s not too surprising that it’s a rare-to-mythical beast. However, they can be a powerful tool, so if you can make room in your budget, they can free you from either getting an adequate but less than ideal site due to enforced conservatism or getting a feature that becomes a maintenance nightmare as attempts to fix a fundamentally wrongheaded approach are slapped one on top of the other until the whole thing is written off as a failure.