Menu Search
Jump to the content X

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
  13. 13

↑ 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

    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.

  2. 2

    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.

  3. 3

    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!

  4. 4

    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!

  5. 5

    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.

  6. 6

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

  7. 7

    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!

  21. 21

    I was just talking about this and realized that 90% of the conflicts I have had as a developer have not come from a lack of communication from the designer, but from the project manager. For the most part the designers I have worked with have been very communicative, and rarely have had an issue where the development process modified the outcome of the project from a design perspective. Usually if I come to an un-specified portion of the site that requires a design, we can collaborate and create a quick wireframe and work from there. Maybe it is also because I can’t tell a Primary Color from a hotdog, so I rarely ever try to add new elements.

    This article rings extremely true in my opinion however if you replace “Designer” with “Project Manager”. The top problems I experience evolve from scope creep, false promises to the client (“we can do that!”), lazy timelines (not actually scheduling accurate timelines due to putting it off until the last minute) and not effectively communicating technical requirements to the client.

    So as for Designers and Developers – we’re on the same side! Effective communication is all you ever need.

  22. 22

    Andrew Pendletorn

    August 14, 2009 11:58 am

    From a developer’s perspective, I’d add a couple of things, sort of on the harsh-truths end of the spectrum: first, don’t condescend. Lots of developers are major users of web applications, etc., as well as authors of them, and have a sense of when UI doesn’t make any sense, even if they don’t have formal design training. I can’t count the number of times I’ve worked with “web” desigers whose background was in print, and who insisted that they always knew better than me even though they didn’t understand how to design for the web, because they had the Elements of Typographic Style on their shelves (which is also on mine, by the way). We sometimes have useful skills, too.

    Second, play to your strengths, and to theirs. The post says to deliver something with structure, like HTML, but often times, designers’ strong suits are not writing good markup, and that’s something lots of developers do really well. If you know what you’re doing, great, but if you’re going to hand over an incomprehensible pile of tags with IDs like “div_4,” I’ll take the layered PSDs and write my own, thanks. It’s not something I mind: I’m the one being paid to write the code, after all.

  23. 23

    I’m now a freelance web designer and developer, but in my past life (full-time job) I was primarily a developer. As others have mentioned, the biggest difficulties for both designers and developers actually came from product management — scope creep, unclear requirements, endless “tweaking” requests, and unrealistic expectations.

    I liked the emphasis on communication in this article, but I’m picking up on a little condescension toward developers. The fact that QA departments exist is not because developers are sloppy or lazy. Think about it this way — if you’re writing a 100-page document, you’re not going to hit every keystroke correctly the first time around. Some errors you’ll catch as you make them, some you’ll catch as you read over what you’ve written, and some you won’t notice until others point them out (I’m sure they’re in this post!) That’s why editors and proofreaders exist. A good coder/writer will minimize the number of mistakes, but they happen to the best of us. And of course, if designers/product managers/clients are hovering over your shoulder, changing the requirements and rushing the process, the likelihood that bugs will crop up increases exponentially.

    Well, I’ll step off my soapbox now. :) And I do sympathize — I’ve definitely run into developers who look down their noses at designers, and clients who think that they can do a design job when they most *definitely* cannot. So thanks for writing the article!

  24. 24

    My general experience as a developer has been about 70+% of the time the designer and/or project manager blow off or somehow hose up the scheduled project time line (i.e., assuming they didn’t just pull it out of their toe in the first place) and when push comes to shove the developer has to belly up and deal with a massive work load in a short time frame. Throw in the extra headaches of trying to figure out what the customer “really” wants along w/ usual recipe of bogus documentation and double talk crafted by management and the developer is up against it almost always. The only projects where this doesn’t happen is when I can interface with the client directly and have total say over the specs.

  25. 25

    I think exist something very wrong about this.

    Is with the *customer* or actual user that *both* need to talk about. The designer is as bad as anybody on define a project of software. The designer is not the key role (except if the website have few soft requeriments).

    Also, sometimes (sorry, EVERY time in my experience) a designer not know or understand the limitations that impose the plataform where we develop on. For example demanding that the desing of the website look exactly as in photoshop and complaining when not.

    I have the impresion that “designer” here is more a “software designer” than a “graphic designer¨. A graphic designer probaly is as bad as any other in layout a software, build the interaction rigth, define the steps, and know what is 1, then what is 2, 3, 4…. IF “designer” here is a software designer, then everything is ok.

    Is very, very bad drive any kind of development from the UI. That plague a lot of developers. Is far better drive the application from the user expectation, requeriments, challenges, etc.

    When somebody commit the mistake of drive development from the UI, then is very likely that the internal desing get messy. However, when is clear the intention and have a good understanding of the actual process, a good UI mockup help A LOT!!!!

  26. 26

    Great post. I loved the line “Since your developers are so close to the code and system, they will inevitably miss something. Don’t blame them”

  27. 27

    *sends this off to his designers

  28. 28

    I haven’t even read it and its brilliant! I’ve seen that first image so many times I understand the article already!

  29. 29

    Nice, cool and very interesting…. thank you, mate

  30. 30

    Sorry, this post has several flaws. I won’t go into details, but here are a few realties of software development that you need to consider:

    – Users want functionality, not a specific UI design. If I tell a developer to build something based on a user interface design the underlying functionality will be lost or misunderstood. Tell the developer what the user wants to achieve.

    – Requirements change. You can’t stop them from changing. The reasons why they change include changing business environment, changes in the organization, new insight gleaned as developers provide incremental functionality.

    – There are different levels/seniority of developers – you need a mix of senior leads that can interpret requirements, and code monkeys that can write code (to which your article seems to assume all developers are)


↑ Back to top