How To (Kindly) Work With Developers
One of the most requested topics I receive from other designers is how to work with developers, so I thought I'd finally dig in and outline what I personally do. But to help balance things out, I've also brought in a friend (and collaborator) of mine, Janine Isabelle. She is a developer who will be sharing her own knowledge and thoughts throughout this post so that you get two different perspectives. Not just mine. ;)
Although I have enough knowledge of coding to be dangerous, I don't offer it as a service here at Rowan Made. Instead, we outsource and connect our clients with a handful of trusted developers. This begins with a simple email introduction before the design phase even begins, so that our clients know what all of their project costs will be up front. I do this by emailing 2-3 developers with a quick overview of the project goals and site map. I'll also CC my client into the discussion in case they have any follow up questions. The developers then individually respond with their availability and an estimate, which our clients can then use to make their final decision. They also have the design estimate (from us) at this point so they can easily compare costs to their overall budget.
This first step is a little monotonous, and would be much easier if I had a developer in-house at Rowan Made. But that's not where we're at right now, and luckily, our clients have never minded. We just make sure to let them know that although their developer is outsourced, we remain a part of the process until the end to ensure that our designs are carried out accurately before launch.
Once the client makes their final decision, I'll have them sign a design contract and pay their downpayment* in order to get started on the website design. And because this post is specifically about HOW to work with a developer, I'm not going to go over design tactics at this time, since that's a huge topic in and of itself. Perhaps I'll save that for a different post down the road. ;) So for now, let's skip ahead to the end where you'll be prepping files and communicating with your chosen developer.
* Because we outsource, our contract + downpayment systems are completely separate from whatever developer our clients choose to work with. The developer will handle those two items on their own with the client.
A QUICK NOTE
I design websites in Adobe Illustrator for a few reasons. First of all, it's so much easier to drag content around. And secondly, I'm more familiar and faster with this particular program. I know that many designers swear by Photoshop for website design, but it's always felt seriously bulky to me. And if you're wondering about "pixel perfect" design (which is important for web), you can select "align new objects to pixel grid" at the start of every project in Illustrator, which means that you'll be working in 1px increments without any decimals. Here's what Janine has to say about the use of Adobe Illustrator:
"Because I’m both a developer and a designer, I am *doubly* biased when it comes to using Illustrator for web design. For a number of years, the argument was that Photoshop was the only Adobe program based on a pixel grid, but Illustrator has supported pixel tools for more than a decade, so the point is pretty moot now. Illustrator also has a number of features that just straight up make my job easier. One of my favourites is the artboard tool, which allows you to create multiple pages inside a single file, as well as add helpful notes in the margin — one of my favourite things Bre does in her design mockups! Another big one is the ease of object selection. While in Photoshop I find myself spending extra time hunting down basic information about elements in a design, all I have to do in Illustrator is click on an object to inspect things like colour, size, type details, etc. Honestly, the only argument left for continuing to use Photoshop for web design is familiarity and that’s not a good enough reason in my opinion. ;)"
ORGANIZE + CLEAN UP YOUR FILES
The first thing you'll want to do before handing off files to a developer is make sure that everything is clean and organized. I like to divide the website design into two files: desktop.ai and responsive.ai. The desktop file is straight forward, outlining exactly what each page will look like at their widest state (on desktop + laptop screens). The responsive file, on the other hand, is more of a visual guide for responsive styling, since it's almost impossible to create screens for every single possibility (mobile, tablet, horizontal this, vertical that, etc.). I'll cover this a little more later on in this post. So for now, let's go back to the two files from above. Each file is composed of several artboards (one per website page), as well as a handful of layers:
— Content
— Hover
— Notes
The content layer is where the actual website design lives. The hover layer is turned off and locked by default, but once the developer turns it on, they will see an overlay of ALL the hover styles throughout the site (links, buttons, etc.). The notes layer can be turned off or on (it doesn't really matter) by default, and includes lots of notes outside of each artboard to help explain exactly what is happening. I don't include notes for every single detail of the website, since a lot of it is straight forward and easy to understand. But when I feel like something needs a bit more explanation, I'll share my thoughts. For example, I may explain how a slideshow works. Or why a blog feed is setup in a particular way.
click on the above image to view in full
To help round this section out, here is what Janine has to say about website design file organization in terms of what helps her the most as a developer:
"Another perk of using Illustrator is being able to use layers in an intuitive way for general organization. It’s incredibly helpful to have things like hover states on their own layer that can be turned on or off as needed, and I’ve already declared my love for Bre’s extensive margin notes. I’m a bit of a stickler for details, so I love getting design mockups where all my questions have already been answered and everything is clear and organized. It just makes everything go a lot faster when I’m not having to go back to the designer to ask for clarification all the time."
HOW TO APPROACH RESPONSIVE STYLING
As I mentioned earlier, responsive styling is where things get complicated, because there are literally endless possibilities. Most developers work in "percentages" so that websites are fluid and scale down naturally, and as a designer, I keep this in mind as well throughout the entire process. But I always begin with the desktop design, since that's where you get the most space to play around. ;)
While designing a website in its widest state (for desktop and laptops), it's important to always think about where and how certain areas of the design will break. For example, if you're on a computer right now, start dragging your browser window smaller. Once you get close to the white container of my blog, a natural break occurs, where the text column continues to shrink so that it's always in view.
Now, even though my clients always receive a fully responsive website at launch, I only present desktop solutions during the design process, simply because responsive styling tends to be a bit overwhelming. If there is something really specific or intricate that needs to be illustrated on a smaller device for approval, I will absolutely do that. But most of the time, it's more efficient to get the desktop design signed off so that I (as someone who understands what it means to make a website responsive), can translate everything for smaller screens before sending everything over for development.
I do this in the aforementioned file, responsive.ai. Here, I'll typically translate enough pages to convey what the overall responsive styling should look like on smaller screens. For example, the home page is an absolute must to include, since it's somewhat unique. From there, other pages may have similar structures, so there's no need to include everything, unless you really want to. Developers will pick up on similarities and apply the same types of responsive styling across the board. Because of this, I only include pages that I truly think are needed. And if a developer ever has any questions (or needs more direction), they'll simply let me know. Here is a quick screenshot of what one of my responsive guideline files actually looks like!
click on the above image to view in full
Once again, to help round things out, here is what Janine has to say about responsive stylings in terms of what helps her the most as a developer:
"In 2009, less than 1% of web traffic was on mobile devices. So far this year, it’s hovering around 40%. In other words, nearly half the people looking at any given website are doing so from their phones. This obviously makes responsive design extremely important, since you want to optimize the experience visitors are having on your website no matter what screen sizes they’re viewing it on. As Bre said above, it’s usually not necessary to put together responsive mockups for every page of a website as a lot of how a layout “breaks” is fairly intuitive (for example, a grid that has three squares on desktop might go down to two or one square on smaller screens), but it’s crucial to include enough to give your developer a good idea of how the design should adapt to mobile screens. It’s also important to have a solid understanding, as a designer, of how layouts naturally adapt. Responsive design (and coding in general) is not drag and drop, so elements generally need to keep their order in a layout regardless of the screen size. For example, if a heading comes after an image on desktop, it’s not an easy feat to reverse the order for mobile."
SAVING DESIGN ASSETS
The last thing you'll want to do before sending over your website design to a developer is save all of the design assets they'll need. AKA, photos, graphics, and fonts. To do this, I'll simply provide one folder for images (which includes photos and graphics) and one for fonts. Within the images folder, I like to create sub-folders for each page (ie: home, about, contact, portfolio, etc.) so that everything is easy to navigate. The reason I save out images for whoever I'm working with is because it's the nice thing to do. Plus, it also ensures that the crop and sizing you'd like is accurate. Other tips for saving out images:
— File names shouldn't included spaces. Do something like this: logo-white.png
— Ask your developer if they need images for retina display or not
— If retina images are needed, save a second copy of each image at 144 dpi
— Images doesn't only mean "photos." Save out website vector graphics as well
For fonts, I simply include a file or link to whatever I used within the design so that the developer can install everything on their own server before opening up any of the files in Adobe Illustrator. Remember that fonts should be web friendly, whether that means using something from an online service like Google Web Fonts or Typekit, or having your client purchase the required webfont license. The last thing you want to do is choose a typeface that isn't web friendly. ;)
- - - - - -
Once all of the above items are ready, I'll send the entire package to the developer I'm working with through DropBox. I'll also let my client know that their design is now in the development phase, so that they're updated accordingly. Beyond this, I get involved again at the very end, performing a site review to ensure that all of the details were carried out accurately. This can be done through a project management app, or a simple Google Doc, where you and the developer can chat about any potential edits that need to happen before launch.
If you have any other questions about how to smoothly work with a developer, please leave a comment below. We'll either answer you directly, or let your note inspire a new post on the blog!