Skip to main content

Blog Post

Near and Far: Best Practices for Working with Satellite Developers

October 24th, 2016

Our Lead Designer shares her experience working with remote teams, particularly for designers when it comes to handing mockups to front end development.

In our office, designers and developers live in harmony (for the most part).

We sit next to each other and work everyday to strike all the balances between best practices, beautiful aesthetic, timelines, and budgets. As the Creative Director at LookThink, I have a lot of experience working with both our developers and client development teams. Often that can mean working with remote teams. We have honed our approach to create the best working environment. Distance can be a real buzzkill, so how do we foster the same in-person harmony when we’re working with remote development teams?

Meet in Person - at least once

Put a face to the voice. I know this isn’t always possible but, when you can, you should. After the initial introductions and idea sharing, take the temperature of the room. Come to a consensus on a process, toolset, and communication structure that ultimately works for everyone. Prepare for the end: set up a delivery/handoff plan that works for the development and design teams involved in the project.

AND IF YOU CAN'T....

Share War Stories

Scenario: You’re jaded, you’ve been here before - you KNOW what’s about to happen, but *maybe* this time is different, right? Right? If only you’d all shared lessons learned from previous projects before you got here...

Talk through some past experiences both great and terrible. War stories are a quick and effective way to relate to one another – and are pretty entertaining (sometimes horrifying and often hilarious). Once the ice is broken, this tactical conversation helps get into the details on how you’ll collaborate best. You can have conversations that unveil preferences like framework or custom build, Sketch or Illustrator, SVGs or PNGs, annotate or prototype. Sometimes these details are dictated at the beginning of project, but often they are not and this is your opportunity to take the reins and plan how you’ll get the project done together.

Shared Tools

Scenario: You like working in Sketch. Who wouldn’t? Everyone’s moving towards Sketch right?! So you deliver files to the development team, who can’t even open them and in the interest of time, tries to Make. It. Work., but doesn’t have any experience in design software. Had you only known! You’d have annotated the files more. Now they’re working from screen shots instead of source files, and by the time you realize it, you’ve both sunk so much time into making it work, you’re days behind. If only you’d agreed on a common file type or software.

Every designer and every developer is unique, and we’ve all lived and worked through many different processes. I like to find out how proficient the developer is in design programs and go from there. My number one question is: “Do you have Adobe?” or more often these days, “do you use Sketch?!” Nothing makes my designer heart flutter more than a dev who knows their way around a Sketch file. Understanding that everyone has different levels of experience with a wide range of tools helps me, as the designer, decide how far to take my documentation. This can save everyone a lot of headaches and the project a lot of time. Then, our next step is generally a negotiation based on timeline and budget as to how ‘clean’ that source file we hand over is.

Given all the time in the world, designers prefer to put together a basic style guide, slice out all imagery and assets, clean up any SVG icons or logos, and finally annotate unique styles and spacing. But when do we actually have all the time in the world? Never. So, it’s back to that negotiation - figuring out what works best for the developer given the timeline and budget.

With a clear understanding upfront, the team is more collaborative and less siloed.

Tension Elevates Products, Compromise Makes Them Happen

Scenario: You had a dream: this website/app/landing page/digital property was going to be the most beautiful square foot of the internet. People would come to it, marvel at its usability and design; the client shouts your name from the rooftops!

Then your lead developer wakes you from euphoria: “But the platform doesn’t support that...we could try to make it work, but, it’s really not in budget, and I can’t promise it’s going to work.” This is how broken dreams happen: no one collaborated on technical specs upfront.

As a designer, I want everything I create to be a special snowflake. Unfortunately, that’s not realistic for most projects. We work within tight budgets, and our clients depend on us to use our experience to come up with development plans that align with their expectations, timelines, and budgets. Just as I fight for the best design, developers will fight for the best technical solution.

The best compromise I’ve learned is to embrace how a certain CMS (e.g. Drupal, WordPress, etc.) or framework (e.g. Bootstrap, Tachyons, Foundation by Zurb, etc.) functions and design to its strengths. Learn how the grid works, how menus work, (modals, tooltips, sliders, form elements, etc.), and design with those confines in mind as long as it doesn’t compromise the UX integrity of the site or application.

If you hit a snag, reach out to the development team. If you work with the devs, not around them, you may find out that the small style edit is actually big lift and decide maybe you don’t need that style after all, or that this tricky component is achievable through a plugin you hadn’t worked with before.

Illustration by Alyssa Pine

In all of my lessons learned, the bottom line is: a little communication goes a long way. Trust me.