Design for Behavior: Part 2

Twice last year, I had the experience of putting together SocialDevCamp East, a barcamp-style unconference for software developers and entrepreneurs focused on social media.

Sounds straightforward enough, but that sentence alone is jam-packed with important design decisions. And those design decisions carried through the entire event, and even into its long-term impact on our community and our community’s brand. I’ll explain.

Barcamp-Style Unconference

In the last few years, the Barcamp unconference format, focused on community involvement, openness, and attendee participation has gained a lot of traction. I won’t write a ton here describing the format and how it all works as that’s been done elsewhere, but the key point is that this is an open event which is supported by and developed by the community itself. As a result, it is by definition designed to serve that community.

So what are some other design implications of choosing the Barcamp format? Here are two big ones.

First, anyone who doesn’t think this format sounds like a good idea (but how will it all work? what, no rubber chicken lunch? where’s the corporate swag?) will stay away. Perfect. Barcamp is not a format that works for everybody – particularly people with naked corporate agendas. It naturally repels people who might otherwise detract from the event.

Second, the user-generated conference agenda (formed in the event’s first hour by all participants voting on what sessions will be held) insures that the day will serve the participants who are actually there, and not some imagined corporate-sales-driven agenda that was dreamed up by a top-down conference planning apparatchik three months in advance.

The fact that there are no official “speakers” and only participants who are willing and able to share what they know means that sessions are multi-voiced conversations and not boring one-to-many spews from egomaniacal “speakers.”

The Name: SocialDevCamp East

We could have put on a standard BarCamp, but that wasn’t really what we wanted to pursue; as an entrepreneur and software developer focused on the social media space, I (and event co-chairs Ann Bernard and Keith Casey, who helped with SDCE1) wanted to try to identify other people like us on the east coast.

We chose the word Social to reflect the fact that we are interested in reaching people who have an interest in Social media. It also sounds “social” and collaborative, themes which harmonize with the overall event.

We chose the wordlet Dev to indicate that we are interested in development topics (borrowing from other such events like iPhoneDevCamp and DevCamp, coined by Chris Messina). This should serve to repel folks that are just interested in Podcasting or in simply meeting people; both fine things, but not what we were choosing to focus on.

Obviously Camp indicates we are borrowing the Barcamp unconference format, so people know to expect a community-built, user-driven event that will take form the morning of the event itself.

We chose East to indicate that a) we wanted to draw from the entire east coast corridor (DC to Boston, primarily), and b) we wanted to encourage others in other places to have SocialDevCamps too. Not long after SDCE1, there was a SocialDevCamp Chicago.

Additionally, our tagline coined by Keith Casey, “Charting the Next Course” indicates that we are interested in talking about what’s coming next, not just in what’s happening now. This served to attract forward-looking folks and set the tone for the event.

The Location

We wanted to make the event easily accessible to people all along the east coast. Being based in Baltimore, we were able to leverage its central location between DC and Philadelphia. Our venue at the University of Baltimore is located just two blocks away from the Amtrak train station, which meant that the event was only 3 hours away for people in New York City. As a result had a significant contingent of folks from DC, Baltimore, Wilmington, Philadelphia, New York, and Boston, many of whom came by train.

Long Term Brand Impact

These two events, held in May and November 2008, are still reverberating throughout the region’s community. At Ignite Baltimore on Thursday, SocialDevCamp was mentioned by multiple speakers as an example of the kind of bottom-up grassroots efforts which are now starting to flourish here.

The event has the reputation of having been a substantive, forward-looking gathering of entrepreneurs, technologists, and artists, and that has gone on to color how we in the region and those in other regions perceive our area. Even if it’s only in a small way, SocialDevCamp helped set the tone for discourse in our region.

Design? Or Just Event Planning?

Some might say that what I’ve described is nothing more than conference planning 101, but here’s why it’s different: first, what I’ve described here are simply the input parameters for the event. Writing about conference planning would typically focus on the logistical details: insurance, parking, catering, badges, registration fees, etc. Those are the left-brained artifacts of the right-brained discipline of conference design.

Everything about the event was designed to produce particular behaviors at the event, and even after the event. While I make no claim that we got every detail perfect (who does?), the design was carried out as planned and had the intended results. And of course, we learned valuable lessons that we will use to help shape the design of future events. Event planners should spend some time meditating about the difference between design and planning; planning is what you do in service of the design. Design is what shapes the user-experience, sets the tone, and determines the long-term value of an event.

More to Come

I’ve got at least 3 more installations in this series. Stay tuned, and I’d love to hear your feedback about design and how it influences our daily experience.

WARNING – GEEK/PHILOSOPHER CONTENT:  It occurs to me that the universe is a kind of finite-state automaton, and as such is a kind of deterministic computing machine. (No, I was not the first to think of this.) But if it is a kind of computer, then design is a kind of program we feed in to that machine. What kind of program is it? Well, it’s likely not a Basic or Fortran program. It’s some kind of tiny recursive, fractal-like algorithm, where the depth of iteration determines the manifestations we see in the real world.

As designers, all we’re really doing is getting good at mastering this fractal algorithm and measuring its effects on reality.

See you in the next article!