I'm a huge fan of Eric's writing and his general approach was reflected 
in a bunch of the original work that we did in Denver Art Museum's 
galleries. I'd recommend him to anyone in a heartbeat that's trying to 
figure out how to make some change and is frustrated by your 
institution's process. Hell, even if you're not, it's still a good read.

When I first joined DAM in 2004, before the expansion opened, we chose 
an early exhibit about the construction of the expansion to start trying 
out a slew of interface ideas and pieces of tech. There were maybe a 
half-dozen interactive bits that tested out RFID, tangible interfaces, 
oversized projections, and interactions that embedded visitors in the 
experience. They were all relatively simple in execution and we treated 
the exhibit as the testbed for more complex tech elements that we would 
develop later and, more importantly, how our visitors would interact 
with the ideas that we were proposing. Everything we did later --- 
experience, additional software, and complexity --- all iterated on 
those early tests and we constantly refined what we were doing based on 
what we were learning.

I ran the tech department as a startup in the museum and publicly 
described it as such to the rest of the senior staff, trustees, and 
outside advisors. It was very much ingrained into my thinking and we 
frequently did most of our work on a shoestring budget and with only 1-2 
people. It meant that we were able to do a fair bit of work that 
couldn't be done elsewhere at a much lower price point in the end. We 
had to build internal tolerance for iterating on projects and creating 
awareness that an opening wasn't a finish line, but instead just another 
milestone in the longer-term view that we had of tech in the museum.

I am a huge fan of just getting stuff out into the public. We can 
discuss and prototype ideas ad nauseum but seeing how visitors interact 
with something over the course of a few days will tell you far more than 
all the anticipatory discussion and wondering will do. You just need to 
be prepared to iterate, accept that all of your original assumptions 
about the experience could be wrong, and, perhaps most importantly, be 
prepared to quickly capitalize on opportunities you might see in how 
people interact.

> Nate Solas <mailto:nate.solas at walkerart.org>
> July 20, 2012 1:43 PM
> Anyone out there implementing (or wanting to) advice from Eric Ries's book
> The Lean Startup? It's been vigorously recommended to me and at a glance
> some of the ideas are pretty appealing. Especially a fan of testing before
> committing to big projects / changes, etc...
>
> Article from Wired last month:
> http://www.wired.co.uk/magazine/archive/2012/07/features/the-upstart?page=all
>
> Just curious if anyone's drunk the kool-aid? Tips / ideas / warnings? 
> Happy
> Friday!
> Nate
>
> _______________________________________________
> You are currently subscribed to mcn-l, the listserv of the Museum 
> Computer Network (http://www.mcn.edu)
>
> To post to this list, send messages to: mcn-l at mcn.edu
>
> To unsubscribe or change mcn-l delivery options visit:
> http://mcn.edu/mailman/listinfo/mcn-l
>
> The MCN-L archives can be found at:
> http://toronto.mediatrope.com/pipermail/mcn-l/

-- 

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Bruce Wyman
bwyman at teufelkind.net

Reply via email to