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

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

Two Cats In A Sack: Designer-Developer Discord

The differences between designers and developers often erupt in pointed jabs on the Web or at conferences. Jokes or not, the jabs create friction whose consequences are real.

I am a designer, and by no elaborate means of job-title-rejigging do I consider myself a developer, but I see the cruelty of designer and developer egos going both ways. So, what happens if someone throws a pair into a sack to hash it out? How do we emerge? Our projects, careers and maturing industry rely on our ability to learn to work together instead of against each other, and looking at what we have in common is one way to begin addressing interdisciplinary cat fights.


Shared Priorities Link

A belief that design and development have competing interests is an obstacle to successful collaboration. There are, of course, developers who design and designers who code (I’ll return to this point later on), but the tension referred to here is between the designer and developer who believe that their respective discipline is more important. Conquering this belief is crucial to avoiding a clogged workflow, low team morale and, ultimately, limited project success.

Design is not completely an aesthetic concern, nor is development an entirely technical one; designers must consider how functionality affects form, and developers must be creative in building out functionality. Similarly, if we look closely at design and development, we find that principles of good design are often similar in good development. Focusing on these overarching ideas reveals a large pool of reciprocal interests.

Harmony of Parts Link

Paul Rand, a designer’s designer, creator of the IBM, ABC and UPS logos, wrote in A Designer’s Art:

Copy, art, and typography should be seen as a living entity; each element integrally related, in harmony with the whole, and essential to the execution of an idea.

He wrote this in 1985. Today, the principles remain mostly the same, but one component is sorely missing from Rand’s statement: technology. Copy, art, typography — and technology — are the bones of a project, where design and development are the joints and skin that connect and hold together the parts. When all of these elements fit together well, you essentially have design and development working together as the support structure for the user experience and overarching concept, the so-called “living entity.”

While far too simplistic a metaphor to cast a strong light on the process (building a website in fact looks much messier), Harmony of Parts does illustrate how design and development should ultimately work towards the same goal.


It is also worth mentioning that development, like design, encourages the harmony of parts in programming concepts like polymorphism and encapsulation. These ideas quite broadly mean that pieces of functionality should work well when placed inside or beside other pieces, another way of saying, “each element integrally related, in harmony with the whole.”

Teachability Link

Both design and programming are teachable, and where there are talented individuals there is also hard work, discipline, teachers, mentors, standards, taste, ruthless editing and constructive criticism, all of which are cultivated. There is bad work and breathtaking work. There is the scrap heap, the slush pile, the useless code: all evidence of learning.

This commonality between disciplines is important because it presents an opportunity: designers can learn about development, and developers can learn about design. The democratization of resources in this information age (which some would argue we’ve already passed23) means that we have little excuse not to obtain, or teach, at least a basic understanding of each other’s crafts. Not doing so will work to the detriment of the team. And when there are gaps in knowledge, rather than reprimanding, we should encourage an open dialogue to protect our most valuable learning tool: the ability to ask questions.

Elegance and Efficiency Link

Chris Coyier, self-described Web craftsman, blogger, author and speaker, writes in “What Beautiful HTML Code Looks Like4”:

Code? Beautiful? Sure. After all, code is poetry. This is just HTML, so it can’t be quite as intricate and elegant as a dynamic language, but it still bears the brush strokes of its creator.

What is elegance? It could mean restrained beauty and grace, as in art and fashion. But in design as well as math and science, something elegant typically embodies simplicity and effectiveness, sometimes solving two or more problems at once or by an unexpected insight. Elegance, then, refers to underlying content or an underlying process.

Design may rely on aesthetics for its medium, and development may rely on code, but both draw on theories of efficiency (perhaps a synonym for elegance) to create effective output: elegant code is efficient code, and elegant design is efficient design. This means that design and development share some core values of process.

Shipping Link

In his article “Design Is Not the Goal,” Francisco Inchauste writes:

The end product (website or application) should always be the focus.

Inchauste goes on to say that too often, process insists on polishing irrelevant deliverables; for example, over-updating wireframes instead of moving on to the build and user testing. The true deliverable is the final product that we launch and that people interact with. Jeff Gothelf goes more in depth in his article “Lean UX and getting out of the deliverables business5.”

In a healthy team environment, we designers, developers, copywriters, user experience designers and project managers are all shippers. Bigger agencies tend to lump design and development teams into the Production Department, for better or worse, and this is telling. It demonstrates that both “creative” and “technical” professionals share a predominant interest: they must ship.

