The Importance of Being Iterative - Eliminating the Fear of Being Open
Spot.Us is about to hit the ground running. We hope to have something to show in mid-to-late October (assuming everything stays on schedule).
We've gotten here through a couple of stages. The Cliffs Note version of that is as follows.
Stage one: Narratives
After realizing Spot.Us would become a reality I got writing. Essentially this was a chance to toss ideas around and create a vision for the site.
The basic approach was: Define the types of users that would interact with spot.us and then write out their experience of the site - and what they'd see on each page of the site. I wrote narratives for "Rita the Reader" "Johnny the Reporter" and "Harry the News Organization."
Stage two: Test and Design
This was when spot.us became more public. It included using cheap tools (a wiki and a blog) to try and get a caricature of how the final site would work. See "Starting Small and the Importance of Being Iterative" and "Growing a Community and the Importance of Being Iterative."
This included the SF Election Truthiness Campaign, Ethanol Investigation and more. If spot.us is "just an idea" this was an attempt to see if it had merit.
The beauty of this phase: If I couldn't make it work using a wiki and a blog - I'd have some serious re-thinking to do.
Design: I've tried to be fairly public with the emerging designs - but it essentially included working with two individuals who took my narratives from step one and the working examples from step two and turning it into a real site. Having the wiki up as a concrete example of the narratives didn't hurt either.
Along the way - the designers (Jonathan and Anthony who are awesome) questioned my assumptions, brought fresh perspectives, etc - so the process itself was iterative and required daily check-ins and the ability to turn on a dime (change my mind about assumptions).
Stage Three: Development and scaling I'm working with HashRocket for development.
Their 3-2-1 process sounds like making a site is incredibly easy, but I suppose that's the marketing trick. Truth is - if you come to them without having gone through stage one and two above (each take anywhere from 1-3 months) they won't be able to help you. Or, what is probably more accurate, they'll help you - but your expectations must be lowered since you haven't set them in a deterministic fashion.
It should really be called 60, 59, 58, 57....1 - but they don't come in until the last moments - when all that's left is to turn the vision into a functional site.
As you can see - it's not dissimilar from Startup Weekend, which you can learn more about from Andrew Hyde.
With HashRocket step one was to translate the designs back into narratives, this time with a programmers perspective/language. Every button, action, view, must be turned into a "story."
Learning to work within restrictions
The hardest part of this process is leaving things on the cutting room floor. We've designed an intricate site with a lot of moving parts and a large scope. Of course I'm attached to every link, line and action we designed, but the fact is - you can only get so much code shipped in such a short period of time. I've had to scale back.
The silver lining is that restrictions force one to cut out "niceties" and really focus in on the core functionality of your site. The question I'm forced to ask with every feature is: what is needed right now for launch? This restriction, although painful for me is probably very healthy. I won't suffer from mission creep in this early stage - I simply can't afford it.
Spot.Us is not waiting for a "ta-da" moment. The site will, hopefully, never be "finished." It will constantly evolve. That's partly why I feel comfortable leaving things on the cutting room table. As the site grows, I'll find out what users need/want and then I can easily look at the functions we left out to see if any answer those needs. But at least I'm not trying to prescribe or predict what users will want/need from the start. The fact is - you never know how people will engage and use your site. That's why you must release early and release often.
I'm sharply contrasting my experience building Spot.Us with Assignment Zero which many people will remember as a highly anticipated experiment in networked journalism from mid-2007.
While
I'm trying to keep spot.us as an organically evolving project that is
light with a reasonable turning radius, simply building Assignment Zero
ballooned into a massive undertaking that was done behind closed doors
(despite the best of intentions). When AZ launched it turned like a battleship. (I could talk for hours about my AZ experience. I look back at it fondly, but at the time between grad school and AZ - I was working 20 hour days)
Fear of being open disappears
I don't think fear was the reason why Assignment Zero was done behind closed doors and turned into a massive battleship with slow turning. It was more because we were trying to grasp at something that hadn't been attempted before. We had no clear vision of what would happen other than people collaborating on journalism. I hope projects like IAmNews can better capture it. My first advice: Don't prescribe the topic (which AZ did..."crowdsourcing") and stay open and fluid. I would love to see a successful example of networked journalism. To date - I'm left wanting.
On a regular basis I do hear people that suggest the reason they haven't gone public with their idea is the fear that somebody else will take it. Let that fear go. You can hoard your idea, spend all kinds of time and money trying to predict what users want - but until you freely reveal the idea, you'll never know. The idea might not have a market, might not have a good user-interface, might not be able to grow a community, etc, etc, etc. The only way to find out is to determine the path of least resistance and start.
As journalists become more and more independent - I hope this becomes a regular practice.
