How To Effectively Communicate With Developers

Advertisement

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.

Screenshot1
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

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

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

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

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

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

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

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

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

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

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

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.

Related Resources

Footnotes

  1. 1 http://www.projectcartoon.com/cartoon/2
  2. 2 http://www.projectcartoon.com/cartoon/2
  3. 3 http://gettingreal.37signals.com/
  4. 4 http://www.37signals.com
  5. 5 http://gettingreal.37signals.com
  6. 6 http://www.lighthouseapp.com
  7. 7 http://gettingreal.37signals.com/
  8. 8 http://www.alistapart.com/articles/visual-decision-making/
  9. 9 http://www.fastcompany.com/tag/communication-tools
  10. 10 http://www.betterprojects.net/2009/01/agile-case-study-salesforce.html
  11. 11 http://www.publish.com/c/a/Web-Design/37-Signals-Jason-Fried-Thinks-Less-Is-More/
  12. 12 http://blog.decayingcode.com/2009/06/are-your-debugger-making-you-stupid.html
  13. 13 http://carsonified.com/blog/features/design/everything-you-wanted-to-know-about-designers/

↑ Back to topShare on Twitter

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. http://twitter.com/ryanscherf

Advertising
  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!

    0
  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!

    0
  3. 3

    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.

    0
  4. 4

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

    0
  5. 5

    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.

    0
  6. 6

    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.

    0
  7. 7

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

    0
  8. 8

    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!!!!

    0
  9. 9

    Casablanca web design

    August 14, 2009 9:11 am

    Nice and cool very intersting thank you guy

    0
  10. 10

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

    0
  11. 11

    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.

    0
  12. 12

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

    0
  13. 13

    Funny cartoon :)

    0
  14. 14

    Good Article.

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

    0
  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. ;-)

    0
  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?

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

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

    0
  19. 19

    The first image rocks!

    0
  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!

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

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

    0
  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!

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

    0
  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!!!!

    0
  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”

    0
  27. 27

    *sends this off to his designers

    0
  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!

    0
  29. 29

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

    0
  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)

    0
  31. 31

    I think it is the other way around. Developers need to communicate with the client/boss effectively.

    0
  32. 32

    To say that developers shouldn’t work on the UI, and should just ‘develop’ is ridiculous.

    I deal with designers who have no idea how to create an application that makes sense, or even just a website that flows well.

    To think that user interface lies only in the designer’s realm is both arrogant, and incorrect.

    User interface design should be done by whoever can do it best- no matter what their job title.

    0
  33. 33

    I had sorta left what would have been a rather insulting comment, because this article is somewhat offensive, and I’d rather not be, so I’m changing it.

    I design AND develop, and yes it is possible to do both. The problem with developers is that everyone that is speaking to them, except for other developers, don’t usually know how to communicate what they need in dev lingo. A designer who only designs is pretty much worthless in my opinion.

    0
  34. 34

    Section 6, paragraph 3, sentence 2 – “higher” should be “hire”

    0
  35. 35

    There’s UI designers, and then there’s Graphic Artists who happen to be working on a UI.

    My experience has been that real UI designers are great to work with, and think first in terms of solving the User’s problem, and tend to work great with developers.

    The graphic artist types are really defensive about any changes/deviations from their mockups, and almost universally insist on working up front on their own time without talking to devs at all. When it comes time to code their masterpieces, there’s almost never enough time to finish all the detailed bells and whistles. They also have a really hard time differentiating the important funtionality vs the nice details.

    0
  36. 36

    I almost threw up in my mouth when reading this. I’m a developer and this has to be some of the most offensive stuff I have ever read.

    I thought about making a list of items that were offensive, but then realized that I’m just a big dumb code monkey and I might not understand the issues or be able to craft a pretty enough list.

    I’m with the other developers on this. Please feel free to give me a PSD and let me do everything else. This will save me from having to wait for you to decide how to do the “backend” HTML.

    And another thing. Any designer worth their salt knows enough of the actual scripting language being used to be useful. If all you know is HTML and CSS, please, please, please do not get in to web design. I know how to use CS4, so please learn to use our development apps.

    I can’t explain how happy I am that I don’t work with you.

    0
  37. 37

    I find most if not all of this article laughable. The condescending attitude of the author is extremely annoying. The notion that designers are the ones who oversee and hold the developers hand through the site development is hilarious.

    As a developer I can honestly say that designers along with project managers are always at the core of the problem in every site development cycle. PMs always over promise and continuously allow for feature creep and designers rarely if ever take into consideration the dynamic aspects of a website. Sure you can make a page look really pretty with a well defined set of data but designers hardly ever take into consideration the countless possibilities of data combinations that users actually enter. What if a someone posts a full page comment as opposed to just three lines? What if someone uploads an image that is in a portrait aspect ratio instead of a landscape? As a developer we have to think about all possible ways a user could manipulate a page…designers usually only tend to think about how they themselves would.

    Overall the ideas on communication are fine, but like some have said this stuff is common sense. It’s funny though because designers hardly ever actually do ANY of this stuff. Most of the time we get a PSD and nothing but a “Why isn’t this finished yet?” or a “This doesn’t look EXACTLY like the PSD”. Meanwhile the developer is the one pulling the countless all nighters in order to hit the BS deadline that the PM pulled out of thin air and to implement the usually poorly thought out user flow of a site and functionality that does not yet exist except in the labs at Google. Meanwhile the designer is home every night at a normal hour and sleeping soundly, dreaming about the next version of Photoshop to be released.

    I know it’s hard for designers to put together 10 – 20 PSDs (if that) for a site using an application that lets you draw on the screen basically…so I empathize with you…really I do…but try stepping into my world where you work with actual limitations. As a developer I work with sometimes hundreds of files and thousands of lines of code in something like 5 – 6 different programming languages. While it may be hard for you to take that PSD and hide the layer, adjust the color hue, move an element from left to right (etc.), in order for us to make that change can sometimes require adjusting or rearranging countless files and hundreds of lines of code.

    Developers usually if not always end up holding the designer’s hand to see a site through to completion… as a necessity!

    I have said my bit … I await the onslaught of designer comments.

    0
  38. 38

    Heh. Check out the rage!

    Look people, building a web application requires a large set of skills, not a small set of people. It doesn’t matter whether the UX guy is the developer, or the designer, only that there be someone with UX skills. Someone has to backend code, someone has to do database work, someone has to do admin work, deployment, testing, branding, graphic design, scripting, html+css, security, business analysis, architecture, etc etc.

    In some projects, those skills mostly reside in one person. In others, they’re diversified among most of the team. In general, the more senior the person, the more they’re able to step up and take some or all of the load for these skills – even if it’s not their primary expertise.

    As long as you’re all busy arguing about what the designers role is, without defining which of the myriad of skills actually belong to “designer”, you’re all just sheep passing in the night.

    Here’s the key thing: at the beginning of any project, identify who has what skills and to what degree. Make sure everyone knows this. Then decide where the buck stops for each one, make sure everyone knows this too. After that, it’s all about communication and holding people responsible for their work. If you have html skills but it was agreed that the designer would do the html, then that’s it, you’re not doing HTML unless the designer asks you to. Got a problem with that? talk to the project manager role.

    0
  39. 39

    Oh also, remember that time when you said that designers provide the HTML/CSS?

    HAHA! That was a good one.

    0
  40. 40

    So to summize: the way to effectively communicate with developers is to act and work like a professional.

    And yet it did not occur to the condescending jerk-off who wrote this piece that it may not be the developers who are the problem when it comes to effective co-operation…

    To paraphrase this piece of junk: “Some of us are fortunate enough to find a gem; a designer who actually knows what the f*** they’re doing.”

    It’s not a matter of not seeing eye to eye. A designer who designs an interface for a website or any other piece of software is an important part of the process of developing said website, not an outside force of nature who’s only responsibility it is to be “creative”. If you don’t grok the process of developing software, stick to designing posters and flyers, instead of bitching about developers who “don’t get it”.

    Developing a website is collective effort that involves many disciplines. There’s no room for condescending a-holes who feel just being able to make pretty pictures, sorry, beautiful designs, puts them outside, or god forbid, above that collective. There’s no room for solo artists with a limited skill set in this business.

    Now take your timemachine and travel back to 1995, when clients and designers still thought websites where glorified brochures.

    A developer.

    P.s.: Yes, like many developers I actually read Smashing. Wonder how many designers read sites about development…

    0
  41. 41

    Yes, take a look at the number of developers responding to this article. I guarantee you, you will never get so many designers reading programming blogs. Take this into consideration when dealing with developers.

    Be aware that UI design is taught in most computer science courses and is a fundamental part of any good programmer’s education. Good developers have strong opinions and deep knowledge regarding UI design and functionality.

    Creative thinking is a prerequisite for good programming, and many programmers have strong creative talents in the fields of music, art, writing etc. If you pull that ‘we are different, we are creative’ line, you won’t get very far with that programmer who is into photography and plays drums on Saturday night.

    0
  42. 42

    I agree with “loki_racer.” This article is a little insulting. I think that some of these subjects are a fundamental difference of how designers and developers think – right brain vs left brain.

    We left brain developers have a tendency to think very module, objective, linear and logical. It’s natural for us to think about projects in that way. The look and feel is something that’s icing on the cake.

    But on the flip side, for the person who’s designing, it’s usually about colors, styles, the whole piece fitting a style that represents the entire project, etc.

    I haven’t worked with a designer who understood the difference. This is just in my particular case. But on every project i’ve worked on, I usually get comps that represent 60% of what I actually need.

    That’s because the designer feels it’s complete, maybe because the style is done, or they feel the design guideline is done – which can be copied and transformed into other pieces “follow the style guide”.

    But developers don’t have time to focus on translating a style guide into pieces we’re building. We need stuff that’s ready to go, as is, exactly as the designer wants it. If any “translating the styles” happens on the developer side, it usually leads to a mess, that ends up having to be changed.

    The projects I’ve worked on that were really a breeze and, basically flawless execution, were the ones that the design was done after project specs, and UX. You have to have someone who’s logical, and plans the user experience, and understands the user goals. After that’s done, then the designer puts a skin on UX.

    Again, this is just in my experiences, but often when the designer is putting the comps together, without any UX guides, they tend to think too much on colors, gradients, etc. This is where the problems happen, while they’re working they’re not thinking logically about the user.

    I gotta say, there are some great designers out there. And sometimes I wish I was a better designer. But then I just remember – that’s why I love code so much more. It’s what I love.

    Maybe one day we’ll all be friends

    This article, like so many others was pretty weak. Isn’t “communication” taught in like first grade?

    0
  43. 43

    Hi
    The comment page can not be displayed correctly in IE6.0, And it has last for a long time
    I thought you had noticed this problem.

    0
  44. 44

    The designer needs to talk to the developers before (!) they present their killer features to the customer. In many projects there are technical constraints that limit the features that can be implemented. Communication again ;)

    The task of the developer prior to the start of developement is to bring customer’s expactation, designer’s wishfull thinking and technical / financial reality to one level.

    And never use the sentence “we can fly to the moon, why can’t we implement feateure xy” ;)

    0
  45. 45

    No user stories…. No word about agile? Good luck with this.

    0
  46. 46

    Actually, the main problem is the most common current direction. A marketer works out what could be required. They speak to design, then it gets passed to the developers.

    Everyone should be working together at all times to work out what can and cannot be done. But, the designers should be the last ones to work on any project, to style the content.

    0
  47. 47

    Where is the Interactive Creative Director / Art Director in this? That’s what they are there for you know – they can code and design, and should be over the back of the designer letting them know when their design is going to break interface, and making sure the devs, who can’t tell blue from pink, are never making a design decision. PM’s sometimes can fill this role, but I find CD’s are much more capable of making sure the designs are right for dev, and in my firm, the PM doesn’t have to do anything but manage time and budget, I manage the people and production.

    Honestly, the way it works is that no Dev should get a trash interface – its not their job to design! They dev what they are told to dev. Its the CD’s job to make sure there are no issues with what is delivered to them.

    Most devs can take a psd and make a site out of it exactly how it was designed. Its when the interface doesn’t take into account real world functionality that there is trouble. Its on the designers shoulders to make sure this doesn’t happen.

    Im an ICD, and I can tell you most designers don’t know crap about web. They just don’t think that way, because most are illustrators or print designers who have to get into web to have a job. I require that if you work for me in web you have to learn code, period. I had to when I wanted to get into web.

    I find that the leg work is done up front in design, and usually goes smoothly from there. It is vital that the person managing the Designers be both an excellent designer and Dev. Devs are not difficult to work with, on the contrary, Designers – pure Designers – are the most difficult employees in the office, hands down. Ask anybody in a firm.

    0
  48. 48

    Hilarious the reaction by a few developers here. This piece was so not offensive if you would have actually read it and got your ego’s out of the way. Sure, you can probably do a lot more than code, but that isn’t what this article was about. And if you wanted to do more than code, there was also a section about communication and answer questions. I would assume this is where you could have your feedback.

    As a developer, we all have egos that we need to get over. It’s funny to hear everyone say “people don’t know how to talk to devs”. Look who is condescending now @loki_racer and @rick. It’s a good thing you guys know everything so you don’t need designers, but I certainly do.

    Since you think you are smarter, write your own article and submit how it should really be done.’
    Thanks for the article!

    0
  49. 49

    Very helpfull !
    Thanks a lot

    0
  50. 50

    @Jason A – I never said I found the article condescending. I said it was offensive. I’m pretty sure I’m allowed to be offending by things.

    Being labeled as having an ego is a little offensive as well. I never said what developers do is anymore important than what designers do. I don’t work well with people that see developers as code monkeys and don’t take kindly to people writing articles making statements like this article did.

    0
  51. 51

    @loki_racer

    “I know how to use CS4, so please learn to use our development apps.”

    Nope, no condescension. You better watch out, the world is pretty offensive.

    “I can’t explain how happy I am that I don’t work with you [on my development team].”

    It’s a good thing you learned everything in the first grade.

    0
  52. 52

    I got a nice smile when I saw the illustration as it was the one my teacher used in a computer engineer class last year :) Good points and relevant article! Keep up.

    0
  53. 53

    @Jason A

    How is me asking designers to understand a little about development condescending? I’d love to hear the logic behind that. A designer that lives in a box of simply pumping out designs and doesn’t have a clue or care about learning a little development isn’t going to make it far in the industry. I consider photoshop just another tool in my toolbox of apps. By asking designers to understand how to use nusphere, zend IDE, etc. I’m actually asking them to do a little professional skill development.

    When did I say anything about first grade? Have you ever actually had a real debate?

    I’m sure your response will have some very random points to be made, but I’m done arguing. I made my point in my first comment. You just didn’t like the points I made and decided to try and put words in my mouth.

    0
  54. 54

    Nice article, at least most parts but it’s a shame that developers (or are they?) started to storm out already.

    I’m working for a web 2.0 project with a desktop application. We are building our website and application multi-language and client based (changeable colours and images). As a UI Designer and Graphic Artist, I also tried to learn basic coding. I always ask developers what they are using? How do they do some features so I get the feeling. I send PSD, CSS and sliced images when I’m working on something to developers.

    Since 99, I’ve worked with a lot of developers and most of them were like stubborn child. They are not open to listening designers who might know better than them when the subject is design! System is based on developers working on coding, sure there are guys who understand the importance of design but most of them don’t! And they shouldn’t! All They have to know is how make it. Most of the time, Boss/Project Manger tells me that developers complain about my designs because they are not possible to do but they are! I don’t design something before trying to code it!

    A good designer never make a design which is not possible to code. If you are claiming so, you didn’t work with a good designer! That is it!

    0
  55. 55

    Mark @ AlchemyUnited.com

    August 15, 2009 11:06 am

    Interesting. I also agree with some of the other comments that this is common sense.

    That said, IMHO this makes a case of havinng the developer(s) involved earlier in the design / project process. They are where the rubber is meeting the road. The more holistic their understanding is the more likely they are to make architecture and coding decisions that are more flexible and in tune with the possible evolution of the end client’s biz needs.
    Designer’s design but it’s the developer who’s bringing the biz rules to life. With all due respect many designers don’t seem to have the necessary biz chops.

    In short, there’s nothing to be gained from keeping the developers in the dark to the end.

    IMHO, of course ;)

    0
  56. 56

    i have been told that i am a developer that ‘gets it’…
    this was fun to read!

    i started with design, but didn’t have that ‘eye’ for the screen… i decided to stick to paper illustration as a hobby, and then development somehow took over my electronic life. i think that the small design background helps me out with my development a lot, and i would suggest for all developers to experiment with design, and read a lot about good design practice! (i am always on SM and tons of other sites- will refrain from mentioning because SM is one of my all time favs)

    good article!! if you darn designers would just COMMUNICATE (haha) we would all be happy. cheers!

    0
  57. 57

    upon reading these comments, it is clear that most designer/developer combos have yet to sit down for that first cup of tea/coffee that gets you excited about working on a project in the first place.

    take it slow and see how you work together – don’t hold in all of your frustration and take it out on blog comments! if it doesn’t work from the beginning, you’ll know.

    communication++;
    fun=1;

    0
  58. 58

    I work design/development/management, and the last graphic designer I dealt with was rather green yet thought themselves the expert and I wanted to tear my &4@!#ing hair out, worst yet the client thought the designer was the expert too and would say let me find out what “***” says… !!!

    bizzaro world

    Thank god thats over.
    Sprinkle some crack on the designer “lets get out of here”.

    0
  59. 59

    The business of developing websites is getting increasingly more professional as sites become more complex and clients demand real results.

    In my experience, the designers that display the kind of attitude as the author and some of the commenters are slowly but surely becoming a dying, are rather soon-to-be-unemployed breed. (And yes, the same goes for the kind of autistic codemonkeys the author seems to believe all developers are. Like some designers should go back to designing print, those kind of developers should go back to coding enterprise software in some IT department.)

    Luckily that still leaves plenty of talented, professional designers and developers that do “get it”, that understand that great user experiences can only be created if many disciplines (“designers” and “developers” are a btw ridiculous simplification of the many skills involved in building a website) work together towards a single goal.

    And working together, respectfully and professionally, is almost the opposite of what this article is portraying. Good designers should be just as offended by this article as some developers are.

    0
  60. 60

    I love the cartoon. :D

    0
  61. 61

    Um maybe the Project Manager, Designer and the Developer should sit down and chat about possible solutions for the specific project before the designer whips up anything or the project manager tells the client any ETA. that would just make since and is the only way i will participate in any project. to have the designer come up with a design to solve the customer’s problem with out first researching and speaking to the developer is nonsense. Any good developer should have a wealth of knowledge about the limitations and the end user experience, to not take advantage of that is disrespectful to both the client and the developer. I’ve worn both shoes, and can empathize with both sides, but even more than communication, i think all the “team” members need to be on the same page from the second the project begins.

    0
  62. 62

    Well I found this to be a good article, it is very Web app or simple 2-tier client server oriented. When designing a complex n-tier enterprise app the UI is just not that critical as an initial design document or even a guide. You can have a great design for the UI, but in n-tier its doesn’t tell you all that much about what has to be done in the back end (other than what data ultimately gets published to the UI). Even with a great UI, you can still royally screw up the back end in a n-tier app and end up with a total piece of crap.

    0
  63. 63

    Hehehehe … that cartoon is a classic !!! … As a designer I’ve dealed with developers for many years and I found a solution: to develop by myself, lol … it’s a joke but, sometimes, for small projects or things that developers just don’t undertand what it needs to be done I really do by my own hands.

    0
  64. 64

    Quite a flame war. I’ve worn both hats, and managed projects for 5 years beyond that. You could answer the question that the article poses in two words or less:.: “Be specific.”, or “Communicate.”.

    If someone involved in the design or development of the web site didnt do what I asked for, and (as the customer) it was dellivered to me, I’d question the communications skills of ALL of the people in the company. As a former owner of a web company, remember that the customer sees One face – the web company. When either ‘side’, designer or developer, bickers or rants, it makes the whole team look bad. And as the guy paying for it, I just don’t care. Just suck it up and communicate. That’s the objective of a web site, right?

    Amusing cartoon, but the most obvious hole in it… QA tests whats delivered, right? The pictures are different…Somebody got carried away with the entertainment value rather than attempting to represent reality.

    0
  65. 65

    this is just a theory.. but nice post

    0
  66. 66

    Blaming developers or designers for projects gone wrong is pointless. I happen to sit on the developer side of the fence, but the key to all successful projects is simply good communication. People are not mind readers. I personally have little fear of my job being outsourced because I have worked with developers in non English-speaking countries and the upfront savings are almost always canceled out by costly miscommunication, even when the workers have good intentions and are excellent technical coders. Tip: if your developer can’t carry on a short conversation about the weather he probably won’t understand and correctly implement your 45 page specifications doc.

    Designers: be very specific in your designs, and remember that not only must you provide a static pretty picture, but you must also communicate the flow and usability of a website and consider different scenarios. What if the title is two lines long? What if this page doesn’t happen to have a photo like the one shown in your mock-up? When a form is submitted incorrectly, where will the error mesages appear? And so on.

    Developers: be very detailed upfront about what you are going to implement. Put everything down in writing or email first. Ask for wireframes before final designs. Clarify any and all gray areas before you write a line of code. Re-work and re-coding is frustrating for everyone.

    Most of all, when you’re not sure don’t assume… ask! The development process needs to be one of collaboration from start to finish.

    0
  67. 67

    This is perfect and very unique article.

    0
  68. 68

    As someone who works in a large Enterprise operation (one that has an aforementioned QA team), I can tell you that as a site or software becomes more complex that the it’s often the designer who has not considered all the cases in a scenario (boundary cases, error handling, etc.). In the worst case, where there’s no time to rethink a design (and make more changes), it’s up to the developer to fill in the gaps with the current structure.

    I definitely agree with bringing the developer and designer together at an early phase to make sure goals are aligned. Instead of playing the blame game at late stages in a project, the designers and developers should be working with each other to overcome issues. If the designer is able to rationalize and justify (“sell”) features and changes to developers up front, I believe they will have more cooperation in the long term.

    0
  69. 69

    Great post, thanks!

    0
  70. 70

    Well, what is a developer? Seems like many of the design folks here, worked with developers that got educated by reading blog posts. Get yourself an certified Software Engineer and you will be happy ever after.

    I agree to Mike Palmer. Developers often need to fill the gaps, because most designer’s work end with one or two PSD files while the final web application may consist of hundreds of views in different states (user logged in / user logged out / etc.).

    In many projects time is a valuable resource. So most of the time, the developers need to start coding before the final design is ready. The developers construct their system to meet the functional requirements as well as the non-functional ones like response time. So when the design is ready many development decisions are already made and thus there are technical constrainst that need to be taken care of in the design

    0
  71. 71

    i like the progess bar n tickets pending ;)
    Good one

    0
  72. 72

    Do you know Agile method ? This is another way to develop software and particulary web site.
    On this website you can learn about agile philosophy : http://agilemanifesto.org/
    Personaly, i am a scrum master, one of the method of agile world. With that you can do more and better developements !

    0
  73. 73

    Ever considered using a proper software development process with clear roles, responsibilities and more? Just search for “software development process” or go to Wikipedia. I’m sure you’ll find something which supports your type of project or you can tailor it to match your needs.
    PS: I like the cartoon too even it is not new. I used to work in mainframe projects 15 years ago and almost every office had a cartoon like this on the wall.

    0
  74. 74

    For those of you saying the article doesn’t talk about Agile, you should look at the bottom Related Resources.

    “An Agile Case Study from Salesforce.com”

    0
  75. 75

    the designers & devs should (i wish!) band together and force stakeholders to follow these two principles –
    1. Don’t change mid-cycle
    2. Set realistic deadlines

    :)

    0
  76. 76

    I’ve done both designing and developing. I’d rather just do them both myself so there’s no miscommunication. Haha. I agree with the previous comment, though. I would say those are also issues clients would need to be aware of too. Don’t change mid-cycle. Especially when the concept and mockups explained very thoroughly what’s going to be done and the stamp of approval was given… Just to change it. UGH.

    Designers and developers–get over yourselves! I feel like the people bashing each other and the article are all people who probably need to understand this article the most and missed the point. Learn to communicate, some people just don’t have the brain functionality to do both, which is why we need each other as well as others to help foresee projects to completion. Having been on both sides, there’s no need to be offended. Some developers really just don’t get it and some designers really have no idea either. That’s why I don’t understand why there isn’t more “forced” or “required” (for lack of a better word) interaction between the two (ESPECIALLY in the early stages) in some businesses/agencies or even in educational institutions. It’s pretty absurd.

    0
  77. 77

    I’m working as a UI designer and I need to say that there isn’t a very big difference between designers and developers. First tend to know nothing about usability and UX design or XHTML coding, while developers prefer to question every UI that requires actual coding. That’s why it is very important to have a Usability Engineer or UX/UI designer lead the usability, interaction and UI design. Seniority comes with experience, as well as the knowledge.

    0
  78. 78

    One thing that helps effective communication is correct grammar.

    “How to Effectively Communicate with Developers” is incorrect. It splits the infinitive. This would be correct: “How to Communicate with Developers Effectively” That might be a nit to you, and it certainly doesn’t prevent understanding, but it is still an error.

    The first paragraph of you article contains at least one grammatical error — I didn’t check for others.

    0
  79. 79

    It is very important for a designer to work at least one entire project life cycle to understand his job better. Else he would think he plays the most important part in the project. once you know what developers do with your HTML, you know how important it is to write clean code. A UI designer who knows how things work in backend can create better stuff. Many are just graphic designers with little understanding about coding and user experience. Similarly most developers and project managers ignore users. They think only functionality. How users interact with the system is most important. It takes time for designer to think beyond his designs and for developer to think beyond functionality.

    0
  80. 80

    As a developer this is a wonderful post for designers. I like to think that I’m a developer who “gets” it when you come to me with requests and requirements. However I’m not a mind reader and getting as much documentation as possible is wonderful.

    I’ve got a designer I did some work for who would give me a PSD and that was all of the input I’d get. I may get a paragraph or two in the email outlining basic things like rollover colours or what not, but for the most part I was on my own. What was so frustrating was he’d want complex work done neglect to tell me (this is why I’ve dropped him) and then proceed to make me feel like a bad developer because he either didn’t state what he wanted or had a warped sense of how the web worked.

    I LOVE it when I get as much information as possible because the likelyhood of me doing anything wrong drops significantly whereas when there’s very little information projects change mid-stream and there’s nothing that can be done with it.

    0
  81. 81

    Congratulations @Doug117, you have shown your grammatical superiority. It’s great to know you spent time reading the points throughout the article.

    0
  82. 82

    Working in big software development project as an user experience designer & interaction designer it is really interesting for me to see on a daily basis how big cultural differences are between developers and designers.
    I am glad to have an educational background in interection design which among a lot of other (theoretical) education considered the formal and emotional aspects of visual design, the structural aspect of writing object oriented code and the experience a user may have tested through rapidly created prototypes.

    Still a lot of developers think of the designer role as the one who pushes pixels in Photoshop while a lot of designers seem to feel secure in this role and don’t take responsibility in creating an user experience which is more than the static expression of a PSD file could express. 
     
    When a product hits the market in the end neither the developer nor the designer are going to be the daily user of their product.
    In the developement process the creation of personas, scenarios and use cases helps creating prototypes which need to have a certain detail of viusal design and logic to mimic the function to be tested with the real users.

    In the end a developer doesn’t like to be told wether to use an “if or while loop” as a visual designer won’t appreciate when his colors, type and layout gets changed. Roles have to be clear to everyone. 

    My 2 cents,
    Daniel     

    0
  83. 83

    loki_racer: you said, “I’m with the other developers on this. Please feel free to give me a PSD and let me do everything else.”

    I’m a designer, who has frequently worked with devs, and while i KNOW there are plenty of developers you can hand a PSD off to, I have worked with the same amount who you cant do this with. I have given PSDs to devs and come back to see incorrect fonts, colors, sizes, measurments – nothing what looks like the design I handed them. Ive literally had to sit down and walk them through it. I found the best solution to this is to write out every font name, size, hex code and measurement. Its very tedious – but so far they LOVE that I give them all this information, and we usually get a close to perfect outcome.

    0
  84. 84

    If you cant communicate with a developer, you shouldn’t be designer, because you were never a developer, and I find the whole intro offensive.

    I guess I dont “get it”.

    Im not a religious man, but “dont throw your pearls to swine” is in my vocabulary. And that usually applies when Im talking to wanna be designers.

    Never seen a designer. Only someone who has been promoted beyond coding. Too bad.

    0
  85. 85

    What’s amazing to me is the he-said-she-said attitude between a lot of the designers and developers on here. Until designers and developers can break down those barriers and actually begin working together these problems are going to continue. Everybody should be working together through the entirety of a project, not just completing their part and then passing it off to someone else.

    A Developer

    0
  86. 86

    Thanks Ryan.
    This has really been a useful material not only for me but for my team mates. However, in building a solution, it is important that the technical architects and coders focus more on functionality and the flow that needs to happen and not on GUI.

    0
  87. 87

    This article official pissed me off! I am always amazed, when I read articles like this, by the total one sidedness of graphic designers on this site. I am a developer, but for the last five years I have been doing the design also. The reality is that both designers and developer need to have a clear communication to insure that the design can be achieved from a coding stand point and the developer needs to attempt to stick to the design as much as possible. Please stop perpetuating this ridiculous debate about who is right because there are very real limitations to overcome when coding a design.

    0
  88. 88

    @ Doug117
    The rule about split infitives isn’t a real rule. It was just made up by people who want to appear more literate than they really are. Check it out.

    0
  89. 89

    Doug117…The last paragraph of “your” article contains at least one grammatical error.

    0
  90. 90

    the best article ever!!

    0
  91. 91

    It’s “Hire” not “Higher”

    0
  92. 92

    Very cool article! We wrote a two two-part series on developer and designer collaboration. Looks as though we have a lot of similar ideas!

    http://www.springbox.com/insight/post/The-Designers-Perspective-on-Collaboration.aspx

    http://www.springbox.com/insight/post/A-Developers-Perspective-on-Collaboration.aspx

    0
  93. 93

    Really good article. I’m presently in the middle of a NIGHTMARE at work. I’m a developer, with an incredibly tight deadline, and the designer I’m working with just agrees to everything the client wants. I am now absolutely posative that we are going to miss our deadline (we were so close to getting the site redesign signed off, and next thing I know they’ve had a meeting and now the site “needs” an interactive world map that zooms and animates).

    If I show the designer this article though he won’t read it :(

    0
  94. 94

    Have written a response article to this one, if anyone’s interested;

    http://mikeyhogarth.wordpress.com/2010/09/12/why-do-designers-and-developers-fight/

    0

↑ Back to top