Before starting research at BT, I’d never heard the term ‘demonstrators’ used to describe the deliverables of a research project. Getting to grips with the idea has given me a valuable insight into the differences between ‘intrapreneurial’ innovation in corporate contexts, and the gung-ho prototyping I’ve been involved with in many arts/technology/entrepreneurial ventures.
I got a chance to see a variety of demonstrators at a recent BT Innovate and Design ‘Deep Dive’ event, where all the geeks put on suits, polish up their wares, and come and present them to a mix of management/strategy types and other geeks.
For the hardware/infrastructure demonstrators, there were some big green BT link cabinets (such as you sometimes see hanging open, with vast spaghetti tangles of copper twisted pair bulging out) – updated with the latest in fibre coupling systems. Then there were cross-sectional fibreglass models of brick walls, showing how domestic fibre channels could be installed. Those kinds of demonstrators felt a bit like playing in the launchpad at the Science Museum.
For Software demonstrators, the killer apps seemed to be Flash and powerpoint, because they seem to be the most effective ways to illustrate the concepts and proposed functionality of consumer technologies to a broad base of management/strategy people, with varied levels of technical knowledge. {{1}}
The product our team demonstrated in this context was built in Adobe Air/Flash, with a Processing back-end server – which was effective at demonstrating the possibilities of a second screen application for playing, pausing, text chatting and audio-messaging between users of a SocialTV system.
When I had first seen it, and read user test reports, I hadn’t immediately understood what could be learned from the results. The demonstrator literally only did four things: pause, play, send text message and send audio message. I was interested in how users behaved, how they misused or adapted the technology, which wasn’t really possible with such a limited device and such a proscribed mode of use.
Then yesterday I saw this:
GOAB. A TV Experience Concept from Syzygy on Vimeo.
Which basically compiles all the Social TV functionalities and features I’ve seen built or speculated about so far. It’s really very slick, and (as far as I can tell) entirely vaporware-enabled, which is a very good way of communicating to lots of people and testing a market without the complicated and horrible job of actually building any software.
So what I was missing is that ‘demonstrators’ should be seen as mostly non-functional props, designed to make it easier to communicate the possibilities and marketability of certain technologies. Whether they *actually* work or not is immaterial.
Another gem (or mine full of gems) from recent research was the Notube project, which involves my much admired semweb veteran friends Dan and Libby, which has involved building all kinds of prototypes – but not, explicitly, any products. Libby wrote about that very interestingly, after being badgered by product-hungry trade-fair attendees. Her post, which brings up lots of very useful user-centric patterns for Social TV from her previous work at Joost, helped me to understand the different applications of prototypes and ‘demonstrators’.
Dan also pointed me to this  beautiful demonstration of one of notube’s prototypes, using the new Universal Controller for Mythtv built by Steven Jolly, James Barrett and Matt Hammond at BBC R&D. This is the kind of stick-figure prototype I really enjoy: plain and uncomplicated on the outside, but actually rather elegant and complex on the inside.
So, before diving into making, I’m glad I clarified this for myself:
You build a protytpe to learn something about how users and systems behave. You build a demonstrator to learn about how people and organisations react to your product.
In terms of my research, I’m more interested in finding out how users and systems behave, so I’ll be building some prototypes, and not worrying too much about making them look slick.
[[1]] This wasn’t the case for some internally-focused applications, which were basically fully functional systems intended for use by BT and it’s partners for cost-saving/efficiency systems, or the Saturn Project aggregator/classifier for threat detection and analysis from fuzzy data.[[1]]
Thank you for your post.
Do you use different names for different prototype stages?
In my company, people get confused because there are 2 very different prototype categories:
1) “grubby protos”, “immature”, “investigation-oriented”, “early-development”, “choice makers”, fragile, ugly, “basic”, which we would mostly torture internally in our labs and certainly not good or slick enough to go to customers, where they would spoil our reputation. (Some here use the name “Demonstrators” because they are used to demonstrate/fine-tune each feature one by one … which is not a proper name since I read your post ✔) These get many iterations, that’s normal.
2) Eventually come the “final protos”, “conclusions”, “confirmatory”, “twin to commercial”, which will go to customers, expected to yield satisfaction and confirm the previous phase. The target there is that one version should be the final one, no iterations is an indicator of good upstream work.
Then we go to pre-serial and the pathway to launch.
To avoid confusion, how would you neatly name those two “prototypes” since they are so different?
Thank you for the light you could bring