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.

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

Advertisement
  1. 1

    @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
  2. 52

    @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
  3. 103

    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
  4. 154

    @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
  5. 205

    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
  6. 256

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

    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
  8. 358

    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
  9. 409

    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
  10. 460

    I love the cartoon. :D

    0
  11. 511

    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
  12. 562

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

    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
  14. 664

    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
  15. 715

    this is just a theory.. but nice post

    0
  16. 766

    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
  17. 817

    This is perfect and very unique article.

    0
  18. 868

    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
  19. 919

    Great post, thanks!

    0
  20. 970

    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
  21. 1021

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

    0
  22. 1072

    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
  23. 1123

    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
  24. 1174

    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
  25. 1225

    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
  26. 1276

    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
  27. 1327

    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
  28. 1378

    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
  29. 1429

    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
  30. 1480

    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
  31. 1531

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

    0
  32. 1582

    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
  33. 1633

    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
  34. 1684

    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
  35. 1735

    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
  36. 1786

    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
  37. 1837

    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
  38. 1888

    @ 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
  39. 1939

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

    0
  40. 1990

    the best article ever!!

    0
  41. 2041

    It’s “Hire” not “Higher”

    0
  42. 2092

    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
  43. 2143

    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
  44. 2194

    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