Month: August 2012

You Don’t Know Your Requirements, Your Users Do

/ Sandy Smith / 3 Comments

One mistake a lot of organizations get drawn into is focusing on the organization’s requirements on a website. No, really.

It seems like a strange sentiment, because why else would you build a website or application? The problem is that when you circulate requirements for the website, people focus on their own jobs and what would best represent how they think about their job. What they often don’t do is focus on the organization’s goals.

Your goals and your requirements aren’t synonymous by any means. Requirements are often just a wishlist of features collected piecemeal by people who take a moment to think about what they might want a website to do before going back to their main job.

The problem is, unless you’re building a site for use by your employees, they aren’t really the users of the site. The people the organization is trying to reach are the ultimate users of the site, and its their requirements that should drive the features of your website or application, not yours.

Instead, you should start with a list of your goals generally as an organization, and then the goals you have for the website. Those goals are the ones that usually triggered the decision to invest in a site or application in the first place, such as increased engagement with volunteers, reaching out to a broader base of smaller donors that aren’t feasible by traditional means, or convincing a key demographic that they should support a policy.

The goals for the website should logically support one or more goals of the organization. Goals are the “why”, and requirements are often the “how.” The tricky part is that each person in your organization also has a job that supports your organization’s goals. (Well, they should, right?) The tricky part is that the requirements they have to do their job better don’t usually map very well to what the ultimate users of your site will need to support your organization’s goals. So simply collecting their requirements and turning them into an RFP is a recipe for a site that makes everybody internally satisfied, but goes over with a big thud with the people you’re trying to reach.

This is another reason it’s a good idea to approach web developers with problems rather than solutions. The problem you have is that you have goals and you need to use the web to help you meet them. It’s the web developer’s job to help you figure out how to do that. Your staff should certainly be involved, but they have jobs of their own and shouldn’t be specifying your website for you.

This approach can also prevent some political problems, as specific requirements related to jobs can be conflicting, and wish lists are inevitably larger than budgets. Getting everybody’s input on goals and feedback on proposed solutions is easier than dealing with hurt feelings when a cherished feature doesn’t make the cut.

There are several techniques for getting to the heart of what users need, and they get to the heart of better ways to work with web developers. But by remembering the end users are the ones who hold the key to getting the right requirements for your site, you’ll set yourself up for success, and potentially avoid some internal conflicts.

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.

If you bring your developers in house…

/ Sandy Smith / Leave a comment

While much of my advice is for organizations dealing with outside contractors or web development agencies, many organizations choose to actually hire web developers. If you go that route, I suggest reading this excellent post by Laura Thomson on managing engineers. Engineers are like other skilled white collar professionals, but more so in many of the ways that reward manager-as-servant mentalities.

You’ll also need to hire them, and this post at Autodidacticism, while aimed at developers, covers the non-techical things you’ll want to look for in an engineering recruit. Much of the theme of this blog is that both developers and those working with them forget that success depends a lot on non-technical factors that the myth of technology as magic and engineers as robotic, mysterious, yet interchangeable resources obscures.

Present the Problem, Not the Solution

/ Sandy Smith / 3 Comments

“How hard would it be to make a button…”

I can’t tell you the number of times I’ve heard sentences start with those exact works from clients. Early in my career, usually after the initial delivery of a beta, I’d get that question. I’d listen to the whole thing, put my head down, maybe ask a couple of questions about the details, think for a moment, and then come up with an estimate. Since I’m a pessimist, unlike most programmers, that number would often dissuade the client from proceeding.

After a few rounds of this, they’d complain that we weren’t as responsive as we were in the initial engagement. At first, that puzzled me. Our response time was usually just as fast, and in fact sometimes I was giving the estimate live in the meeting. They’d respond we weren’t as “flexible,” which I took to mean they were getting sticker shock and wanted the rate of feature delivery they got in the main site development even though they didn’t have a fraction of the budget.

Listening past the question

Over time I realized that’s not really what they meant. What they really meant is that we weren’t engaging with the same level of problem-solving we were in the initial engagement. In some ways, that wasn’t fair: in the initial site build, we often had strategic goals, long discussions about what they wanted, what their workflow was like, and how we could adapt the technology to meet their needs and stay within the budget. We were in contact several times a week and got updates on changes at their organization quickly.

Once the main site was done, that level of awareness was gone, so when they’d come out of the blue with a request, my automatic customer-service response was simply to answer the question as asked. Once I figured out they were frustrated with several rounds of that, I learned to listen past the question and instead of asking details, follow up with, “What’s the problem you’re having now that this would solve?”

Overcoming literalism

Unfortunately that’s not an insight that comes easily. Not only does it take experience, it takes a certain mindset. Junior people haven’t learned it yet, people from a sales background want to get an answer back quickly above all, and programmers are notoriously literal-minded and don’t often think about the meaning behind what is being said.

On the organization’s side, it’s also easy to get caught up in “feature fever,” especially as you start to understand the possibilities of web applications and how they can make your life easier. It’s incredibly tempting to envision a magic easy button that solves your problem. The only hangup is that while it looks like the flying magic unicorn pony simply drops elements on a page and they are easy to use and work perfectly, it actually takes a great deal of user experience and engineering skill to make a site function naturally and intuitively.

So the best defense against a good relationship going sour is a good offense: ask your web developer or agency to propose solutions to your problems. Explain to them the way you are doing things now, whether online or offline, let them know where the pain comes in, and ask them if there are any ways they can think of to simplify that. Often even the most inexperienced, literal developer will brighten up and say, “Oh! Yeah, we could just…” and suggest not only something that solves the problem, but solves with the least cost to implement, because good programmers are lazy.