Playing nice with others: The intricate dance of design & technical resources

Have you ever tried to run across a field of grass carrying an egg in a spoon held out in front of you? If you said no, well you haven’t really lived life fully yet and you probably didn’t grow up in my hometown in NC. When I was in middle school, we had a class Olympics every year that involved ridiculous events, such as an egg relay race. Each team would get an egg that they had to successfully relay between teammates running back and forth across 50 feet until 5 legs had been completed. If the egg dropped and broke, you had to start the relay over from the beginning.

Nate Parsons
Posted

Have you ever tried to run across a field of grass carrying an egg in a spoon held out in front of you? If you said no, well you haven’t really lived life fully yet and you probably didn’t grow up in my hometown in NC. When I was in middle school, we had a class Olympics every year that involved ridiculous events, such as an egg relay race. Each team would get an egg that they had to successfully relay between teammates running back and forth across 50 feet until 5 legs had been completed. If the egg dropped and broke, you had to start the relay over from the beginning. It was one of my first object lessons in teamwork.

As it turns out the process of integrating visual design and the content management & front-end technologies it takes to bring it life on the web is a lot like the egg relay hand off process. Your project is the egg, your team is composed of artsy designers and “we deal in hard cold reality” engineers.  And don't forget, it might be the team's first egg relay together. If your project has separate design & development firms working on it you may find out that their idea of handing the egg off carefully to one another may be to fire it out of a slingshot at 80mph at their teammate while running hard in the other direction.  And I suppose this analogy also highlights why we at Phase2 have our own design resources in-house -- carefully schooled to have a steady hand and great eye contact during egg relay transfers. I hope this blog post can help you coach your disparate firms or teams into being masters of the gentle art of the spoon-to-spoon design hand-off and implementation.

Step one: Icebreakers

Just like any stereotypical corporate retreat or first day at camp, it’s good to start things off by having your design team and tech team meet. You, as the client/adult presence, need to realize that in addition to playing the role of Daddy Warbucks, you are also the social coordinator of the SS Project cruise ship. Both teams are going to look to you for the tone for how they will work with each other and with you. It’s very important that both teams realize you see them as partners, as teammates, and you’re expecting them to work closely together. Kicking things off on the right foot will set the expectation to communicate readily with each other and convey the message that they’re not adversaries on this project. You’re designers should be soliciting feeback and input from the tech team on how best to achieve their vision, and you want your engineers to feel confident they can succeed with the design provided. Some things that are possible in Adobe Photoshop aren’t great ideas on the web, and sometimes there are a few tricky web technologies that designers might not even know they can use to their advantage.

These different mindsets also highlight the first major “gotcha” of working with separate design & tech firms. If you aren’t planning on their work time / project time on overlapping, you are setting yourself up for cost overruns and compromises to the design right off the bat. With technology advancing quickly, and with the fact that your design firm doesn’t know the pros and cons of the technology platform as well as your tech firm, it’s imperative that they both have a chance to influence each other’s decisions and make any revisions to the design and functionality that are required to make your finished product something you are proud of. A car company would never hire a design firm to design the outside of a car without allowing the engineers to let them know if the engine would fit inside or if you should put the gas tank right there by the rear bumper -- and you shouldn’t either!

Step two: Participation is 30% of your final grade

Ok, you’ve got your design team collaborating with your tech team.  They are going on paddleboat rides together, planning ski-trips, and you’re feeling like you could be a professional team builder, what’s next? It’s time to figure out what your design team’s choices mean in terms of future work for you and your team. Lots of things that look beautiful in a design can imply a high level of work for you to keep up. This can be a matter of writing copy a certain way (length restrictions, two word headlines, whatever), picture selection for big bold and beautiful image driven designs, or manually selecting stories for “featured” sections/blocks on your site just to name a few things. You want to make sure your expectation of how much time and effort you can expend managing your website meshes well with the proposed design.