Correcting The Workflow Link

It may be that designers and developers are perfectly capable of collaborating effectively, and that management and process are the biggest hurdles or frustrations within a team.

Good Ideas Intersect Link

The logistics of securing work often mean that the earlier a great idea is identified for the project, the happier and more secure the client will be, resulting in a better working environment for everyone. However, it also means that stakeholders will come together early in the process to come up with ideas. This can occur to the preclusion of the very people who will produce the final work, especially in hierarchical agencies. This undermines the designer or developer’s ownership and discourages self-direction and personal investment in the project.

One solution to this problem is to ensure that great ideas are universally respected, wherever their origin. Michael Lebowitz of Big Spaceship famously preaches an agile workflow, saying in a New York Times interview6:

We also invite people from all of our disciplines into all of our brainstorms. Great ideas come from everywhere.

A policy like this opens communication channels in a team framework and dispels departmental inequalities. When something goes wrong, finger-pointing is no longer an option if everyone’s had an opportunity to provide input, and collaborators are forced to learn from mistakes. This is not to say that responsibility is evenly distributed, but allowing teammates and workspaces to intersect in unexpected ways will allow great ideas to surface.


Waterfall vs. Agile Thinking Link

In waterfall-structured processes8, where development is held up by unfinished designs, developers are the ones who end up staying late to finish the project on time. Not only is this unfair to developers, it is complicated, because pointing the finger at designers for taking too long is too easy an answer. Responses to a design can be so subjective and cryptic (“I don’t know why I don’t like purple, I just don’t”); true insights require time to unearth and can result in unpredictable delays in the process.

Hold-ups are best avoided not by keeping design and development separate but by bringing them closer together via an iterative workflow. This agile methodology9 distributes responsibility and assigns value to each team member. Furthermore, departments are not tied to an inflexible plan. All of these attributes of agile thinking help to alleviate designer-developer tension.

Giving Credit Link

In the fable “The Lion, the Bear and the Fox,” a lion and bear fight over prey until they can fight no more and fall over exhausted. Meanwhile, a fox who has been watching the fight sneaks up and steals away with the prize. The moral is this:

Saepe alter alterius fruitur labribus.
From the labors of others, it is often another who profits.

Giving credit where credit is due and sharing the rewards is better, but unfortunately, in a fast-paced digital environment, whoever is left sitting at the table is often the one who gets the final praise. It is up to that last team member (the project or account manager, art director or tech lead) to pass feedback onto the rest of the team in a meaningful context. The cost is minimal (however long it takes to shoot an email or walk to someone’s desk), but the shared joy (or misery) will bond design and development teams because they will see the end product as the force that unites them.

Work Habits: Playing Nice Link

Sometimes playing nice is as simple as extending a courteous email; other times it is as complex as learning a new skill set. There are many concrete ways, big and small, for designers and developers to become more compatible colleagues. Let’s first look at efforts that can be shared, then at tasks more specific to designers and to developers.


Both Designers and Developers Link

Despite being in separate disciplines, our greatest commonality is that we are human. So, many of these shared tasks demonstrate how to play nice with anyone:

  • Keep an eye on the big picture.
    Pre-established goals that are developed by the whole team should inform decisions (and compromises) throughout the process.
  • Cast a wide net for inspiration.
    Look to a variety of sources for a well-rounded understanding of the topic. Discriminate material by quality, not subject matter.
  • Check in early and often.
    Avoid making too many decisions in isolation.
  • Be nice.
    If you must criticize, make it constructive. Being kind11 often reaches far beyond office walls.
  • Teach each other.
    In their book Rework, Jason Fried and David Heinemeier Hansson preach transparency between companies and their customers: “Letting people behind the curtain changes your relationship with them. They’ll feel a bond with you and see you as human beings instead of a faceless company. They’ll see the sweat and effort that goes into what you sell. They’ll develop a deeper level of understanding and appreciation for what you do.” This works for designers and developers, too. Revealing the inner process means teaching, and teaching is a way to invest in a relationship and build mutual respect.

Designers Link

