Menu Search
Jump to the content X X
Smashing Conf San Francisco

We use ad-blockers as well, you know. We gotta keep those servers running though. Did you know that we publish useful books and run friendly conferences — crafted for pros like yourself? E.g. upcoming SmashingConf San Francisco, dedicated to smart front-end techniques and design patterns.

How To Effectively Communicate With Developers

If you have ever worked with a developer or a development team, this article will probably strike close to home. As designers, we work with dozens of developers across the globe each year. Some of us are fortunate enough to find a gem; a developer that just gets it. A developer that you feel is on your same wavelength in terms of what needs to be accomplished with the user interface, and what it needs to happen. Most often, however, we find developers that we generally don’t see eye to eye with.

When many people are involved in a project, it is very important to make sure that they have a common understanding of the problem and its solution. This cartoon2 shows how projects really work in practice.

This is not meant as a slam on developers, as I believe they are a much different breed than designers; rather, the hope is that if you follow some of the principles outlined here, your development process can hopefully be streamlined a bit more than it was before.

1. Provide an adequate level of documentation Link

Modern software development methodologies may lead you to believe that less documentation is better, however this isn’t necessarily always the case. For starters, the best documentation that is provided is the user interface. Not only does the UI show the developer where data should be and how it should be formatted, but also represents the basic flow of what needs to happen. A well thought-out and complete UI will make you a developer’s dream colleague. Granted, there will always be developers who don’t like everything defined and love to take liberties with your interface. These developers are rare (and most of the time unwelcome) in the design community.

Stay ahead Link

As a designer, you don’t need to have every single page thought out before starting development, but it is helpful to stay ahead of the developers. Plan your features accordingly, and make sure you at least have some type of structure (HTML, etc) ready to go when they need it. It is a lot easier for developers to come through on a polished page and insert data where it is needed instead of creating the page from scratch and having the designer come in after them.

2. Be decisive Link

As designers, we make hundreds of decisions on each interface we work on. Whether it is the height of navigation, the amount of text in a table cell, or the alignment of text in the footer, we need to make many decisions each and every day. This is very much like for developers who have just as many (or more) nitpicky decisions to make on every piece of functionality they write. But the beauty of development is that it is less subjective than design. Sure, the architecture, code style and language could all be subject to opinions, but not in the way that design is subjective. Some people prefer stock images, while others illustrations. Everyone has a favorite color, while many colors may be perceived differently by every person.

As designers, we need to decide what the interface should look like. Although some developers may enjoy tinkering with the UI, it’s not their job; and ultimately slows them down from what they should be doing: developing.

Don’t change mid-cycle Link

It is also important to try not to change the design while the developers is in the middle of developing that specific feature. Agile and Scrum methodologies insist that the developers work with the requirements they had at the time, and in the following sprint, the developer could revisit the feature and make modifications. As designers, we should try to avoid any type of refactoring of the UI as we can. It is tedious work for developers to go back and change HTML.

Choose an HTML structure and stick to it. Try to account for any type of design feature in your first draft of the HTML (even if it makes your HTML seem somewhat bloated). CSS should already control the look of your interface, so try to think of HTML as backend code that is more difficult to change than a font color in CSS.

Developers don’t like refactoring their code as much as we don’t like providing revisions to clients. Get the ‘most perfect’ result as soon as you can.

3. Communication is key, so be available Link

You have spent countless hours mocking up the UI, polishing it to your liking and you’re ready to hand it off to the development team. Often times, this is where design ends and development begins. As designers, this is where we should be most involved to ensure that the design concept is fully realized in the working application. Avoid just ‘throwing the design over the fence’, and hoping the developers implement it exactly how you have envisioned it in your mind.

Stay Involved Link

it is also important to not drop off the project here. At the least, be available by e-mail so the developers can contact you about issues with your designs. Respond quickly to ensure your developers are staying on track with the final product. Once again, be decisive in your communication. Most of the time, the real data doesn’t match what you mocked up, and there are many issues you will need to work out in conjunction with your developer.

4. Avoid feature creep Link

Getting Real by 37signals3