Figuring this out usually requires having a few conversations with your tech team about how they plan to implement the design within the content management system powering the site. You’ll want to know what can be automated versus what needs to be manually curated, what content prep work may be required outside of the CMS (such as flash movie creation or what not), and what tweaks might reduce or streamline the work required. The things you learn here may lead to a follow up conversation with your design firm about what you’ve discovered. This is really where the rubber hits the road in terms of adjusting your design to influence how much time must be devoted to website maintenance, and what tweaks to the design can reduce the internal workload required to keep your site vibrant and fresh.

Step Three: Spoon to Spoon Egg Transfer

As you can imagine, rolling an egg between two spoons, each held by a different person is a stressful and delicate process. The same could be said of handing off a design from an artist to an engineer. Designers have their own language and ideas about how sites work and look, and they’re not the same words engineers use. (For one thing, they often have several syllables in their words... ;) You want to ensure that it’s clear to both firms what is being handed off as a deliverable from the design firm and as an input to the engineering firm. The deliverables could be something as simple as Photoshop PSD files, (X)HTML cutup & CSS files, or a pretty sketch on a napkin.

Chances are good that your tech team is going to want the design to be documented in much greater detail and more formally than your design team is used to providing. The visual design is just one component of the design process, just like an artist’s painting of a building still requires blueprints and structural inventories for someone to actually build the building, your engineering team is going to want a suite of Information Architecture documentation to build your website. Is your designer creating those documents? Are those things your engineering team is going to create based on what they see in the visual design? Maybe you need a user experience resource to help interpret the grey areas between the visual design and how people will actually interact with it on the web? What artistic liberties did the designer take that infer functionality (and thus cost) in the web build out? (And were those intentional decisions or simply things that “looked good” in the design?) Do you care about that dreamed up functionality or can it be removed?

It’s very important that both teams know what the inputs and deliverables are to their work need to be and it’s incredibly helpful to the engineering team (and to your budget) if the designer is available to make minor tweaks or changes to the design early on to make it easier to implement within the CMS or to address edge cases that didn’t come up during blue-sky planning. (It’s funny how actually trying to use a design helps identify usability issues…) It’s also important for you, the client, to know which team is responsible for each particular decision, because if you don’t know who’s the captain of the SS Project at any given moment that usually means no one is…

Step Four: Cheering your teammates on

Ok, the egg is in the other spoon and the engineering team is tottering along towards the finish line with a steel glint in their eyes.  If only they were still getting some comforting supportive screaming from their teammates! In a website build this boils down to having on-going support from the designers to help address any gaps in the design or new items that need to be created during the build. For instance, what if you never decided what 2nd level bullets will look like in a bulleted list? Does the tech firm just take their best shot or is there someone not wearing a “will code for food” t-shirt they can call? Who helps address problems such as “the page looks too empty when we put our real content into it” or “the page looks way too busy and long with our real content into it?” (And these are the easy problems!)

You, as the client, need to make sure you’ve gotten both teams to budget & commit time to help each other out, that you have clearly identified which team is responsible for which actions, and who ultimately will make decisions as the website build is completed. It’s probably one of the most common problems with using two separate firms that I run into.  Neither of side was actually contracted or scoped their budget appropriately to actually work together as a single team with the additional complication of having staff available to offer expert advice during both the design and build phase of the project. You hired two experts, but experts sometimes require a little handholding to share their knowledge with other firms, they’re usually only setup to provide information to the client.

Step Five: Trophy Time!

Hey you’ve made it! Your site is built, it works, it looks beautiful, and you didn’t blow your budget or timeline cleaning up miscommunication, painful scope discussions, or ruin your site’s pretty mug by switching design horses midstream. What’s next? Aside from drinks with umbrellas in them. Perhaps if you’re feeling especially feisty you can talk to your design team about a quarterly or biannual design/editorial calendar and then work with your engineering team on creating new functionality or new features? Maybe during that build out process your design team learned a few new technological tricks and they have some new ideas on how some pages should look or work.

The real trophy isn’t what’s next though, it’s the satisfaction of a project well completed with you receiving the most out of the expertise of all the teams. Kick back and have a drink with an umbrella in it, the SS Project cruise ship has made is safely into port.

Nate Parsons