I think I've aged about 20 years in the last month or so because I feel like I've just gotten super preachy, which is somewhat annoying, though probably less to me and more to the people to whom I've been preaching. I don't know, I feel like all these thoughts, observations, and opinions have sorta been brewing over the last while and I've decided I need to start recording more of my internal monologues, not that they're any good, but it gives me some talking points if in the future I ever end up talking to anyone who's listening. So that said, you can probably guess this isn't going to be a very technical post, but hey, I'm at Eye-O! Trust me, there will be tons of technical musings coming...Plus, I'm going to use a lot of marketing/businessey terms, for which I am also truly sorry...don't hate me, my friends (or do, i suppose).
We deliver all three, yo...
You get to that point sometimes where you've had a bunch of related conversations with different people and it all adds up to one conversation, or at least, it would be more efficient and probably effective to just have the whole conversation rather than have bits and pieces with different people. It's definitely been that kind of week/month/year/etc. I've been thinking, talking, trying to practice, etc what being a rapid experience developer, interaction prototyper, interactivist, whatever you want to call it, etc, and I don't think I've quite succeeded yet. Most of that is probably due to the fact that I've spent more time being an evangelist, educator, excel jockey, etc, otherwise not really an experience developer. That said, the one really useful skill I took from my time in the games industry was learning to observe and analyze process, learning what was and wasn't important, and I gotta say I got pretty good at it. So that said, here are my own thoughts on being a Rapid Experience Developer...(I'm probably 100% wrong).
I think a big part of this thought thread started quite a while ago (well, as the internet goes anyway) when a friend of mine was pitching a hardware device to me and I kept interrupting and asking what the experience was. When developing experiences, especially for mainstream consumption, it all starts with the approach. I've noticed that here in tech-land it's all too easy for us to fall back to things like features and implementation details, or presentation and visual details, you know, the things we're good at, but let's be honest, only the pundits, marketers, and people who need techno-babble to sound intelligent care about individual features, and of those people, an even smaller slice care about anything lower level than that, algorithms and optimization details, for instance. Now don't get me wrong, I'm a developer/geek (seriously, don't let the powerlifting and MMA fool you, that's just my security blanket) at heart, I can go on about that stuff all day and then a few more, but in the right company at the right time. So mastering the art of the pitch? Crucial to rapid experience developers (henceforth, RED).
Everything in its place...
First off, there's the overall mindset that comes with delivering a successful pitch. When we realize that we only have a very set amount of time to make people "get it", we really start to focus in on what our overall messaging has to be, so it goes with RED. Our experience has to communicate its essence to either an uninformed user, or even worse, a user who thinks they're informed, both of which are uphill battles. Nowadays, most people have...what I'll call a latent knowledge of experiences, that is, we're so inundated with interactive technology that we know what we DON'T like. If you've ever been in a production job, you know how annoying it is to work with creative leads who pull that stuff (oh, I'll know it when I see it), and while it's acceptable to not put up with that garbage in that situation (I mean really, that's just unprofessional), we can't really hold our target audience to that same standard, so the onus is really on us to...not really know what they want end-to-end, but at least put something in front of them that gets them in. We don't need to sell someone a product, but we do need to make sure it stays with them (no easy feat given today's short attention spans. I blame internet.)
Another crucial element of the pitch process is that it puts us into the role of storytellers, and as any good storyteller knows, we have to be able to connect with our audience. A big part of that is being able to put ourselves into the mindset of said audience. You know, in that way, RED is a lot like being an artist, in that the best artists are those who can see through their audience's eyes and know what they'll be looking for/at. Ok, I know that's a little hippy/new-agey, but I think it's a valid idea, and ultimately, I think it's the closest we're going to get to getting any sort of an indicator as to what our audiences are going to want from our experience (see, again, the onus is on US). Additionally, telling the experience as a story is a great tool for how to structure the experience overall. What's the introduction, i.e. what's that hook that's going to get the user engaged initially? Next, what's the "meat" of the experience, that is, the body of the story? What is it that's going to keep the user around for a bit? Lastly, how do we resolve the experience and give the user some impetus to at the very least stay tuned to see what's in store for either the next iteration or the next story we choose to tell? That's quite a bit to think about, and when we consider we may only have a few weeks to put all this together, well...are we starting to think a little differently about how we approach development?
The last thing I'll touch on here about the pitch process is that it teaches us really quickly that we CANNOT fall in love with our pitch, our product, and most especially, our process. The same goes for an experience, especially when it comes to RED. Now, I realize that strikes a bit counter to what I'd previously said about RED being like art, but make no mistake, while we borrow tenets and process from art, we are NOT making art. At best, we're creating a beautiful corpse, and at worse, we're creating a trinket or a bauble to fill some space. Hopefully not too much of the latter, but it will happen, and when that order comes down, crap it out, flush it down the pipe, and get back to what matters. When we start developing an experience, we've got all these great ideas about all the features we want to include, an all the cool things we're going to write into it, and all the great infrastructure we're going to build, but you know what? The minute that stuff starts throwing up walls, trash it and move through. Coding style? Screw it. Properly modeled and textured meshes? Save that noise for polycount. Here's the question we should be asking ourselves at every step: If this experience were being demoed for 60 seconds (which is probably longer than it will be demoed in actuality), would it totally suffer if I didn't implement this feature that's had me stuck implementing for the last week? If I were to just fake it, would anyone care? Answer is probably not, unless it's some sort of interaction model we're trying to work through. Now, I know at this point someone wants to make the argument that "Presentation Counts! Visuals Matter!". That may be true, but I wonder what a little company called Rovio thinks about that, and the same goes for technical details. You probably get my point, but if you don't let me summarize by paraphrasing Einstein, "visuals, presentation, and code should be as aesthetically pleasing and functional as they need to be, but no more." Focus on what matters, forget what doesn't, and who cares if you're embarrassed to show someone your code or source files at the end? Chances are, no one's even going to ask, so...check it in and call it good.
Seriously, just put it in a private repo, i don't wanna know, it's cool
I think i'll leave this with one of my favorite creative coding projects, Red Paper Heart's Golden Clock. I like this for so many reasons (Cinder represent!!), but the main reason I like it is because it was developed by four people in 10 days. And this wasn't a prototype, mind you, this was a mission critical application, in front of hundreds of people, with different degrees of interactivity that had to run the duration of a party with it being the backdrop for the evening's main event! If this can be done in ten days by four people (albeit four kick ass developers and artists), imagine what one really capable RED could do in a month...There's your brass ring.
A Golden Clock from Red Paper Heart on Vimeo.
No comments:
Post a Comment