Design

Don’t Let Your Developer Crush Your (Design) Dreams

June 19, 2018


You’ve just finished designing a masterpiece of a website. Your design team loves it. Your client is thrilled. You can’t wait to see it come to life on the web. You package it up and hand it off to a developer make it happen. You head out early for a celebratory beer (or is it champagne?). You start browsing IKEA’s website for a new shelving unit; you’re going to need a place to display all those new design awards you know are coming your way.

But the next day, your developer comes back to you with a list of issues; your amazing design work isn’t going to translate to the web in the way you imagined it! Your dreams are crushed and your day is ruined. (Let’s hope you can get a refund on that shelving unit!) How could this have happened?

Although designing a website that looks great and that your client will love is key, it is equally important to consult with your dev along the way—after all, they are likely the one who will be bringing your work to life. This is why a close working relationship between a designer and a developer is so important.

Here are some best practices that a designer can exercise during the design and development process to keep things running smoothly—and avoid unhappy surprises at the end.

Design & UI: You can’t always get what you want

Wouldn’t it be amazing if the sky was the limit when it came to web design? If anything and everything was doable? (Lookin’ at you, Internet Explorer.) Unfortunately, there are limitations when it comes to the web, and whenever you’re unsure what’s possible, your dev can be your guide.

If you have a wild design idea, it’s a good idea to run it by your dev before you get too far into it, only to have them tell you it isn’t doable (and break your heart). Or they might tell you that they can execute your idea in a super simple way. But you’ll never know unless you ask!

The Dumbledores of the dev world

Although developers seem to work magic on our designs, sadly, they can’t read your mind. That super-slick parallax animation you had in mind? Or that wild page build that would definitely take the site to the next level? Your dev can’t bring your crazy ideas to life unless you tell them! Whether it’s using a wireframe walkthrough, some whiteboard sketches, or just sitting down together for a quick chat, make sure that you and your dev are on the same page.

It’s also important not to leave your dev to fill in your design gaps. Although there are a lot of great design tools out there that can save a designer from having to mockup every web page at every screen size, sometimes small details can be overlooked in this process. Hover states, hidden menus, form error styles; these are just a few of the things that might fall through the cracks in the transition from design to dev; don’t assume your dev magically knows what you want for each case.

Feedback & QA: Get buggy with it!

The Quality Assurance (QA) process is often the time when the designer reviews the developer’s work to make sure it matches up with the initial design mockups as closely as possible. In other words, this is the time when the tables have turned, and you get to tell your dev what is and isn’t working for you (try to let them down gently, of course). This part of the QA can get incredibly nitpicky—that border should be 2px wide, not 3px!—but it’s important not to criticize your dev for the small details they might have overlooked.

When you do notice a design flaw, be as specific as possible with your feedback. Sharing detailed information with your dev will help them better identify what’s causing the problem. If you know of a solution that might fix the issue, even better! (For example, “I think increasing that font size from 20px to 24px will fix that problem” is much more helpful than “That font size is too small.”) And while your proposed solution might not always be the best solution, your dev will usually appreciate your attempt to solve the problem.

For more complex issues that need longer explanations, send your dev an annotated screenshot or mockup of the problem you are encountering. Point out what’s not working for you, and try to suggest some solutions! Your dev will thank you.

Finally, be organized! Whether your feedback notes come in the form of bug tickets, a spreadsheet, or a text list, keeping your feedback organized will help your dev be more efficient—and they’ll probably like you more (especially if you have a lot of feedback!).

Bonus: Bring your dev treats. A well-fed dev is a happy dev. And a happy dev is less likely to want to kill you when you ask them to nudge that logo over just one more pixel.