Link

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.

Advertisements

Link

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.