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
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. I wrote narratives for
“Rita the Reader” “Johnny the Reporter” and “Harry the News
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.”
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. The process included working with two individuals who
took my narratives from step one and the working examples from step two
and giving it a user interface. Having the wiki up as a concrete
example only helped.
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.
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… at least for now.
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
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
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.
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 REALLY long 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 that couldn’t turn. 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
can better capture
it. My first advice: Don’t prescribe the topic (which AZ
did…”crowdsourcing”), stay open and fluid and remember technology comes second behind community organizing. 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.