Menu Search
Jump to the content X X
SmashingConf London Avatar

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. our upcoming SmashingConf London, dedicated to all things web performance.

Why You Should Include Your Developer In The Design Process

Should designers be able to code? This topic never seems to die, with its endless blog posts, Twitter discussions and conference talks. But the developer’s involvement in the design process seems to be addressed very little. This is a shame, because developers have a huge amount to add to discussions about design.

Developer Design Process

The unfortunate truth is that many designers have a somewhat elitist attitude towards design. They believe that only they can come up with good design ideas. That is simply not true.

Everybody has the ability to make good design suggestions, including developers1. Admittedly, a trained designer will probably be more effective at finding design solutions. But that does not mean others should not contribute. As designers, we need to swallow our pride and accept contributions from everybody. For that reason alone, we should include developers in the conversation.

Further Reading on SmashingMag: Link

The Dangers Of Not Including The Developer Link

Back in the heyday of Digg, I remember a conversation between Daniel Burka (Digg’s lead designer) and Joe Stump (its lead developer). They told a story of a design change to the Digg button that Daniel wanted to introduce. From Daniel’s perspective, the change was minor. But upon speaking with Joe, he discovered that this minor design change would have a huge impact on website performance, forcing Digg to upgrade its processing power and server architecture.

This is the problem when developers are not involved in design. It can be disastrous. It can lead to designs that are impossible to build, designs that introduce unnecessary technical complications, endless back and forth between the designer and developer as they struggle to fix problems created by the designer, wasted days of revision and iteration — all because the developer wasn’t consulted.

Consider also the client’s perception of this mess. The client has signed off on the design, only to be told later that it cannot be built. That reflects poorly on everyone. This is why we need the developer’s involvement in design decisions. The decisions we make as designers have far greater ramifications than we are aware of.

By including the developer in these decisions, we avoid wasted hours of work on something that is not cost-effective to build.6
By including the developer in these decisions, we avoid wasted hours of work on something that is not cost-effective to build. (Image credit7)

The Developer Can Improve Our Understanding Of What Is Possible Link

But we need developers not only to block infeasible ideas. They might also suggest ideas that we’ve dismissed as impossible. We sometimes filter our own ideas because of the limitations of our technical knowledge, especially if we do some coding ourselves. We figure that if we cannot think of how to build an idea, then it cannot be possible.

Sure, developers will sometimes resist our ideas. But other times they will build on them and take them further than we ever thought they could go. I have been in discussions with developers who proposed things I didn’t even know were possible. Without having them in the room, I would have missed out on those insights.

What’s more, I learned through the process. By working closely with developers, my understanding of development has increased. I remain a specialist in design, but my knowledge of development has increased, making me more of a generalist. And, as I have written before, being a generalist is no bad thing8.

Developers Make Design Decisions All The Time Link

The biggest reason, though, for involving developers is that they will end up making design decisions anyway. The truth is that, as a developer delves into building a project, they will have to make decisions that affect and refine the design. Designers rarely have the time to consider all nuances of a website. The rest fall to the developer.

By involving the developer in the initial design discussions, they will be in a better position to fill in the blanks. And when compromises in the design must be made, they will be in a better position to make those calls.

The Developer Will Have A Greater Sense Of Ownership Link

There is one final reason for including the developer in the process: They will feel more engaged with the project. Too often, developers are at the end of a long chain of decision-making. Their voice isn’t heard because they’re brought into the process far too late. This leaves them feeling no ownership over the project. By bringing them in earlier, they will feel more connected to the work and more appreciated, too.

The question, then, is how do you include the developer in the process?

So, What Are You Waiting For? Link

Involving a developer in the design process is not rocket science. It comes down to inviting them to any design sessions that take place.

Get them involved in the design exercises you do with clients. Encourage them to sit in on at least some of your usability testing sessions, and involve them right from the beginning of the project. The earlier you do it, the more you will benefit. In particular, show them your design work early on, before the client sees it. Too often, a client will sign off on a design and then the developer will discover that it cannot be built! That puts you in the embarrassing position of having to backtrack with the client.

Of course, the more meetings the developer attends, the less coding they will get done. We must find a balance. A few meetings are worth it if delays are avoided down the line.

There is another thing you can do that won’t eat into the developer’s time. Put the designer’s and developer’s desks side by side. My agency’s designers and developers sit beside each other and are always commenting on each other’s work. When a developer is able to look over at the designer’s screen, you can be sure they will speak up if they don’t like what they see!

In the end, this is all about breaking down the barriers between roles and encouraging more collaborative work, not just between designer and developer but between workers in all disciplines. The more we understand what our colleagues do and the less precious we are about our own discipline, the better the result will be.

Excluding the developer from the design process will do nothing but prevent the project from living up to its potential. In fact, excluding anyone — whether copywriter or SEO specialist — will ultimately compromise our work.


(al, il)

Footnotes Link

  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
  8. 8

↑ Back to top Tweet itShare on Facebook

