Several of the folks on the DesignMap team were lucky enough to attend ExactTarget’s Connections conference last week. It had everything you’d hope from in a conference — breaking news (CoTweet giving facebook some love), sought-after speakers (Virgin’s Sir Richard Branson), and giveaways (Red Bull giveaway kicking off hours of keynotes: brilliant). One thing we were thrilled about in a more exiting way than was strictly desirable was the demo of software, software that we helped design, mind you, live. In front of 2,000 people. ExactTarget was giving a sneak peek of the Interactive Marketing Hub, their new integrated platform for social media, multi-channel marketing, on-demand data management, and process automation. Did I mention it was live?
Now there are all kinds of reasons not to build live software for a demo. Obviously it’s not entirely dependable. Unless you have dedicated prototypers, your developers may slow development for the demo because they won’t be able to throw out all their good habits for writing production-ready code. Designers will be designing in a hurry, and in spite of all best intentions to revise, the temptation will be too great to declare victory with the demo. And it requires some long, hard hours and a high tolerance for caffeine and adrenaline.
And I’m not afraid to admit it: Frankly, I thought they were crazy. It can happen to the very best. Why risk it? Knowing that it will be a month, or two, or more before your audience sees some of the things you’re demo-ing, they also know that what they’re seeing now won’t be exactly what they get later. So why go so far out of your way?
After attending the conference though, I’m glad they weren’t listening to me. We got one of the biggest treats a designer ever gets: We got to see our work… working. Stuff we designed. Built. Running. Up on the big (BIG) screen. We work hard to make sure our design work sees the light of day, collaborating with customers, engineers and product managers to make sure we’re not doing something we just “throw over the fence”. We want to be part of a team that designs something viable, feasible and desirable, as Larry Keeley describes it. And if, as development commences, any one of those attributes falls short, we are around to right it. But it doesn’t always happen; whether you’re an internal designer or external, company strategies change, new initiatives become priority, staff turns over… And if the design does get released as a product, it may be different, or it could be months before it sees the light of day. Agile and strong product management has reduced the risks over the last few years, but still it was a thrill to see something being designed just last week, up and really running in front of a crowd.
And they were thrilled too. Knowing it was live code, with attendant hiccups (which got nothing but positive tweets — I’m thinking those should be scripted to happen if they don’t happen by themselves), adrenaline and real-time live-to-your-phone demo got everyone excited in a way that absolutely wouldn’t be possible with Flash. It showed guts, it showed off the strength of their engineering team, and it made tangible the value of the IMH because you could see the promise in action. In particular, the staff that worked on it were on an adrenaline high afterwards that seems to be sustained a week later as a lot of bouncy, happy engineers and product managers, and a stronger sense of camaraderie.
So hats off, ExactTarget. Congrats on an awesome conference, and thanks for reminding us about the value of adrenaline.