The crew over at 37signals4 recently wrote a book called Getting Real5 which talks about this exact problem. This topic probably stems more toward product managers, however it is also important for designers. Always ask yourself, “why does this feature matter?” Avoid a UI that is far too complex, as it only adds time on to development, and ultimately forces you to miss deadlines. If you can’t come up with a good reason why it should be included, then it doesn’t need to be there. It will only slow your team down, as well as create more for you to support.

Stay Focused Link

Focus on what is important for your users. For example, if your users aren’t going to use invoicing heavily, or you already know better alternatives exist in the market that you can’t beat, don’t include them.

As we developed one of our recent projects, we weren’t planning on providing a full suite of tools that included invoicing. We wanted to concentrate on proposals, bids and RFPs; knowing that we still needed to serve a small userbase that may require invoicing. We choose to add in a bare-bones system (simple line items, nothing recurring), because we felt it may be useful to some people that didn’t already have an invoicing solution. We also realized that users probably wouldn’t want to switch to our invoicing system (mainly because they already had a solution), so there was no sense in creating something robust.

5. Set realistic deadlines, and stick to them Link

As designers, we can quickly turn around designs in a few days and be done with it. Unfortunately, this is not the case for development. The ratio of design to development hours is not even close to 1:1. Make sure your deadlines allow enough time for the developer to implement the features, as well as any back and forth time for questions.

No matter how hard you try to hit your deadlines, something always comes up. Perhaps another project, kids, family, etc. Try your best not to announce any hard dates until you are absolutely sure you will hit them. Announce the week before (or even month before) if you feel comfortable. If you just started a project, never commit to launching in the next 6 months. It just won’t happen, and your users may or may not hold you accountable for that date.

Don’t make promises you can’t keep Link

As irritating as missing deadlines is for you and your team, its even more irritating for potential customers that are waiting for your app to change their workflow. Be vague about deadlines, and keep people wanting more.

6. Test it yourself Link

Don’t rely on your developers to write perfect code, as it will never happen. You can’t always rely on developers to test their code to make sure it functions properly, fulfills requirements and ultimately works in the manner you described. But remember, developers don’t write buggy code on purpose. They would rather write perfect code and work on newer, cooler features each release. Since your developers are so close to the code and system, they will inevitably miss something. Don’t blame them, help them fix it. Explain to them where it’s failing and what the desired action should be.

Track bugs with Lighthouse6

Also as you take on the testing, this frees up the developer to keep moving on the back-end, which once again, is where they should be focusing. And as you find bugs, make sure to fully document them, including screenshots, how to recreate and most importantly, the desired outcome.

Of all the developers we’ve worked with, none of them have been interested in any type of testing past in-the-code unit testing. Large enterprise shops higher entire Quality Assurance teams to follow-up on developers work (which doesn’t make it right, but it’s the way it is). Help your developers out by testing their features — your app will be much better for it.

One last point is to measure performance. Set milestones and goals and make sure you are hitting your marks. Try to monitor how your team is doing on fixing bugs versus creating new features, as there will always be a snowball effect. Fix bugs early and often to prevent them from growing into larger and more complex bug colonies in the future.

Footnotes Link

  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
  8. 8
  9. 9
  10. 10
  11. 11
  12. 12

↑ Back to top Tweet itShare on Facebook


