To be (code) or not to be (code)?
When you’re working on installations and interactive designs there’s one hurdle that is ever present in almost every job: the point at which your team decides to switch over from designs, comps, renders, or sketches, over to real interactive code. To preface the problem, I’ll briefly talk at a high level about the life-cycle of an interactive project. Keep in mind that in such a budding field, the model described below might not fit everyone, but the outcomes and strategies I lay out later are generally the same. This post will also cover most of the life-cycle, even though the reality is that many developers come in at the later stages, but knowing the process puts you in a position to guide the other teams involved and give yourself advantageous positions over the course of the project. But before that, what’s buy-in?
Buy-in and snail-down!
Buy-in is the the crux of this whole article. You could even say the only real philosophical challenges of any project are buy-in…but that might be a stretch! There are many definitions of buy-in in the business world, but a common definition used in conversation is:
the agreement of one party with the suggestion of another party
So how does this work in our field? Well, every stage of a project is essentially someone pitching something and trying to get the agreement of the higher-up powers (clients). Whether this is trying to get clients to commit to a creative direction, or trying to get an AV vendor to agree with your technical specs for the rack, or you’re trying to get all teams on a project to agree to an overall project schedule. Buy-in is what you’re seeking in all of these instances. You’ll notice in most cases there is always some resistance, then there is a moment of buy-in when you’ve proved yourself or your idea, and then everything after that is smooth sailing until the next thing you need buy-in for. So with that in mind, let’s talk about projects (in a pretty high level and simplified way)
Interactive project life-cycle
The first part of any project is discovery. This is when you find out there’s a possible gig to be had. Whether it’s an RFP (request for proposal), a cold call/email you get, or a referral, this is when you hear about the project existing and that there’s a possibility you might get it. What you’re required to provide at this stage may vary. RFP’s often require more than most others pitches, as you’ll need to put together budgets, schedules, project descriptions, and even some initial sketches or renders. Most other forms of discovery are a mix of some back and forth about potential ideas, some budget ballparks and schedules, and then a general sense of whether or not you’re the right one for the gig. Moral of the story is at discovery phase, you’re usually exploring creative ideas and capacity to get the client to buy-in to you as a vendor overall. Once you’ve got buy-in as the vendor, you usually move on to the next stage.
So now you’re on the project! Hopefully you’ve got a down payment and some contracts are signed. Now you’re in charge of delivering some cool idea. What that is may be vague, as the discovery phase is usually a bunch of people talking about cool stuff and possibilities and a direction. It’s time to actually decide what you’re going to make and how it’s going to look and function. I could write a whole article about the trials, tribulations, and traps of the design phase. For one, the longer it lasts, the less likely you are the please the client no matter what you do, because at a certain point the client gets a sort of design fatigue. So a side pro trip, don’t rush, but try to get through this phase as quickly as possible. Back to our main topic and the meat of the article.
Crouching tiger, hidden issues
It’s taken us an extra long preface but we’re now at this tough question of “at what point should we stop using Cinema4D, After Effects, etc, and start coding the actual project?” Before we answer it, it’s good to cover the hidden issue behind this question: accurate replication. What happens to far too many projects is that the designers are able to use offline rendering tools to create visuals, graphics, interactions that are far beyond the quality and capabilities of real-time systems. It’s as simple to the developers as “we can’t make it look that good while it still running smoothly” and “that’s not possible to make in real-time.” Experienced teams will often throw designs back and forth internally with developers to prevent these issues, but often times this doesn’t happen. Because the worst thing that could happen is that your client loves the beautiful offline render and will not accept the slightly different real-time version because it doesn’t look exactly like the thing they approved.
This is where understanding buy-in becomes so important. My strategy and approach to this question is as follows:
Use the design phase to get creative buy-in NOT finalized design sign off. Only do as much design as is needed to get buy-in.
What’s this mean? Seems like jargon, buy-in vs sign off. As we defined earlier, buy-in is an agreement to suggestions and ideas and that we can proceed. Sign off on the other hand is a more formal process of a project at which point the client, who may actually physically sign on a piece of paper, that certain requirements have been met and the thing they’re signing off on is the final version of that thing. This is difficult because as we mentioned above about accurate replication, if you get the client to sign off on a design, you damn well better be sure you can make your real-time work look almost exactly like the offline designs. With the nature of real-time systems, I generally prefer to avoid this task of accurate replication, and I like to replace it with the task of real-time iteration. Either way, both of these are the development phase, so let’s focus on the design phase still.
So let’s say you want to avoid the burden of accurate replication. How do we proceed with the design phase? Buy-in. During the design phase you’ll want to nail down / create / document things like creative goals, project narrative, design rationales, overall UX, mood boards for references of looks / tone / feel, and then maybe some very rough sketches / renders (emphasis on the rough part). You want the client to feel understood and that you know the right direction. You’d be surprised how well clients react to formal write ups of their goals, project narratives, design rationales, and UX explanations. Those combined with some references of “it’ll feel like these bunch of images combined” can go a long way and get you a solid buy-in that lets you dive immediately into coding and designing in real-time with your code.
The only way this strategy works if is you have someone on your team who has strong client relations and management skills because you may be taking your clients in new territory and they may need comforting and guidance. Most clients and design agencies are used to doing a bunch of really polished designs, signing off on them, and then getting the made and deployed. You’re going to need to forego that mindset and convince them to be a bit more loose, and here’s some bullet points you can use for your case:
- interactive tech and immersive media are bleeding edge technologies that have different abilities than older offline design tools
- the way things interact in real-time will be very different than their rendered versions
- content at scale will look very different (you’ll want to then setup a scale mockup system if possible)
- they’ll be able to help guide design in real-time (show them how cool it is that sliders and buttons can change code in real-time!)
- if you focus on buying into well thought-out and documented UX and rationales, that you can iterate a lot faster on designs in real-time (this might be a straight up lie!)
- faster turn arounds vs designs that need to render for days or a week before they can be seen of commented on (also might be a total lie!)
There are more reasons that you might need to come up, but I’ve found a combination of these kinds of topics will usually convince the client. If they were completely risk-averse, they wouldn’t get into interactive tech.
The development process usually goes down one of two routes, as we already mentioned: accurate replication or real-time iteration. Either way, you’ll want to show continuous and incremental progress. A lot of clients may not be versed in design or technology, so dropping updates where everything looks completely different might throw them off because they can’t mentally get from their previous state to this state without a lot of mental energy. Whereas time and well-paced updates (maybe twice a week or once a week) help them mentally stay with you during the progress and gives them the ability to throw flags along the way if there’s any concern. But keep these paced and well-timed. Don’t throw down 100 renders in one week, and then nothing for 3 weeks after, it’ll really confuse the client.
If you’re in the accurate replication side of things, your focus is incrementally getting closer and closer to your signed off renders. If there are any flags, make them early but not all at once while offering alternatives. Accurate replication will usually have less iteration and real-life mockups / reviews, since you’ll mostly just be grinding away to make it perfect, then there’s usually a big review at the end to confirm or deny your effort.
If you’re on the real-time iteration track, I recommend setting up a mockup system as early as possible. This helps solidify the rationale of going real-time iteration, so you can easily and often times show the designs and play with them right on the mockup system. You’ll also want to hold more reviews than you would with accurate replication, because you still have the burden of getting your final buy-in on the design, but now the nice thing is once they sign off, you already have it (or at least most of it) already built and ready to go. Don’t forget to involve your client in the process of iteration, it’ll help make them feel empowered and involved. A happy and powerful-feeling client is generally a good client. You can send them possible app’s that they can play with with sliders and buttons options to change things on the screen in real-time. It’s also pretty impressive and again solidifies the whole real-time iteration path. If you can’t easily send them apps to play with, getting them in regularly with your mock up system is a nice thing.
I won’t go too deep on deployment, but at this point you’ve got all your designs and developments done. You’re going to be showing up on site soon and setting up your project to get the final buy-in, client happiness. How corny, right? By this point, if you played your cards right the client is already excited and seeing the thing in real-life will be an instant-win. If you’ve had a ton of trouble along the way and the on-site deployment is a disaster, brace yourself for the wrath of the wealthy, which ironically ignores all elements of the process and only focuses no the immediate moment. Regardless, deployment is the home stretch, getting everything up and running, testing it, writing any documentation needed, signing SLA’s, and handing off any technology to the appropriate parties as you prepare for your next project.
Ok, so there was a lot of stuff in this post. A ton of it was also in side notes that’ll be examined in further posts (like the trials and tribulations of the design phase). For now the things to take away are the importance of buy-in. With buy-in you can really flex the iterative factors of real-time systems and interactive tech. If you’re able to convince clients to go down the path of real-time iteration you can also save yourself the chore of matching over-the-top renders with your real-time systems.