There are innumerable great tips to help designers become better colleagues. Here are some of my favorites:

  • Explain the design rationale.
    Design isn’t magic, and making an effort to analyze and share design decisions will create a conversation and demonstrate to colleagues that their insights are valued.
  • Practice PSD etiquette.
    Adopt the Photoshop Etiquette Manifesto for Web Designers12.
  • Design thoroughly.
    Think through the interactivity of the product, which includes designing the on, off and current states, designing error messages for forms, designing 404 pages, etc. This will save your teammates valuable time.
  • Be considerate.
    Avoid making others wait on you. Be proactive and organized, and ask for feedback often.
  • Enlist a developer.
    If the technical implications of the project are unclear, grab a developer to go through it with you. They’ll likely appreciate being involved.
  • Learn about development.
    Knowing even a little about code will make you a better designer.

Developers Link

Here are a few ways for developers to improve their work habits:

  • Make yourself available.
    Being a part of the process from concept to realization will translate into a sense of ownership of the project. Ask colleagues what they’re working on. Make your expertise available as a resource.
  • Simplify the explanation.
    If you can help team members from all levels and backgrounds understand high-level concepts and how they affect a project, you will become more valuable.
  • Develop the design details.
    Much of a designer’s craft lies in the details; if they are forgotten or changed, the designer’s time and effort will be wasted.
  • Be honest about what can’t be done and why.
    Big ideas often struggle against time and budget constraints; that’s nothing new. Knowing the development constraints ahead of time allows the team to create more appropriate solutions.
  • Learn about design.
    Theories, rules and standards play important roles in aesthetic and usability decisions. A little knowledge of these concepts will help you better navigate designs.

Some of the tips for designers will certainly also be useful for developers, and vice versa. Being able to work well on a team often depends on the individual’s personality, so take those habits from either group that will contribute to better collaboration. Do you have other good ideas? Share them with us in the comments.

The Hybrid’s Role Link

Designers and developers come in many shapes, and design and development skill sets are overlapping more and more. Hybrids, who have one foot in each discipline, seem to be increasingly sought after by clients and employers. This begs the question of whether we need to get along better or simply become more like each other.

Hybrids are in a unique position to answer this question. If you consider yourself both a designer and developer, tell us: What is it that you find easier or harder about being involved in both disciplines? What do you like or dislike about it? What can we all do to become better collaborators?

Post-Disciplinary Collaboration Link

Way back in 1999, Andrew Sayer, professor of sociology at Lancaster University, published an article titled “Long Live Postdisciplinary Studies! Sociology and the curse of disciplinaryparochialism/imperialism.” Despite the hefty title, he wrote quite simply:

Interdisciplinary studies are not enough, for at worst they provide a space in which members of different disciplines can bring their points of view together in order to compete […] Post-disciplinary studies emerge when scholars forget about disciplines and whether ideas can be identified with any particular one; they identify with learning rather than with disciplines.

Competition is fierce in our industry, and as talented new generations join the workforce, it will only become fiercer. Web makers will need to work harder and more efficiently to retain that quality that clients and consumers value: the ability to surprise. For this, we need innovation, but designer-developer cat fights take up precious time that could be put to innovation. If we instead incorporate post-disciplinary collaboration into our process (a fancy way of saying, “Let’s forget about job titles for a moment and work toward something together”), I believe we’ll be more successful and find our jobs more enjoyable.

(al) (il)

Footnotes Link

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

↑ Back to top Tweet itShare on Facebook