Paul Boag is the author of The User Experience Revolution and a leader in digital strategy with over 20 years experience. Through consultancy, speaking, writing, training and mentoring he passionately promotes digital best practice.

  1. 1

    A really interesting article. I’m lucky enough to work in a company where I am consulted not only by my designer colleagues but by project managers as well.

    When I, as the developer can offer my input that functionality will be affected when a design concept is proposed, a lot of the time results in a better, more clear and concise design.

    You’re definitely right that it gives you a greater sense of ownership and you feel a lot less like a coding drone. It also helps me to improve my design skills.

  2. 2

    As a developer, doing this in the agency I work for, I totally agree!

  3. 4

    Martin Spierings

    November 21, 2014 2:43 pm

    Interesting article. I think both the designer needs the developer but the developer also needs the designer.

    One thing that might be worth mentioning is that developers should be considered for some things in the design, but should not always have the last say. Sometimes developers believe something isn’t going to work or is too difficult (or too time consuming). They might learn a thing or too by trying. You shouldn’t limit your designs for whatever the developer says as you will then limit innovation. A possible solution is to tell something of which the developer might say it is too difficult. But than have him investigate it and continue on some other parts of the design until he has an answer. Talk to the more experienced developers in your company to see if they might now a solution. And so on.
    If you are working agile you might go with the easy solution first and have the more difficult (but better by usabilty standards for example) component in a later stage so if you have some time to burn, you could look into it.

    Lots of these issues can be avoided by doing more research in the platform capabilities and ask your developers for some examples of what they’ve made so you have an idea of what they are capable of and how much time things could take.

    • 5

      What is important is if the developer suggests something will be very difficult or time consuming then it probably will be (at least with the resources available to you currently).

      To an extent no developer should ever say “it cant be done” because with enough resource practically any design decision is possible, they should be able to provide insight into the costs to allow appropriate cost benefit analysis to be applied.

      Design requires compromises in order to be within an appropriate budget for it to be realised.

      • 6

        “To an extent no developer should ever say “it cant be done” because with enough resource practically any design decision is possible, they should be able to provide insight into the costs to allow appropriate cost benefit analysis to be applied.”

        I don’t necessarily agree that this is every developers job, yet rather someone who is higher in the ranks, such as a lead or a technical manager. The developer should be able to provide someone more senior with information that could lead them to conduct their own research, so that the developer could stay focused on development/coding.

        I agree that a developer *must not* end a discussion with “it can’t be done”, yet rather explain why then propose alternative solutions. If a developer ends the discussion with the former, they’re more than likely being lazy or uncooperative. However, if they end with the latter, this is a good sign of maturity, knowledge, and experience… a team player that every company should have.

      • 7

        You are technically correct in that anything can be done, but oftentimes if a developer has insight into the bidding/pricing, it is good shorthand. If a developer says “it can’t be done”, what he or she means is “it will be more expensive in time and money than it is worth.” The dev is just trying to save you hassle and keep you within budget. Trust me, I’ve been there.

    • 8

      If a developer doesn’t have final say in things that simply shouldn’t be done at all, you end up with nightmare projects like mine.

      All scrolling replaced with transitions.

      The client and designer saw a promotional page that heavily utilized CSS 3D transitions for flashy looks and insisted that’s what we are going for. The single promo page had over 10K lines of custom JavaScript to pull it off and all the content was clearly fitted to it by the developers, as a one completely isolated and static page.

      Imagine how that works in a large site built on a content management system, where the client needs to add pages with various templates and products without developer aid. Where text is formatted with a WYISWYG editor, where localisations and photo material comes from a third party and where in addition to mobile devices you support IE8.

      It’s been over a year, the user experience is absolutely terrible and the client needs to jump through some ridiculous hurdles while adding content. They’ve sort of stopped caring when it looks like garbage and so have I. Next time a designer insists on getting rid of native scrolling, either they can listen or I’ll just quit.

      If you don’t understand the technical implications of your design, or even if you think you do, you listen to the guy who is putting it together. It’s not always a matter of challenge and something for the developer to figure out, it could be just a completely unrealistic and broken idea.

  4. 9

    That’s fantastic! Thank you for sharing your post!

  5. 10

    I used to work in UX a few months ago and it was always the best choice to talk and ask questions to developers. They always had a different point of view of something I was not even seeing well.

  6. 11

    As a developer, I cannot agree more wholeheartedly!

  7. 12

    This is an amazing article and something I think a lot of people can work towards better! I’ve noticed a huge shift in how we approach design after working more closely with the designers. You would think about first that doing this would place tighter constraints on design but it is absolutely quite the opposite.

    The biggest impact is also the reduction in time that it takes to build a working product because the designers are also thinking about how the “building blocks” will come together which makes the developers life a lot easier, which leads to more time refining the design and providing a better UX for everyone.

  8. 13

    Since RWD is a thing a lot of people (designers and developers alike) are talking about the integration of the designer/developer early on in the project… yet, often it is not the developers or designers that refrain from working with one another as soon as possible.

    A lot of times it’s the agencies, companies or clients, who separate those departments way too strictly because the keep on doing “their thing” (first design, then code, then filling boxes with precious contents).

    Thanks Paul for this article. Something we all can pass on to our bosses, clients or fellow devs/designers. =)

  9. 14

    Geraint Perkins

    November 21, 2014 4:23 pm

    Great article, cannot agree more. Many times I have been in the situation where a design has been created that cannot be built. Apart from that I think as a developer you will take a different perspective on how you would use the web page/ application/ feature and may spot a problem that could effect the end user or device.

  10. 15

    This article needs to be sent to every design/creative/branding/marketing agency in Seattle.

    Out of the 200+ agencies in/around Seattle, well over half of them force their developers to work in silos and only see the designs after each page is approved by the client. And of course, it’s the developer who gets stuck holding the bag when the project fails.

    It’s a sad state of affairs in the PNW.

    • 16

      Interesting that you say this, I am curious about this model. How prevelant is this setup, where devs and designers are seperated and not involved in the overall process? Where did you get the 50% number? Do you think this reflects other cities and countries outside of Seattle?

  11. 17

    Terrible article. I am both a designer and developer, and from my experience developers are the worst people ever. They should think instead of just doing what they are told. All the comments so far are just sad developers who are frustrated about their own incompetence.

    The article writer shamelessly promotes developers as the backbone of the internet and the forgotten heros of our time. This couldn’t be more false. Developers are shortminded people who only think in problems.

    Everything is possible and designers drives innovation, not developers. Developers only try to do the least work possible, by sabotaging every ambitious or challenging project that comes their way.

    • 18

      Riiiiiight. If it wasn’t for the account managers, designers w titles, and anyone else that’s never written a line of code, all of which have an over developed sense of value, developers would be able to do what they do best – put out the best project possible for the budget and timeline presented.

      I’ll tell you what… take that pretty JPG or PDF you made and had the client sign off on, open it in a browser, and show me the interaction. Oh, you can’t? And why is that? Maybe it is because there is no web without development. The sooner creatives realize this the better the industry would be.

      Creative types forget that design is just someone’s opinion. The designer’s opinion, the CD’s opinion, the client contact’s opinion, and the client’s boss’ opinion. It stops being an opinion when real data is backing the decisions.

      It’s plain ignorance if you honestly think that in this day and age developers do not want to challenge themselves and put out an amazing product.

      Unfortunately, too many people that don’t know squat about what goes into building a website think that being challenged means building out something impossible in the time given.

      It would be different if designers were held accountable for their uninformed decisions and for not doing their due diligence like actively involving the project’s developer in the proposal/design/ux process.

      But they’re not. Ever.

      It is always the developer that is raked through the coals no matter how many times they speak up and explain why the design they have seen for the first time won’t work in the time they’ve been given. And it’s the same response every single time – the client approved it so we have to do it.

      THAT is incompetence at every level.

      • 19

        Sadly……I have to agree to some of this.

        If clients see and sign off on work that hasn’t even been seen by a developer, but there are massive development issues, the blame usually goes to the developer or people think the developer may not know how to do it or something.

        An ideal workflow has a PM, a designer and a developer in all creative meetings to make sure the clients needs are met, the designs are fluid, and the development possible.

    • 20

      Yeah right. Everything is possible. With that attitude you will end up with designs that are horrible to built with current web technologies and hard to maintain.

    • 21

      I am going to go ahead and presume you are joking.

    • 22

      Innovation is never design, and has never been. Instead, innovation is enhanced functionality. Current design trends involve hiding stuff so you can… add more white space, because barren/sparse looks good.

      Hiding functionality can occasionally enhance functionality, by splitting up tasks into manageable steps. But mostly, you do it because you prioritize good looks over usability. In turn, you may do that because you know good looks sells, and you want the client to take the project. I guess clients would like to just point at a design and say “I want that”, and ignore that they’re having a tech product that has to work made for them. If a tech savvy person is not in the client meeting, it’s your responsibility to sell them something that works.

      When you make designs that are technically harder to solve, build robustly, and maintain, or involve more steps and therefore more work, the question that should be asked is, ‘who were responsible for making the product expensive to develop…who lowered the project’s profitability’?

      That would probably be quickly found out in a meeting where the developer is present. When more than one developer is involved, you usually can’t pull stunts like these because it will crop up early in meetings – if it can be foreseen.

      Because you see, everything is only possible if development time is infinite. In the real world, developers have to work within the possibilities of the frameworks they spent years learning, fighting the frameworks, some irking framework bug, some browser’s or device’s quirk, compatibility issues between any of 20 components involved, writing thousands of lines of code where one typo can give a very hard to find bug, to implement the design, which can have none of these issues.

      You wouldn’t believe how many simple things are impossible when things _have_ to get technical. Browse around for a week solid to get a mere glimpse.

      Current design trends are easy to duplicate for a developer. With designs growing simpler and simpler, designers may become obsolete.

      • 23

        And everything is going to look the same…

      • 24

        I agreed with almost everything, until I read this, “With designs growing simpler and simpler, designers may become obsolete.”

        Designers will never become obsolete. And by designers, this does not only include UI Designers, but UX Designers as well. Just because a developer can go to a site to find common UI/UX Design Patterns doesn’t necessarily mean they’ll be able to incorporate those patterns effectively.

        Developers will always need designers, and vice versa. There will always be a symbiotic relationship between the two that companies cannot simply live without.

    • 25

      Way to be a Dick, Jansen. Sadly I think your point of view is outdated and “shortminded”. Fortunately, you mentioned you were also a developer so that must explain it, right?

      This article encourages cross-over, for a better product and more awareness of boundaries up front. If you can’t see that much being important than I just don’t understand how you can be a self-proclaimed “designer and developer”.

      I am a developer and I have often worked closely with designers. From my experience, it can be quite harmonious.

    • 26

      “The article writer shamelessly promotes developers as the backbone of the internet and the forgotten heros of our time. This couldn’t be more false. Developers are shortminded people who only think in problems.”

      And guess who takes the most heat when a bug gets discovered on production? Even for minor bugs, developers get bashed as if the issues were blocking. Please don’t generalize your experiences as truth. You’ve either been working with some really bad developers, or you’re the one with the problem; a person who knows nothing about compromise and being a team players. It’s one or the other buddy.

  12. 27

    Jabran Rafique

    November 21, 2014 6:07 pm

    I myself being an important part of each project, completely agree to this. This definitely saves a heck lot of time for developers and designers at later stages.

  13. 28

    Good article.

    There is another aspect to this, which developer you should be working with.

    In my experience, the *best* relationship is where a front-end/ux developer is the glue between the designers and the programmers – an interface.

    Sure, the lines are never that defined, but there are some generalisations that will often ring true.

    Backend programmers *tend* to not really care nor understand visual or UX design. Their design is systems communication.

    On the other side, designers rarely understand nor care about exactly what happens in the backend.

    Enter the go-between. The developer with design ideas, who loves UX, loves tinkering with aspects of the backend but prefers working with front-end.

    There’s rare breeds that sit between all these camps – designers who can code, coders who can design and there’s never an *exact* fit.

    Then we get the business folks. It’s also important to have them involved with the process from the outset. They may not be in every meeting, but it’s imperative that a top down approach is avoided at all costs.

    I’ve lost count of the amount of meetings I’ve been in where all a marketing person can offer is “I think the header is the wrong shade of blue.” – when what we’re actually in the meeting to discuss, is the business logic!

  14. 29

    Is the “designer pride” really that wide spread? I do agree that developers need to be brought into a conversation at first stage of the design design process, that has always been my position on web related projects. It is surprising to me that some agencies don’t seem to hold that position.

    • 30

      It unfortunately is very wide spread.

      While design (and all aspects of it) are important, it’s not more important than development or project management or any other part of the process. In fact, you can build a site without a full design. Will it be the most gorgeous thing ever? No. Will it win awards? No. But will it be functional enough to accomplish the client’s goals? More than likely.

      There’s a definite elitist thing going on and has been increasingly more prevalent over the years where designers cannot be bothered to listen or even ask if some functionality they are looking to design is not only possible but more importantly possible in the budget and timeline given.

      God forbid you have to build for IE7-9 browsers. I have yet to meet an agency that is willing to put out a lesser experience and are befuddled as to why this multilevel parallax gmail-like facebook-clone super-interactive site that they’ve spent the last 4 weeks designing won’t work in IE7-9 in the 5 days you’ve been given to build it.

      It’s even more prevalent in designers that are tasked to design emails. Most (not all but most) don’t understand the limitations that email clients (phone and desktop) bring to the table so they design these great wondrous things and then get pissy when you explain the numerous problems with their design.

      And of course these are never seen as the developer trying to put out the best solution possible, it’s the developer being “difficult” or not a team player.

      It boils down to a lack of understanding of the functionality and technical limitations that exist behind practically all elements of a site and an unwillingness to admit that they don’t know.

    • 31

      It can be beaten out of them over time :)

      Every good designer I’ve worked with has admitted, in the past, they’ve put pride before purpose. That’s a completely understandable trait. You put your heart & soul into a design and then, someone who doesn’t know their cymk from their rgb comes along and pulls it to pieces.

      Design is far more subjective than development, because eveyone feels they have a stake in the artwork. It’s immediately visible. Development, on the other hand, can hide all manner of bad practices. A good designer will *know* why specific elements of their design are correct and will be able to explain colour choice, font weight, space & flow. They will know *how* they want interaction to happen, how fast, how fluid. They will be able to storyboard user journeys.

      A good front-end developer must have a design eye, being able to take a provided design and extend it, while collaborating with the designer.

      But don’t even get me started on developer pride :)

  15. 32

    Yes, yes, yes.
    That’s why i started to learn code: i wanted to know what problems is the coder facing sometimes. And this helped me a lot on thinking about possible ideas, and not only too-difficult-to-implement design show-offs.

    Very nice read, thank you.

  16. 33

    Excellent article, and thanks for raising this problem Paul!

    As a freelance web developer and regularly working with many “web” designers/agencies integrating stuff into CMS’s, so I can empathise with everything you said.

    Some designers/agencies are truly excellent and provide not only standard image mockups, but a full breakdown of structure content, required fieldtypes, expected behaviours (for both styling and content), and a flexible approach if I find issues with any suggested design patterns.

    On the other hand some don’t really have a clue outside of a pretty PSD. Typically:

    – I’ll get no information on structured content (most don’t know what structured content is), leaving me to best guess and requiring extra meetings/time to find out what their content structure is so things can be done properly

    – awkward designs to cater for (even worse when they haven’t considered RWD!) which leads to code bloat, slow page load etc

    – absolutely no flexibility with the “design” – “we want it as it’s shown”, often even if it’s at a cost of a ton of extra CSS, JS and decorative images just get that “effect” (poor mobile customers!)

    I could go on.

    I’ve always seen the commonly used “design” process as being backwards. It’s the developer who should be the lead, not the designer. The developer they can then suss out the content requirements, data structure, any areas that may be problematic and so on. Once that initial ground work has been done then bring the designer on board to design according to the projects requirements.

    Think of it this way. If you’re building a new house you employ an architect first, not the interior designer!

    Rant over :)

    • 34

      Good point with the house example. The only thing is, the architect is the designer and the developer is the builder. Approaching design as an afterthought (interior decorator) is a bad practice that used to be common in the 90s.

      There is a reason why design should lead development. Most of the times developers think constrained by technical limitations and that is not beneficial to the product. Start with a blank canvas and design with the end user in mind. That’s all you need really, design and development serves a purpose and that purpose should be based in user research and user testing. Everyone should be involved but is the designers job to emphatize with users and to design solutions that not only look great but work in a way that delight users.

      Developers in most cases approach problems within the technical boundaries they are aware of. And that is not a bad thing since that is their job.

      It is however beneficial to not constrain yourself and think about interfaces in a human way, and that is exactly what a good designer should be good at and that is why it is important to involve developers in design discussions but not let them lead the design process.

      • 35

        Yeh true, though the architect is neither designer or developer!

        I’d have to disagree with (visual) design *always* leading development. That’s why the “architect” is the ideal person to lead since they are responsible for the overall structure, ie making sure the building is suitable for the home owners needs, addressing basic requirements like wiring, plumbing, ventilation, room sizes, walkways, lighting and so on. In web terms that’s content requirements.

        Then, as you say, it’s the developer who puts the house together. In terms of a CMS that would be templates, HTML/data structure publishing channels, custom fields – anything the client needs to manage their house (site) from day to day.

        The (visual) designers job is to create a look and feel for the sites visitors (UX/UI?) and more importantly for the myriad of devices we have to support. In house terms that’s probably choosing the type of brick, windows, fixtures and fittings, interior decoration etc. In web terms that’s colours, typography, call to action styles, logo design etc.

        I’d agree though that all interested parties should be in at the start to avoid potential pitfalls with any part of the process.

        I’d have to disagree about (all) developers being constrained by technical limitations, after all it’s us developers who often have to point out issues to designers, such as accessibility, usability, RWD, design bloat, page speed, inflexibility with a design (think shoehorning content) and the rest of it. Granted many designers do have good knowledge about how the web works, but on the other hand many don’t!

        Just my 10p’s worth :)

      • 36

        Good comment! I agree with you.

    • 37

      Mark F. Simchock

      November 24, 2014 11:05 pm

      Yes. Agreed. The problem is, much of this old habit dates back to the roots of web design. Agencies that did graphic design jumped on the internet band wagon – often per client request – and developed a process that was design-centric (?). Back in the days of static html pages that was fine.

      But now it’s 2015. Clearly we’re not in that Kansas any more.

      Unfortunately, no agency / designer is going to (come to their senses and) stand up and volunteer for less importance in what is now a very technology driven process process.

      Rant never ending :)

  17. 38

    When the headline to this article flashed on my mobile device I must admit I got pretty excited. I strongly agree, and also the point you made about developers doing design work is very true, I often need to tweak designs to fit content. The growing field of UX design in web has really helped introduce developers into the process.

  18. 39

    Mark F. Simchock

    November 22, 2014 2:06 am

    Fact: With rare exception every project has context. Included in context is budget; both time and hard dollars.

    So it’s not a matter of “infeasible ideas” per se (i.e., “But we need developers not only to block infeasible ideas.”) That is, with rare exception, anything is possible. As in, “Anything is possible. Do you have your cheque book handy?”

    Finally, I’ve said this before and I’m sure I’ll say it again:

    “Design without consideration for manufacturing is not design; it’s art.”

    Unfortunately, based on what I’ve experienced (and heard from others), this is not something they teach in design school. To put it bluntly, more designers need to be mindful that most clients / project aren’t paying for art. If you can’t do great design within the context at hand, then it’s probably time to consider another career. For example, say, artist.

    • 40

      Wow! THIS x 1000! I can’t tell you how many designers that I’ve known that can create STUNNING designs with ZERO practicality.

      Picasso was a great artist. But, I would be infuriated if I commissioned a self-portrait and received a Picasso-style portrait of myself. Just because the art is great, doesn’t mean it is applicable to the purpose at hand.

    • 41

      Can you please start a design school, immediately burn down all competing facilities with out-dated philosophies, and take over the education of all new web designers entering the industry?

      I would give anything – as a web developer – to work with “designers” as opposed to “artists”.

    • 42

      You forgot one last thing that needs to be considered in addition to time and cost: scope. +1 for everything else. :)

  19. 43

    I have been preaching this for a long time. The last senior developer position I held, I found myself having to walk over to the designers to question them on functionality, the size resolutions they designed for, mobile designs and functionality, etc etc. Many times my comments ended up making the designers redesign something or go back to the drawing board. So it ended up becoming a love/hate relationship I feel like.

    I’ve moved to another agency now where two developers and two designers share a room and I love it. The designers are learning css and basic code. They also teach me good design and color theory. It’s actually a lot more fun because we conceptualize together throughout the entire project. I wish my last job had been like that. I always felt like “just a developer” since we were at the end of the line and had no input during the planning phase.

  20. 44

    Just last month, I started working as a contractor for a marketing firm and was given a website to develop from a PSD. After two weeks of work developing this site, the PM tells me that the client wants the end user to go through a certain process to purchase composite items, instead of being able to add one item at a time to the cart. After wasting another day on development (with a project that was supposed to be launched the next week), I offered a better solution that the clients really liked. Afterwards, I asked the PM if it would be cool if I were included in the design phase for future projects, and he told me that no other developer that he’s worked with has ever really spoken up before — they just do as they’re told.

    I think that there’s a lot of truth to this article because including the developer in design work would cut down on a lot of wasted time and frustration. Maybe if it were done more often, the argument for designers learning code wouldn’t be so prevalent.

    Then again, with the architect/builder/interior designer metaphor, it seems that if developers are builders and designers are interior designers, then architects would be a bridge between the two. Architects are able to design structurally sound homes with all the basic elements of a comfortable and functional home in mind because they learn from both sides. Architects learn about building materials and feasibility. They learn about the various design methods and traditions that are used in pretty much every home. Because of that knowledge, they can lay out plans that the builders can follow, and those plans allow the interior designers to do their jobs.

    So in the case of web design and development, it seems to me that having a “web architect” on the team would be the way to bridge the gap. Having someone who knows the ins and outs of both disciplines and can brainstorm and collaborate with designers and developers would make things much easier for both parties. Especially when designers and developers seem to have so much angst towards each other.

    I know that from my experience, having someone who can make designs development-ready would be awesome.

  21. 45

    Over 30 years as architect I have always straddled both worlds of designer and developer. I’ve learn to adapt to teams where there are resources specific to each where I function between each. I can’t say that those hybrid teams always succeed, and I have learned that the communication between designer and developer needs to be bi-directional. Honestly I have less sympathy these days with the so called web designer that can’t code, at least in HTML5, CSS3 and Javascript, and little affection for the web developer who doesn’t, at least in principle, understand web design and usability. Mainly the reason for this is that training assets are at our fingertips. Smashing Magazine is itself among the greatest if these.

  22. 46

    I’m 70/30, developer/designer. Though I agree with “Form follows function” that does not make function superior to form. It is a sequence of steps; to stop at the first would be akin to turning a knob but not opening the door. I see many people use the test scenario “which is better, a beautiful website that is static, or a flat website that provides needed functionality.” The answer to me is “neither.”

    Yes, I believe both Developer and Designer need to be in on projects; that works both ways. And I do believe that both will benefit from knowing the basics of the other’s field (though I’d never expect them to be anywhere on the caliber that the other is in their respective field) But design is every bit as important as function. Neither is better than the other, and a project with both will ALWAYS be better than with that has either or.

    A functional site with no design? It’s just text. Just walls of text. No fonts, kerning, whitespace, indentation, none of that. THOSE elements ARE part of design. Content may be king, it may be one of the reasons WHY we go to a site, but Design is what helps us to consume that content quickly and efficiently. In this day and age, the consumer is very impatient, and though they may not be aware of all the design cues which help them subconsciously to enjoy the site as they do, they are, IMO, every bit as important as the function.

    To me, Designer and Developer are Yin and Yang, though commonly pitting themselves against each other, they are blind to realize that BOTH are necessary. It is mind boggling how much knowledge each must have of their field to be exceptional at it, and a mutual respect should be shown to each other. One side creative, one side logical, neither side good nor bad, they are 2 parts to 1 whole. A team. Alone, they will always fail, but together, they gain the potential to succeed.

  23. 47

    As a UXer, I think having Developers working with UX and Design team and UXers/Designers knowing a bit of coding is a MUST!

    No more discussions needed on this subject. And the Designers that cannot understand the importance of knowing/trying development can easily consider themselves out of a job – so they’d better make the money they can now because later on there will be nothing to lucrate on.

    Sorry for being so direct, but I believe that UX and Design have the mission to adapt themselves to new technologies and needs, and I feel really depressed when I see people that consider themselves “creative” (and usually are in very high positions, like Group Directors etc) and literally have no clue of development (I believe they have never seen a text editor or a basic html code) – with the result of slowing down the “real creativity”, which to me is “find creative and beautiful solutions to the technical (browser, device, data download etc) constraints”.

  24. 48

    Great article and an issue I have recently discussed with colleagues.

    I think it’s time the design process is turned on its head with developers speaking with clients to discuss what data is available from a db/api perspective, a front-end dev to discuss what can be done with that data and then the designer to theme the content.

    That way a client and a designer has a very clear definition from the outset of what is possible in terms of content which at the end of it all, is what a user comes to a website for, not for the design.

    • 49

      “I think it’s time the design process is turned on its head with developers speaking with clients to discuss what data is available from a db/api perspective”

      I’m pretty sure clients don’t care about all the technical (back-end) details. Usually, all they care about is what they can get with X amount of dollars in Y amount of time. Clients don’t need to know about MySQL, Mongo, REST, JSON, etc. You can generalize things in layman terms by talking about how complex something is by stating the effort is either small, medium, or large; but anything other than that will usually just go over their heads.

      I don’t think it’s a bad idea from “the team” to meet with clients to ask questions about the requirements. Just be mindful with what you say and choose your words wisely.

      “That way a client and a designer has a very clear definition from the outset of what is possible in terms of content which at the end of it all, is what a user comes to a website for, not for the design.”

      Users come to a site for various things: good content, user experience, AND the design. Do you honestly believe that users won’t complain if a developer decides to create a site using a black background, a gray text, and/or forms that produce cryptic error messages at the top of the page? Of course this is a stretch, but I have seen one to many sites that were poorly designed that made it difficult for me to navigate and find what I’m looking for; not to mention, poor UX.

      Design is very much important. You should Google “5 principles of interaction design” to get a better why design is just as important as everything else.

  25. 50

    Sometimes it’s best to start with designs and UI ideas that seem “impossible to build”, that’s when you haven’t let technical limitations cloud your creative process. Some layouts take more work but nothing is impossible. I find myself falling into lazy design habits when I let my developer brain take over.

  26. 51

    Im a designer and developer. When I have to slice and code work from a designer with zero coding background, its an absolute nightmare and takes much more time. Even worse when a client has approved the designs. Although I understand that everyone has to start somewhere and I do my best to educate them on how to create designs that will flow seamlessly through development.

  27. 52

    Web Designers should understand their medium. No Web Designer should ever design anything that cannot be built (progressive yes, impossible no).

  28. 53

    As a developer, I hate it when designers design without consulting me regarding feasibility. But as a designer too, I hate it when developers makes “minimalistic approach” or “usability” an excuse not to innovate.

    I think designers and developers should have a clear understanding of both nature. As a creative, I am happy that I have been very open to developers on my early stage of career which enabled me to design and develop now. No developer is above a designer and vice versa. In the end, the output will be assessed collectively.

  29. 54

    This is one of the reasons that I love working in an Agile development environment. The product owners (clients) discuss their feature requests directly with the development team who will be working on the code. Whether it is front-end or back-end development, the developers working on the feature as well as a QA rep and a UI/UX rep discuss what is to be implemented with the product owner. In this way, all of the potential issues can be identified and end goals agreed upon before a single line of code is written. Design is done in an iterative manner rather than all of the design being finished and then jamming code in behind it to “make it work”. We start with a loose set of design guidelines and build as needed. Function is given primary consideration with the designer given the task of working with the devs to “make it pretty”. I realize this may not work for every client but it has worked for us. Agile development FTW!

  30. 55

    Good article. I totally agree. The role of the designer is not exclusive to a certain type of individual. Perhaps in the eighties it was, but today the design process involves many specialisms as strategy or product development moves from the initial funding phase >> through the design process >> and out toward production. The design process should embrace all cerebral input and analysis if it is to harness the best possible outcome. I might have been described as a designer once, now I enable design to develop and respond in an agile workflow by … blah blah … I am sure you get the idea.

  31. 56

    When I first arrived at my current company, the process was “Design”, “Code”, “Deploy”. The designs were beautiful, but had very little interactivity and flow. They were certainly not flexible, fluid, or responsive. One of the reasons I was hired was to bring responsive design to the company (and I have a fair amount of graphic design experience). Imagine their surprise when I immediately began to shake up their workflow and informed them that in order to make your sites responsive (rather than serving up a mobile site), I needed to be involved in the design process. A few people resisted in the beginning and felt like I was trying to take over the design process. Fast forward to about a year later and now I lead the design conversations for our websites and everyone agrees that our sites have become more powerful, beautiful, and dynamic! Take the steps to involve your developers. Together, designers and developers can create incredible things!

  32. 57

    This is a nice information but at some places the Developer should include in the Designing if there any small issues occur in the some websites the developer need not to approach the designer from the back end they can do changes at critical situatuions.

  33. 58

    I couldn’t agree more. And not only for purely technical reasons. Developers often have an ability to understand how these designs will be used and what will work or not work when it comes to users. These are the people who spend their time turning design ideas into a useable product so their input should hold a lot of weight.

  34. 59

    Web Designers should understand their medium. No Web Designer should ever design anything that cannot be built AND Developer should include in the Designing if there any small issues occur in the some websites the developer need not to approach the Web design services from the back end they can do changes at critical situatuions.

  35. 60

    Mahmoud Metwally

    November 25, 2014 2:19 pm

    actually I agree with every sentence you write but you should focus on two points 1st. these discussion should be manged by the art director or who lead the design department to validate and evaluate ideas from 2 sides because developer can suggest a lot of ideas can break the concept and the consistency of the product. 2nd. and it’s more important developer should train himself and have a wide vision of what the normal users do daily in web and even mobile, Most of developers and even us as designers are geeks so we are not the normal users so if the developer have any concerns on performance or the story and steps of process it’s okay for sure but if it about the concept and the experience I think we need a middle man responsible for validating and make sure it works with the concept and the consistency of the product.

  36. 61

    So true!

  37. 62

    Thank you for the article. I totally agree. And yet for me as a ux designer working at an agency it is not that easy and I have the feeling that a solution is hard to find.
    There are many parties involved that I have to satisfy during the design process: “the client”, “our project managers”, “the ux director” and “the developer”, the people that have to work with the CMS once the website is ready and of course “THE USER”. When designing , I usually try to think of all the requirements from each group. What are the business goals, what are the users goals, what kind of design performs well (e.g. loading times), what templates are already developed that we can reuse with a different visual design(budget decision), do I pick the easier solution because I know the results of the user tests and it is easy to develop, or do we have enough budget to try something new.

    If you try to establish some very important strategic decisions for a website, a developer is usally not necessary, also I rarely met developers who are interested in business goals and digital strategy( I don’t mean to offend anyone). So to involve a developer very early, before the information architectur and visual design stage is very difficult for me. A lot of developers I work with are not even in the same office, they sit all over the world, get their briefing, get the job done, are paid and don’t overthink it. Then there are a few developers I met who really want the best for the project, they care about a beautiful design that works well as much as a clean CMS that you can easily work with, but in my experience they are hard to find. So in the end it really depends on the structure of the company, on the expertise level of the developer if involving them early makes sense or not. At least for me. Please let me know if someone has a better solution…

  38. 63

    What your talking about falls onto the Project Manager. As a project manager myself, it is my responsibility to ensure that the clients needs are met within the timeline and agreed upon budget. This requires balancing designer’s visions and feasibility of development. As mentioned, with infinite resources and time pretty much any layout is doable, but if it doesn’t fit with the project, it can’t be done.

    Generally speaking as long as both development parties and designers are respectful, balancing design and development should be an amenable experience. But, when all is said and done, it comes down to timeline and budget and usually a developer is better at understanding this.

    That said, I have made the mistake of showing a design to a client before going over it with developers. This led to me having to backtrack, rather uncomfortably, with the client. It won’t happen again.

  39. 64

    design is development. development is design.

  40. 65

    In my company I am the one designer on a team of 5 developers and the project leader who is also the company founder ( I smell a difficult stake-holder! ).

    I always show developers my designs and some are more happy to just do whatever they’re given and not worry about it whereas others want to question every minute detail to the extent it makes you question whether they just think you’re incompetent and they do not trust your judgement.

    More often than not I am walking a very thin line between accepting other developers’ points of views whilst trying to maintain some integrity – when they start moaning that the user will be confused because of my design it does hurt but I take it onboard and try to get everyone behind a decision. Unfortunately this has often meant backing down to a particularly assertive developer because I feel that he will get stroppy if he loses the battle and has to build something he didn’t believe in from the get-go. This means some things get designed by committee and end up being crap and I lose my confidence.

    Other times everything goes really well and everyone is on the same page and we all feel good.

  41. 66

    I don’t know if anyone’s pointed this out yet, but the arguments put forward in this article apply both ways.

    Just as designers need to involve devs, and involve them in a way that means something to those devs, so those devs need to keep the designers informed of what they’re doing, and in a similar fashion.

    If you let a designer discover for themselves, on the production site, that a UI they designed hasn’t been built the way they specified then you rightly deserve an earful.

    This is particularly important when (as is the case most of the time) devs are building something the designer designed a long time ago.

    So to all those devs who are agreeing with this article – I hope you will also attempt to keep the designer(s) informed when you have built some UI, and to do so early and often. Continuous build servers, staging sites, notifications on significant commits – you know the score.

  42. 67

    Let me ask all of you this.

    What if your only designer on your team is a print designer by trade and has no training in interactive media but wants to own everything with the brand on it? I get mockups with design techniques from 10+ years ago.

    • 68

      Then your company needs to invest in training that individual. Whether that’s company money or developer time is up to your company, but no employee should be allowed or made to stagnate.

  43. 69

    100% agree with this.

    A web designer in my opinion, should know how to code front-end stuff… As a developer also, how many times I get designs given to me, where they’ve designed stuff that just makes development difficult, for no justified reasoning, is unbelievable…

    • 70

      I don’t think that designers need to know how to do front-end coding, necessarily (in my opinion, it risks holding them back as their development knowledge starts questioning whether a thing can be done), *but* I do think they should be thinking about the web as the interactive medium that it is, and be able to understand its strengths and weaknesses/limitations on a conceptual level.

      I’ve seen a number of times where designers not trained or experienced in the web as a medium have missed things that I’ve had to repeatedly go back and ask about — what should these buttons/links look like when hovered? Should this widget have an animation? If so, what kind? How should the error messages look?

      The designers I’ve worked with (that lack web experience) spend a great deal of time and attention to how things look as though they were designing a print or other non-interactive, fixed-media thing (I’ve spent far too many hours trying to align things down to the pixel across a stupid range of browsers). This results in some *really cool* designs that are hard as hell to code (and usually impossible to code such that things can be reused), but they don’t think about how it looks and acts while *interacting* with their design, and so, miss the crucial details that take a design from “cool to look at” to “really awesome to use.”

      Part of the problem is that design tools are still excruciatingly static and no one’s really come up with a way to convey animations/interactions without using storyboards in meetings or using something like Macaw, which has its own limitations (and which someone will try to use to replace front end developers, no doubt). As someone else mentioned, the waterfall approach a large number of agencies have, combined with the segregation of the designers and developers (if not physically or in rules, then functionally in the way projects are handled such that no one really has time to do anything else, making it very hard for designers to “go back” to a “past” project when the devs need help/design input).

      This is a huge reason to make sure a developer is involved from the early stages, especially if your designers have a mostly print background.

  44. 71

    In the end, it’s a matter of project management. As long as studio’s are still too stubborn to let go of waterfall methods, this issue will persist. Start scrumming!

  45. 72

    I agree, especially since I do both design and development. I’m lucky and unlucky in some ways. Sometimes the design, though visual pleasing, can cause issues in translation to development.

  46. 73

    Great article and comments. Our web designers code the front end and work closely with our programmers during the entire development process. This keeps everyone on the same page, working towards a common result.

    Over the years we’ve watched companies silo the designer/developer roles and always scratched our heads a little bit. There are pros and cons to both approaches, but for us, having designers and programmers share the development load, creates a better experience for everyone and delivers a better product to our clients.

  47. 74

    I’m designer who codes (self taught), to be honest these days I think it is important that designers can at the very least understand code. I think it makes a project so much easier if the designer is working with a developer and they can speak the same language and have an idea what is realistic in the time we’ve got.

  48. 75

    I completely agree with this. The agency I work for keeps developers and designers in the same room so we iron out design problems very early, before a client even sees a design. It is nice to be able to just turn my chair and ask a developer for an opinion on a design decision. I think more agencies would benefit from having a more collaborative environment for both designers and developers.


↑ Back to top