Episode 3: Prototyping and F*ing Up
It's all fun and games, until it isn't
In this episode:
Daniel Belquer: Prototyping and Fucking Up
Oriol Ferrer Mesià: Making Modern Retro Computer Terminals
Kirsten Nelson: Everybody’s Favorite Art on Big Screens
Sundar Raman: Your Prototypes are Designed to Fail!
Prototyping and Fucking Up
Please allow me to introduce myself, I’m a man of wealth and taste. No, this is from some song or whatever… I’m sorry, actually I am not wealthy and my taste is… questionable. And for introduction you can just Google me.
So let’s jump right into the topic by starting to analyze its title using some good old fake math:
P (prototyping)
F! (fucking up)Which gives us:
P&F! = XWe could pursue the resolution for this equation and the value of X, but this could be better stated through group theory, so:
Of all the almost infinite, philosophical, existential, romantic, jackass or just plain dumb ways one could satisfy one's urge to fuck up either by pathological impulse or masochistic tendencies or else, I strongly recommend to you not trying prototyping just because you could find cheaper and simpler ways to fuck up.
That being said, by mentioning cheaper and simpler I have implied P requires $$ and Td (which in this case stands for Time drained). I’m talking about relative cost here, because if your budget for prototyping == 0 you can still consider time spent obsessing and money that you don’t have. Even then prototyping is going to suck whatever you have out of you.
———xxx ___=== ()_Moving from fake math to Pub-based Psychoanalysis (PbP according to no one) you’ll have to have an above average OCD level to get into prototyping. As the frustration builds up and the BS talk about all the ways you’ve learned on how NOT to do some shit, you have to have a social death wish in order to commit to the lost cause of prototyping. Picture yourself at a romantic dinner: Your loved one is discoursing passionately about some family-related quarrel and you can’t help yourself but thinking that on line 2735690 of your code there is a flaw that prevents that damn LED from lighting up properly.
There is also the physical hazard of sleepless nights or the true danger of getting burned, stabbed, pinched, cut, bruised, blistered or having swallowed some unhealthy substance while trying to declog a weird tube that you will discover later on it shouldn’t have been there in the first place.
But then there is joy. Yes, but it doesn’t last long, as you discover it moves but it smokes after 10 seconds.
I don’t get it, but who am I, don’t take my word for it. If you don’t ever prototype, how will you discover you actually hate it? But then it will be too late and you’ll also find out you cannot live without it…
Who knows? Maybe Heidegger, Arduino or Lady Ada can help us here.
Good luck and poor us!
Photo Courtesy Art on the Mart
Everybody’s Favorite Art on Big Screens
Seems like everyone, no matter where they live, has a ticket to one of the innumerable touring immersive Vincent van Gogh exhibits making their way around the planet. But that’s not the only massive-scaled artwork happening right now. These attractions are appearing anywhere the threshold has been met for a) reasons to leave the house, b) even my home office green screen can’t create this effect and c) this stuff will look amazing in my social media content feed.
One of these massive sensations that I’d actually consider traveling to experience is in Chicago, because the nucleus of my personal Venn diagram of sentiment, captivating imagery and place-specific content can be found there.
Eons ago, on a mid-winter evening, one of my DJ hero friends retrieved me from my favorite whisky and grilled cheese bar (emotional context note: the day after I wrote this, I coincidentally opened the newspaper and discovered this bar went of out business during the pandemic) and transported me to a secret Brooklyn after-hours spot where some Chicago footwork DJs were playing. The stage was filled with a crowd of visiting dancers and DJs together, bringing the whole scene to us. In these mixed-up copycat everywhere homogenized times, it was the most exceptional feeling of experiencing something purely from another city, purely of Chicago, in NYC.
Apparently that was exactly the intention, as revealed in a new film and animation capturing the essence of footwork, projected mega-scale via Art on the Mart in Chicago. Go see it, or look at the video in this New York Times story that gets into how the DJs started bringing dancers with them to really set the music in motion everywhere they went.
For the next-level interactive version of experiential artwork exploration, check out what Cocolab is doing in Mexico City with Frida Immersive. Beyond big art on beautiful set designs, all created in house at Cocolab, these animations are infused with realtime graphics. Definitely want to find out more about the interactive pieces that were built for this experience.
Back in the giant-scale projection as slightly one-dimensional attribute category, there is also the Illuminarium in Atlanta. What is really on offer there needs to be explored before further comment can be made.
Fortunately, it seems that for every disappointingly facile rendition of immersive experience, there are seriously magical things being built. Of course the progenitors of the form are still doing it right. TeamLab built those crazy new orbs for their new outdoor installation, “Moss Garden of Resonating Microcosms - Solidified Light Color, Sunrise and Sunset”. Artechouse is trying to depict a slightly hopeful angle on our post-apocalyptic future with “Renewal 2021” in DC, and it’s delving into art and activism with Vince Fraser’s “Aṣẹ: Afro Frequencies” in Miami. Then, near the center of it all, Atelier des Lumieres embraced the disorienting nature of the format and went surreal with Dalí and Gaudí.
There’s a lot to see, and it’s all gigantic and happening in large spaces with more humans, all of whom have tickets to what they can only see in this one spot, this one time. I think they call that collective effervescence. Remember that?
— Kirsten Nelson
Excerpt - Making Modern Retro Computer Terminals
[Editor’s Note: The following is an excerpt from the comprehensive article composed for CreativeStack by Oriol Ferrer Mesiá, “Making Modern Retro Computer Terminals”.]
During the 2020 Covid-19 Pandemic, I found myself with plenty of spare time (I am currently willingly unemployed), the inability to go anywhere, and a curiosity about making real physical objects. I had a 3D printer that I previously used to create simple parts and enclosures here and there, but I was keen on moving onto trickier objects, beyond the spectrum of basic blocky parts and random things downloaded from Thingiverse.
I also often fantasized about owning a minimalistic physical terminal, a single appliance-like device you could just turn on, and get a fully working linux shell. I learnt to code C on a dumb terminal back when I was at university, and there’s some nostalgia attached to them for me. I regularly looked on eBay and similar local sites, looking for an old dumb terminal in good visual condition I could hack into, at a reasonable price, but I never quite found the right one.
At some point, these curiosities and dreams unified into a formal project; why not make a fully functional terminal myself? And so it began…
Read the rest of the arduous and trial-filled prototyping process, with fantastically delightful results, by Oriol Ferrer Mesià.
Your Prototypes Are Designed to Fail!
If you’ve read this far, you are either in the realist camp (prototyping sucks!), or in the delusional camp (yay, let’s prototype!).
I’ll start by stating the obvious. Complex projects are full of things that want to go wrong. Experience Design falls within this category of “complex projects,” primarily because of the sheer volume of things that fall somewhere on the unfamiliarity spectrum.
Things (usually) go wrong because we don’t have muscle memory for doing them. Unfamiliarity means we have not yet built up the instinct to navigate, to differentiate working from failing. And this lack of prior knowledge is where we lose our fortitude and ability to pivot and re-align.
It took me a very long time to accept a basic concept: The ability to do things well comes from fucking up repeatedly. To be fair, it wasn’t just repeated dumpster fires (though there were enough of those!), but enough screwups where the path to success was still apparent when someone pointed it out. It’s frustrating when the outside observer points out our idiocy. But we all need directions sometimes!
Experience Design is chock full of the term “prototype”. I’ll say it’s misused enough to lead to confused expectations on what exactly it’s supposed to be. But even then we’re all generally familiar with design and engineering prototypes — the dictionary definition of which includes “preliminary model from which other forms are developed.”
That “preliminary model” can be hard to understand, depending on the context one comes from.
My favorite example of a prototyping process is Jeff Hawkins’ for the Palm Pilot, perhaps the first successful handheld computing device. The story goes that Jeff cut out a block of wood in the shape of something that would fit into his shirt pocket, and used this block of wood as though it was the real thing. He refined the experience (both end-user and engineering) by working through the use-cases. Diagrams and images of Jeff’s process are easily Googleable.
At a very high level, any experience design project (or arguably any project at all) has the holy trinity of Creative, Technology and Product/Project Management. If a key rationale for prototyping is to build muscle memory for the production solution, then it must be utilized for all three facets.
Every (Experience Design) project comes with constraints. It’s easy to argue (as I always do) that some are “hard constraints”, such as physics, and others are “soft constraints”, such as budgets and people and timelines. But it’s important to understand every type of constraint and get comfortable with it.
In my experience not enough consideration is given to prototyping within product- and project-management. And this has forced me to ask: What does it mean to prototype the “process” aspects of a project?
Engineering and design prototypes provide hints for time and resources needed to create a solution. This is the “Cost to make”. The “Estimates Equations” that come out of this exercise almost never take the process part into account. How much overhead did it take to manage the resources, to coordinate people, to build out the timelines, to context-switch due to changes in expectations, to get agreement on anything at all?!
Timelines change. Expectations change. “Value” is “Engineered”. Pandemics happen.
It’s hard enough to mitigate the identifiable variables in engineering and design. Throw in the human and bureaucratic elements and you start wondering how any project ever gets delivered! The corollary is that this may explain why so many projects fail.
I received one of the best (and unexpected) lessons in recent memory from my Project Director friend Jamie Barnsley... to prototype and define a “Change Control Form” (CCF) process. Jamie schooled me that every production project has things that need to be changed, and budgets that need to be identified for them. Changes need to be captured, documented, requested, signed-off on, and ultimately implemented in some formal fashion. It seems naively simple, but having a system in place makes it possible to get the human machinery oiled.
Similar to the CCF, every aspect of the project planning process needs to be prototyped. These prototyping exercises help all the diverse disciplines that need to collaborate to bring a project to fruition, to understand their specific roles. These exercises are crucial to avoid confusion in understanding of the overall implementation workflow, between the responsible departments or teams. The exercise of prototyping the process exposes and familiarizes teams to the different tools, methodologies, and even risk management and mitigation strategies. Most importantly it builds muscle memory around a consistent process.
There is a machinery, an operations practice, to process-prototyping (i.e. the above suggestion is not just an abstraction). A specific sequence of steps might be as follows:
Create a project plan around a functional component of the project that can be managed discretely. For example, in a lobby projection experience, this might be the initial animation sketches.
Model the planning process for a small subset of the team. Perhaps it is only the two or three motion graphics members and a technologist who has to consider the production implementation environment.
Adhere to the process for a full phase — this is usually two to four weeks.
Implement a communications workflow between the project team members and see if that works. If nobody uses it, it needs to be rethought.
Throughout the process, AND at the end of the prototype duration, evaluate what worked and what didn’t.
That last point is crucial. In the engineering prototype exercise we must come to decisions about what works and what doesn’t. In technical prototypes a piece of hardware, a software programming language, or even the hardware platform may need to be rethought.
Similarly, certain aspects of the project management workflow may reveal unnecessary friction. If there’s a lack of collaboration or clear understanding of objectives, the overall project management structure must be revisited. For engineering, the architecture, platform and tools are rethought. In the case of processes, the tools, operational frameworks, and collaboration structures must be revalidated.
A project should NEVER have collaboration and project-management tools that are used only by a single person. Obviously collaboration is about the non-singular!
Every project MUST have tools that help everyone move faster and more efficiently. The point of tools is, after all, to make team collaboration easier! You can't drive (any more) without turn by turn directions. Why do you think you can deliver a complex project without a similar roadmap and milestones?
Prototypes should be measured. We don’t talk about this enough, but it’s important that the prototype process involves formal documentation and statistics. This does not mean we need to get crazy about metrics early on. It DOES mean you need to track what you’re doing. The classic quote about this is from Scott M. Graffius in Agile Scrum: Your Quick Start Guide with Step-by-Step Instructions: “If you don’t collect any metrics, you’re flying blind. If you collect and focus on too many, they may be obstructing your field of view.”
Arguably that’s the entire point of prototyping — to understand the unknowns, fill gaps in knowledge, and generally gain expertise. Obviously while having frustration-filled fun!!
If there’s one thing I’ve learned, it’s that things will never stay true to plan. There are ALWAYS evil gnomes scheming to trip you up.
Prototyping, though painful, is ultimately also fun! This should be clear even given Daniel’s article above. You may rightfully ask “What’s the fun in process?”
The best metaphors for me are around food. Recipes have
quantified ingredients
prerequisite steps
preparation instructions
final plating and assembly (yes, I read some really boojie recipes!)
These are a template, and you can prototype any menu by delving into any of these aspects.
An analogous template exists in any prototyped system. And if it does not exist, the prototyping process helps you to extract out such a template.
Templates are simply an organizational mechanism, the structure to help ease the complexities of coordination, collaboration and consistent delivery. Creativity is arguably rooted in breaking out of structures. But the structures must be there to break out of! Templates provide both the grounding, and the opportunity to escape the bounds to create something new and more wonderful (or fail miserably while trying and learn from that process).
The fun in any project really is when the work is easier to do and more coherent to execute. And processes are an aid to this endeavor and should never be an encumbrance.
Nothing is obvious on complex projects. My experience has been that as much as I have found prototyping to be frustrating, it’s what helps to make aspects of a system less opaque and more obvious to everyone. It’s hard to imagine and extrapolate how things really work.
So we need to make it and feel it to know it.
Are all prototypes destined to fail?
Yes! That’s the whole premise. Once you’ve got a reliably working system, it’s no longer a prototype. Getting to success is about reducing failure. Complex systems have many many ways to fail. The more you have experienced those paths to failure, the less likely you are to head that way.
Will prototyping the process help you succeed?
Probably NOT! But the likelihood of failure is significantly higher if you don’t prototype the things you don’t know.
Falling off the bike, burning the toast, forgetting to pick up the kids. These are the stories that we find refreshing. Because these are the prototypes that ultimately (hopefully?) teach us and lead us to success.
Prototyping and fucking up (for process or otherwise) may be the best thing you do for yourself!