Menu Search
Jump to the content X X
Smashing Conf Barcelona 2016

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 Barcelona, dedicated to smart front-end techniques and design patterns.

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.

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

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.1
By including the developer in these decisions, we avoid wasted hours of work on something that is not cost-effective to build. (Image credit2)

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

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
SmashingConf Barcelona 2016

Hold on, Tiger! Thank you for reading the article. Did you know that we also publish printed books and run friendly conferences – crafted for pros like you? Like SmashingConf Barcelona, on October 25–26, with smart design patterns and front-end techniques.

↑ Back to top Tweet itShare on Facebook


Paul Boag is the author of Digital Adaptation 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.


↑ Back to top