Cassie McDaniel is the lead UX designer (or whatever) for the Mozilla Webmaker project. Say hi to @cassiemc on Twitter or check out for design and more words.

  1. 1

    I’m a hybrid. I could never say, “I’m better than a Web designer or developer”. I just try to share my knowledge like any hybrid, and try very hard to learn about design and development at the same time,… Do u happen to have 2 ways? for both? I see only one.

  2. 2

    Interesting read. Communication and just a bit of empathy seem key. Seeing as I am a developer and most definitely not a designer, what you do recommend for “Learn about design”?

    Any books or other resources?

  3. 7

    Why not do both? :D

    • 8

      because then you’re doomed to do one or the other rather poorly :)))

  4. 9

    This was a great article and a refreshing read. I consider myself both a designer and developer although I’d say my primary strengths lay in the design side. Having development knowledge has helped me to think about implementation while designing, but I also feel that in some cases has possibly hindered my design approach knowing that some ideas are just not feasible given my development skill set. I also think that being both a developer and designer has possibly “held me back”, in the sense that I’m forced to be good at both, but unable to be great at either discipline. I’ve often wondered if I should stop trying to be both and just focus on one side of the coin. Anybody have a quarter I can borrow? ;-)

    • 10

      Cassie McDaniel

      May 13, 2011 12:13 pm

      Nick, that is indeed one of the drawbacks of being a hybrid. Unfortunately there’s no easy answer. This article is about building a more collaborative team, but I do think there is room for all kinds of skill sets. How we define ourselves often says more about the necessities of our job roles, and I’m sure your knowledge of both will come in handy, but you should definitely do what works for your goals.

  5. 11

    First and foremost, this was a solid article and something we generally dodge in the web community.

    @Nick brings up a good point, in that some of us “hybrids” could potentially be better at designing/developing if that’s all we focussed on. I feel passionate about the topic because of how good or bad it can really get between designers and developers. It works best when both parties understand their roles well but are willing to be taught, as noted in the article. Two things you can’t learn easily… humility and teachability.

    Good environments and conditions between designers and developers will only breed better work, in my opinion.

    • 12

      Cassie McDaniel

      May 13, 2011 12:14 pm

      Thanks Dan. You’re spot on.

    • 13

      While I agree that there’s a “jack of all” tendency for us hybrids, there are other factors. First, because we know the technology, there are ways we can include details that another designer may not have known was possible. On the flip side, I find that I sometimes limit my designs because I know something will be impossible or at the least, difficult. As with so many things, it’s a double edged sword.

      • 14

        Richard Williams

        May 16, 2011 6:14 am

        I’m happy to be able to say that I’m definitely a hybrid.

        Personally I think it’s an advantage to know exactly how everything is going to work together.

        I do a lot of work on my own and I love not having to rely or wait for anybody else.

        I see where Nick is coming from when saying you might be able to be better if you were to focus on one discipline, but I like the change of being able to go back to photoshop and playing with layout after a week of solid coding (or vice versa). Definitely a help when you find yourself suffering from designers/coders ‘block’. I don’t think I’d be able to get as much done if I was forced to do one thing only, and I enjoy both sides of my work.

  6. 15

    Im primarily a designer and quite efficient at that but I did learn javascript, html, css and some flash but I dropped using these skills actively. Why? Because both disciplines are too wide and extensive, you can write average code coupled with average-moderately good design but probably it does not come as a surprise that if you split yourself you lose efficiency in both. However I do believe that in most cases it is possible to do both (most of the webdesign is not cutting edge and does not require top end code nor design and medium to good is good enough).

    What I have done is getting myself a programmer to work in sync with. By now we have been working together for 3 years day-in & out. I have learned alot about coding and coders mentality which has propelled my competency into new heights because now I can direct developers properly and not cause problems and keep both bosses and programmers happy cause I can relate to both.

    I guess my point is, get form partnerships and strong teams – its good to know how to code but from work efficiency point I think its better to have a real good coder who can do whatever you want using fraction of the time you would and he can take your designs and blast away real quick not having to struggle with photoshop skills etc.
    Most importantly respect eachothers talents and include eachother into the “Design” process discussing flows and usability – sure there is stuff you can do alone (drawing details) but flows and usability is something that I find is done best when both are involved since both have their unique input…..


  7. 16

    Hi Cassie:
    very thoughtful article – if only more developers would appreciate good design… Perhaps the UX guys should be included in the mix.
    N.B did you work @ Mindblossom, Toronto?

    • 17

      Cassie McDaniel

      May 13, 2011 2:35 pm

      Mide! I did work at Mindblossom, where are you at now? I included UX peeps in the article where I could, but much of the tension seems explicitly between designers and developers. UX designers seem to be standing on a safer middle-ground.

      • 18

        Cool… nice to stumble upon you online
        I’m still working in the GTA… doing front end work but surrounded by hard core developers!! it’s tough, they’re trying to turn me into a developer as well

  8. 19

    I am primarily a designer, but I have solid understanding of HTML and CSS. This understanding really helps me in creating things that ARE possible. If I’m unsure, I go talk to the developers first. BEFORE, I talk to the client, much less show the client anything.

    When it comes to creating something that is more interactive, our project manager works out the details of how it’s suppose to work with the client and developers. Then taking that spec, I design the interface. I when I want to change something, because from a design/usability perspective I think works better, I go discuss it with the developers.

    Our team works really well this way. I think having a solid understanding of what’s possible is key. Not necessarily, being able to implement it, but an understanding.

  9. 20

    Anon Ancestor

    May 13, 2011 1:57 pm

    Your proposed dualistic view is rather naive.

    A designer would actually be the person who understand what, why and how. Developer just knows how to build it.

    Now you propose that designer just paints it up. Thats not how things work at all most of the time, imo. Unless you use some subcultural definition of designer, which would imply your opinion is fringe, iow irrelevant.

    So, this article ends up being “kind of wierd”.

    • 21

      Cassie McDaniel

      May 13, 2011 2:31 pm

      I’m not at all proposing a designer just ‘paints it up’ nor am I suggesting that developers ‘just know how to build it.’ The idea is that when both designers and developers are involved in the process from start to finish you end up with a better product and a happier team.

    • 22

      @Anon Ancestor:I think you’ve missed the point…
      It’s absolutely vital that deigners have a basic understanding of what a developer does and that the developer has an understanding of a) the general principles of graphic design, and b) the rationale behind some of the design decisions made on a particular project.

      I guess you’re a designer… as a hybrid with a very slight tilt towards the technical, I work with a lot of designers. The best ones all have a basic understanding of how and what I do for them on a technical level. Not that they can do my job, but they are able to appreciate what I talk about. The flip side of this is that they also know that I understand design, and that if I make a suggestion, it will have beenthought through from both perspectives.

      I would be very suprised if i was the only person in the world like that :oP

      In truth, and I think it’s what this article is about, we should all be hybrids, to varying degrees. How much is each individual’s choice, but hybrids we all should be :o)

      It’s all about the ‘C word’…


      And what a great diverse world we live in.

      Oh, finally, Cassie, thanks for a great article.

  10. 23

    hi, I’m a designer by education, but switched to fiddling with the webs in 1997. I have a solid understanding in html/css, js, ajax, jquery, can code in php build templates with smarty and make things work with mysql. To answer your question, I find it very exciting to create, to bring my ideas to life – not limited to the “look”, and not depend on someone else to craft the thing. It helps to have a understanding of the mechanics, logics and tools needed – but I find that it can limit the creative process. I often think that designers without the knowledge of the underlying technologies may come up with truly surprising designs, not limited by the constant nagging in the back of their head regarding the possible implications for the development process. On the other hand, I will never be able to think solely in terms of logics and classes, ignorant to the representation. I love building the web, but sometimes keeping up with all the disciplines and honing the skills needed is a hellofajob, and as Nick says above, maybe the time is better spent concentrating in one thing, getting expertise there. But I love knowing and doing all this stuff. :-) – Tom

    • 24

      Exactly my thoughts, Webrocker. Sometimes I wish I could shrug off the knowledge or thoughts of what’s “possible.”

  11. 25

    As a hybrid, most of the challenge seems to come to me in the form of design. Sometimes, it’s easy to get caught up on small details and things that will work / will not work when it’s time for development. This can leave a hybrid spinning their wheels quite a bit. In my opinion, it’s beneficial to design fast and at a high level in the beginning. This may create a bunch of holes and inconsistencies, but these can be patched up before presenting to the client and before you begin development. This 2-pass process allows hybrids to get ideas out quickly, but polish everything up for development.

    It can be challenging to flip between a designer brain / developer brain but I think it’s better to know both in the long run, especially with the way things seem to be going.

  12. 26

    Well, this is exactly what’s going on where I work. Neither one can see the other one’s point of view. I guess for better or worse I’m the ‘hybrid’. And, I gladly take on the gruff.

    I’m not a php programmer but I use php and can write simple apps and trouble shoot. I’m not a javascript programmer but use javascript everyday and can usually write functionally or find clean code for what I’m trying to accomplish. Nor am I a Unix sys admin, but I interact with a command line everyday as well, (especially with sub version control software; in particular ‘Git’.) I use Photoshop, some Flash and I love to play with Illustrator, but am certainly no graphic artist. I’ve seen programmers and sys admins whip through the command line and editors flinging code and scripts like a short order cook flings hash. I see how incredible they’re skill sets are. I’ve seen our graphic artist do the same with Photoshop creating beautiful designs and mocking up cleaver and useful UX.

    Most of the time I feel like I should know more on both ends. Motivating? Yes. Learning in leaps and bounds? Yes. But, I can end up driving myself into the ground with unrealistic expectations. Glad to hear the idea of ‘Hybrid’. Heck if I can think of those designs or fluently write dynamic languages like I’m writing this response. But, if you give me the .psd I can put it into html, style it with css, add js and hook up the back end functionality sometimes writing code or editing the .psd to make it work.

    Great article. Glad to know we’re not the only ones dealing with this issue.

  13. 27

    Aaron Martone

    May 14, 2011 7:07 am

    Proud to be a hybrid. But it’s important to note that it’s even more rare for a hybrid to be as knowledgeable in each field (design and development) than a person dedicated to either would be.

    I’m 60/40 Designer/Developer and I’ve worked with people who are 85/15 Developers. It’s true that there are significantly different priorities between the two, but there’s no reason we can’t work together. We just need to see eye to eye.

    Of course, people love Hybrids because you pay 1 salary and get someone knowledgeable in both fields (for the sake of being cheap) but you’ll always get what you pay for. A hardcore designer/developer vs. a hybrid will best a hybrid in their respective field, but then have no experience in the other field that the hybrid can claim responsibility in.

    Designer, Developer or Hybrid; we all have a common enemy: Internet Explorer.

  14. 28

    I consider myself a hybrid, however as soon as I have to delve into learning new, in-depth programming I get a intense form of A.D.D. and can find anything else to do.

    I am fluent in HTML/CSS but from the little “more intense” programming I have learnt I’ve found that I can talk with developers more freely of what solutions I want to achieve through my designs. And my Designs have improved to work better with Developers and what they are trying to achieve in a project.

    My dream is to become a teacher in Interactive Media Design and the first thing I will tell my students is to learn hoe to code, because I truly believe it improves interactive design in a whole way.

  15. 29

    Martin LeBlanc

    May 14, 2011 12:41 am

    I believe design is more than the skin. It’s also the number of “legs” and “arms”, as well as what the software has to do.

    • 30

      Cassie McDaniel

      May 14, 2011 6:46 am

      I’m glad you’re questioning that. Determining the shape of the body is a good idea, but many people together make that decision, not just the designer. And design isn’t ‘merely’ skin – skin is a body’s largest organ and a person can’t live without it. It is deceivingly complex; it constantly rejuvenates itself, regulates a body’s temperature, and allows us to touch and interact with the world, all the while staying pliable, impervious to disease, and sometimes is the cause of a disease. Despite all this, people often see the role of skin (or design) as very simple. So while I agree – design isn’t always surface – the skin metaphor works because it infers hidden functionality along with the bits we see.

      • 31

        Martin LeBlanc

        May 21, 2011 3:35 am

        I believe design should be Design as in “Purpose, planning, or intention that exists or is thought to exist behind an action, fact, or material object”

        So I believe design should be how the whole body is put together – not just one layer.

        • 32

          The problem is that people think in development as “building”. Coding is a design process! Graphic design is a part of the design, developer are designing too.

  16. 33

    Shannon Mølhave

    May 14, 2011 6:41 am

    I enjoyed this article and think it has some great tips for creating more of a harmonious work environment among designers and devs. Being a “hybrid” I think it really helps to understand the thought process of developers. Algorithmic thinking is used in front- and back-end development, and while I don’t know how to write PHP, I can understand when discussing a design with our developer how certain elements can affect the coding process.

    This leads to my advice for design/dev teams (which you touched on discouraging a waterfall workflow): get the developer involved throughout the design process. Having a designer explain how they envision a PSD storyboard will work to the developer can bring to light certain parts of the design that either won’t work the way you thought or can be improved upon knowing more about the back-end setup. This can save a lot of time and frustration on both ends as well as help both parties understand where the other is coming from.

  17. 34

    Great article, but just one thing, if you cant code, you are not a web designer, and thats it. Graphic Designers should always be involved in web design team, always, but they cant take on the web designer role, its like a developer saying he/she is a graphic designer because he/she downloaded a template.

    Graphic designers have a much wider understanding about message, color theory, hierarchys, presence, and so on, so they should be a part of the team, but the job title should be graphic designer, not web designer.

    But anyways, as always, smashing magaziens articles are top notch!!!

    • 35

      Cassie McDaniel

      May 14, 2011 5:01 pm

      You’ve brought up a good distinction Ricardo, but I’d clarify and say web designers need to know about code, not necessarily how to do it themselves. Obviously there are many differing opinions about this, but in my experience the need for designers to code is not always implicit, especially in large teams.

      • 36

        Ricardo is right. In my experience a designer who can’t code is essentially a print designer. Why? because if you can code, even to some degree, you respect the medium and understand it’s limitations and that is reflected in your design work.

        I can pick off a web design concept done by a non-coding designer a country mile away. There is always at least one Pollyanna element to it that looks nice but won’t work in the real world. The other tell-tale sign is arbitrary complexity. Even though things have gotten better over the years with the newer browsers, any true web designer will have spent time in the trenches fighting browser inconsistencies and will avoid going back into battle for the sake of some overly complex, but ultimately inconsequential design element.

        Absolutely no offence to any non-coding designers, but you have to eat your own dog food – even if it’s just once in a while. You will be better off for it and you might even get a raise!

        • 37

          Cassie McDaniel

          May 15, 2011 7:00 am

          I don’t agree that a designer must know how to code in order to respect and understand code’s limitations, but I’m 100% in agreement that designers should know about code, which is truly the least we can do. There are occasions, as Nick mentioned above, where focusing on limitations tends to produce the same ideas over and over again. In reality the skill set depends on the team’s values and end goals.

          • 38

            Regarding the role of “The Hybrid”… I wouldn’t word it as strongly as Ricardo does, but I definitely agree with what he’s saying. There’s no good reason for a designer not to pick up the basics of HTML and CSS, or for a developer not to read “Don’t Make Me Think” or other ui/ux books — both could be hammered out in a day or two of reading and experimenting.

            In my short career (4-5 years), I’ve seen only two big designer/developer clashes, and in my view, both were caused by people that refused to pick up additional skills that would have helped them to better understand each other.

            I now work at a web startup called where nearly every member of the 12-person development has crossover skills: design/front-end, front-end/back-end, back-end/systems. And all members of the team, regardless of discipline, are encouraged to voice their opinions about everything from business decisions to issues of company culture. Conflicts between team members are practically non-existent because each person knows a fair amount about what their teammates do, and how their work will affect each other. Arguments still happen, of course — but everyone gets their say and logic prevails more often than not.

            37signal is another often-cited success story of what can happen when you hire (or mold) cross-discipline people.

          • 39

            Cassie McDaniel

            May 15, 2011 11:00 am

            Travis, the issue seems somewhat a problem of semantics – a day’s effort would produce a fairly shallow skill set, which is close to what I mean when I say to know “about” each others’ disciplines. Regardless, it is only one root of the problem, and the hybrid’s role as you mention is certainly changing the game.

  18. 40

    Any coder worth his salt knows how to handle dynamically loadable content without it exploding his code. The only exception is when design, UI, business logic, and user experience are intermingled with no separation, put under a sniper scope deadline while the project zealously oversold to the client, and managed by yes-man grunts who hover over you, doing the equivalent of pressing F5 every three seconds asking for a status update like each coder was their own Twitter server.

    When you hand over your car to be fixed, do you call the mechanic every thirty minutes and make change requests? No? Do you know why you don’t do this? Because the mechanic would gut your pocketbook with glee in his heart.

    You can always have placeholder art and change it later.

    Good luck changing placeholder code later. Hope you like wasting lots of money.

  19. 41

    Also, there is no such thing as a “really good coder.” Dispel with that myth entirely. Coding “really good” is not a critique that can be made by non-coders. Really good code is modular, compartmentalized, atomic, efficient, well-organized, and scalable.

    If you don’t even know what those principles mean when applying them to the field of computer programming, then you’re analysis of what a “really good” coder means is no different than saying you know a “really good” astronaut. How the fuck would you know?

    Good code is a discipline, not a magical property that manifests as a result of a personality trait. Really good code is a group discipline that requires perpetual maintenance and communication.

    • 42

      Aaron Martone

      May 15, 2011 9:02 am


      The things I’ve learned about coding from my coworkers shows that the greatest code is that which is clean, optimized, modular and upkeeps itself; and it always puts a smile on my face when you see that clean code running nice and smoothly.

  20. 43

    JC Transfiguracion

    May 15, 2011 6:15 pm

    Great article! I’m a hybrid that takes most of the design duties of my team. I work with a team of 4 who are mostly developers. By education I’m actually 50/50 on design and development but I’ve found that I struggle more with design. Probably my cue to brush up on that a bit more.

    Working with someone who is purely a developer (and a very good ornery one at that), I’ve found that it’s not that they DON’T appreciate aesthetically pleasing things. It’s more of if it means more work for them you better have good reasons for it. As the person dealing with UX as well that has actually pushed me to do even better since I wouldn’t want to waste my team mate’s effort and time.

    A good healthy environment actually goes a long way into putting ideas into reality.


↑ Back to top