Ryan Scherf is a freelance web designer, developer and entrepreneur. When he isn't wasting the day away on Twitter, he can be found building his most recent venture SixCentral, a client proposal organization & management application.

  1. 1

    there we go!

    a sort-of “back to basics” post, but at least it gets back to some real content. you guys do really great work so i feel a little guilty bashing on the “inspiration from tv” post, but that post was really off.

    nice post!

  2. 2

    Yeah! Great article!!

    However, I would like to point out that with the world being so globalised, developers from different countries and backgrounds working together is not surprising. Sometimes we as designers only get to work with Project Managers who manage a group of such developers, whereby communications become two-tier, and language barrier might be one of the so many reason. So, just a suggestion, maybe the presence of a Project Manager could be considered in this aspect.

    My two cents. Cheers!

  3. 3

    Richard Conyard

    August 14, 2009 8:17 am

    I can’t help but feel you missed a point here. How about explaining to the developer what you want to achieve and what the goals of the project are and have that clearly documented.

    As per point one, personally (and for pretty much all of my development team past and present), project specification through UI is horrible, bits get missed, the true functionality of UI gets misinterpreted and the developer ends up having to sit down with the UI and derive their own specification. This then generally ends up as a licence for overrun, scope creep and projects from hell.

  4. 4

    We need a “How To Effectively Communicate With Designers”. Being from a Dev background I know good developers are great a documenting and communicating. The break down in most projects is the Customer or the Designer. The Developers and Project Managers tend to be the only ones that really know what is going on in my experience.

    Good article on communication though.

  5. 5

    Zack Grossbart

    August 14, 2009 9:33 am

    As a developer and a designer I enjoyed the post, but I think you missed the biggest way designers can work well with developers: let the developers help solve your problems. The goal of the design process is to create an understanding of the product and how it will help customers. Many times engineers can help improve the UI with a deeper understanding of what will work better or worse with a given system.

    Even if that doesn’t happen, developers are much better at their job when they have a good understanding of the problem space. Don’t assume developers won’t care about design. Every developer I know wants to make a product that delights customers, they just need your help to see how good design can make it happen.

  6. 6

    Very nice opener illustration. Good article.
    Have a Happy Weekend y’all.

  7. 7

    Alexis Brille

    August 14, 2009 8:44 am

    Haha, those images are the same ones my lecturer used in our project development course.

    And this post seems like our case study answers, lol.

    To me, all this is very general and instinctive.

    It has a great topic however, the content doesn’t offer any new useful points.

    But I could sound sour just because I’m sick of studying and memorizing all this, :D.

  8. 8

    This is very helpful. I am printing it out to save in my helpful articles binder. Nice!

  9. 9

    Hey… Great article…!
    really needed…!!!
    Yes! developers and designers actually face all the facts mentioned by you… thanks for the solutions.
    Communication is key <— fact!!! very nice.
    Described very real situations and facts.
    GREAT POST!!!!
    THANKS a ton!!!!

  10. 10

    Casablanca web design

    August 14, 2009 9:11 am

    Nice and cool very intersting thank you guy

  11. 11

    Did I miss something? This article goes right into the common sense category for me…

  12. 12

    Well Said, now what do I do with the developers who like to tinker with my designs ;-)

  13. 13

    Funny cartoon :)

  14. 14

    Good Article.

    (side note)
    Pre-order link at the top takes you to a 404.

  15. 15

    Interesting post, and I feel this works both ways – developers should also communicate to designers what is logistically possible regarding a design. Too many times I’ve worked for agencies who present completed, signed off designs which look utterly fabulous, but are ultimately horrendous to build.

    Yes, it’s a dream to find a developer who is sympathetic to design, but it’s also a dream for a developer to find a designer (and a project manager, for that matter) who actually understands how a site is built, and for them to quote a realistic timeframe to a client (“It’ll take 3 weeks?? We’ve told them it’ll be complete by tomorrow!”)

    Oh, and it’s also lovely to find a designer who doesn’t insist on presenting designs containing transparent rounded corners and gradients everywhere. Sigh. ;-)

  16. 16

    Great post. It just so happens that I’m being contracted to do UI design for a Application based in Colorado (where I’m located) but the developers are in ireland so not only time delay but just basic communication that we want to move and style this object doesn’t mean it’s a new feature. It’s becoming frustrating, I can’t wait until we move development to the US. Hopefully I can apply some of what you’ve said to help me with my communication with the devs.

    Anyone else have any good advice?

  17. 17

    I once worked as a front-end developer for a poker website. The marketing were based in Gibraltar, the designers in Malta, and the developers in Stockholm. It’s safe to say that nothing we did turned out how the marketers envisioned. Get everyone on the same floor of the same building, ideally in the same room.

  18. 18

    Good stuff.
    I’m lucky enough to have my “developers” about ten ft away from me and even so, completely agree that language and communication are key to an effective website creation.

    I also tend to find that if your project manager/Lead Developer comes from a programming background, the hardship is on the designer, and vice-versa if from a designer/marketing background. If you’re lucky enough to find somebody who is a balance of both disciplines, you’ve found a best friend for life. A literal cat/dog life form type thing

    I never watched that cartoon. Freaky crazy.

  19. 19

    The first image rocks!

  20. 20

    connecticut websites

    August 14, 2009 10:57 am

    better to be a designer AND a developer.

    btw, much better topic than inspiration from TV…leave articles like that for E!


↑ Back to top