Apologies if this is too much of a fuzzy question, I was wondering what people's thoughts were regarding the level of front-end development knowledge a UX professional (Experience Architect, Usability designer, Experience Designer - call it what you will) should have.

I'm guess I'm talking about situations where the two disciplines are handled by separate teams (UX team handle wireframes/designs/user journey and the front-end team actually do the coding).

Do you think the UX team can make do with a general level of front-end knowledge (basic understanding of HTML/CSS), or is it important for them to know the nitty gritty (semantic page structure, optimisation techniques, impact of JavaScript, graceful degradation/progressive enhancement, accessibility etc)?

Should a UX team be able to imagine how their designs/wireframes will be interpreted by the front-end team and what mark-up/technologies are likely to be used?

Does only having a limited knowledge of front-end development make for poorer UX?

Are the finer points of FE development solely the concern of the front-end devs, or should it be a consideration for the UX team as well?

As I said, I know it's a bit of a fuzzy question, but I'm just curious as to how people view the respective skills of FE and UX teams, and how much blurring there should ideally be between the two.

  • 3
    Related: Should user interface designers be able to build what they design? (Quora) - includes input from Rebekah Cox, Glen Murphy, Ryan Singer, Wilson Miner, and like 40 other people. Clearly a contentious topic on which everyone has an opinion (though note that the leading designers I mentioned largely share the same viewpoint).
    – Rahul
    Commented Jul 19, 2011 at 16:08

13 Answers 13


As a UX person who works in a situation like you describe (UX creates the specs, FE implements them), I can say that it is vitally important that my team know what is/is not possible when designing a UI. If something's completely impossible, we do our stakeholders a disservice by proposing it.

On the other hand, given that only a few member of our team members have formal coding experience, we always work in tandem with our developers. Often we'll sit down with the development team prior to presenting our designs to the stakeholders and discuss the potential coding pain points.

In particular, I believe that it is vitally important that UX folks have (at least) a theoretical understanding of "FE-related things", including semantic page structure, optimization techniques, impact of JavaScript, graceful degradation/progressive enhancement, accessibility, etc. Of course, there's always the viewpoint of Jared Spool; that in the future, all UX'ers will beed to be able to code (a viewpoint I don't necessarily agree with).

  • 1
    +1 for including a reference. I'd like to see more answers collecting data instead of just voicing opinions!
    – Rahul
    Commented Jul 19, 2011 at 16:19
  • I agree it is good knowledge to have. That said, if there is a product manager, the PM should be handling a lot of those considerations, too.
    – Taj Moore
    Commented Dec 6, 2011 at 19:31
  • @tajmo Agreed about PMs helping handle some of these things, but the UX person is ultimately responsible for designing practical systems/interfaces that can actually be built. Commented Dec 6, 2011 at 19:52

Short answer: "it depends".

I've been wrestling with this question for about 2 years. Some things to think about:

  • If you learn to code, you will spend a lot more time coding, and a lot less time designing. Muscles that you don't use will atrophy, and the ones you do use will build at the exclusion of others.

  • UX is a craft and must be coupled with something else, like visual design, material design, prototyping, or (as you asked) the ability to do some of the implementation work.

  • Most employers (and teams) have a desire to have someone who can "do both" but rarely is this the case; you're usually doing one or the other, and from my experience it will mostly be coding.

  • If you learn to code, you will have the burden of a coder. That is, you will notice that you will start to design for what you know you can develop.

  • There are positions open for those who are simply great designers, but these positions are few and far between and highly sought after. Adaptive Path, IDEO, etc. hire pure UX designers.

So "should" you? I don't know you. If you're a stellar designer, that is, breathtaking sketching and visual design skills, then keep doing that. If you're someone who wants to work to make a product real, then perhaps coding is a good skill to have.

I consider myself a UX person with technical skills. After 3 years of solutions architecture work I went back to school to get my HCI degree, then went to work as a UX designer. I find that having my technical background gives me more of an edge in leadership roles than a pure designer, but my designs are less creative and innovative than those who get the opportunity to only focus on design.

My advice? Do what you find interesting alongside pure UX work. This may include visual design or development work.

  • "UX is a craft and must be coupled with something else" -> And why is that?
    – Phil
    Commented Jul 19, 2011 at 14:36
  • Good advice! "If you learn to code, you will spend a lot more time coding, and a lot less time designing" --> I argue that UX coding is as much about the design as UX sketching. It's one of the tools a UX designer uses to create the UX. I do agree with your 4th bullet...that is definitely something to be cognisant of. However, I'd say that's less of an issue than the opposite...which is designing things that can't be implemented at all.
    – DA01
    Commented Jul 19, 2011 at 14:52
  • 1
    Phil - UX is a strategy, and while on it's own it can be valuable, I believe it needs to be paired with another tacit skill. This is because a designer must be able to communicate their work to a team, and without something to demonstrate work (sketching, visual design, etc.) you can quickly fall victim to the product-limiting "idea guy" role. Commented Jul 19, 2011 at 15:02
  • 1
    @Andrew: Ok, I see what you mean. I only do wireframes/concepts though (and project management), no coding or visual design. Works pretty well for me ;)
    – Phil
    Commented Jul 19, 2011 at 17:28
  • +1 for the "If you learn to code, you will have the burden of a coder." remark. It's related to the curse of knowledge. Some kind of ignorance of the deep technical details may actually be an advantage in terms of coming up with something great and different (in a good sense). That said, a UX designer still needs to have a good understanding of how UI components work and play together, when to use what and of the characteristics of the platform - not to mention at least a high-level understanding of how backend stuff (e.g. data retrieval) may affect UX. The main task of UX designers, though,..
    – agib
    Commented Aug 10, 2011 at 8:14

This is something that keeps upsetting me. Both your question and almost all answers so far seem to be working under the assumption that UX people design products for the web. Hence, they "need to have basic knowledge of HTML, CSS and Javascript".

Why is that? What about all those who design for desktop and mobile and various specialized platforms - from kiosks to copy machines to TVs to aircraft displays? Do they need to have a basic knowledge of C, Java, .NET or whatever?

Does it make them a worse UX person if they don't? And keep in mind that we're talking about the vast majority of UX folks working at all of these and countless more. So it's not as negligible a percentage of the industry as people seem to believe - I actually think it's at the very least 50% of it (look at the link again :) ).

To make this answer not completely pointless (yes, this should've been a comment) - it's extremely helpful if UX designers understand how programming works, so that the platform is not a black mystery box to them, and they can communicate efficiently with the techies. But beyond that it's really just a skill that is very nice to have, but by no means necessary.

  • 3
    Haha you're right. Just too many web people here (including me). :D
    – Phil
    Commented Jul 19, 2011 at 17:30
  • Bear in mind that most people using UX.SE are web designers/developers of some kind so obviously they speak from their context/domain knowledge. You can replace "HTML/CSS/JS" with pretty much what you said - knowledge of the technical abilities and constraints of the platform they're designing for - and still mean essentially the same thing.
    – Rahul
    Commented Jul 19, 2011 at 20:03
  • 3
    @Rahul, I think these are two completely different things. I'm well aware of the capabilities and limitations of the platforms I work with, yet I can't write one line of HTML or any other programming language (unless you count Borland Pascal). Awareness/knowledge is one thing, being able to build something - as most answers here expect - is a very different matter. Commented Jul 19, 2011 at 20:09
  • 1
    @DA01 See my answer to Rahul. I think you'll agree with me that familiarity with the platform and the ability to build something yourself are completely different things. Commented Jul 19, 2011 at 20:35
  • 1
    Indeed. I've worked as a UX professional for nearly 20 years and never designed a website in my life.
    – calum_b
    Commented Jul 19, 2011 at 21:16

Development skills are obviously important - more so for smaller teams than larger teams. Those skills should be covered within the design team in one way or another.

More importantly, UX professionals should be either extremely close to, or do themselves, direct user support. Hearing pain points directly from customers or users should be a direct influence on the ongoing UX design work, refining the product to solve those problems.

Here's 37signal's take on this from their first book

  • Agree on your point about doing direct user support, and second the notion that a UX pro must be able to do development.
    – Subimage
    Commented Jul 19, 2011 at 20:38
  • 1
    Balance is key. I work at a company where developers do tech support, and a common complaint is that the constant interruptions make it hard to get in the zone and program.
    – James
    Commented Jul 20, 2011 at 16:14

A UX team that can't build their UX recommendations is a rather useless UX team.

Individual UX members don't have to be front-end-coders, but the skillset has to exist within the team as a whole. I've found that UX teams that do not handle any of the front end production tend to:

  • design interfaces that aren't leveraging up-to-date features of the browsers
  • design interfaces that simply don't work on screen (typically omitting key steps)
  • design interfaces that are atypical and/or are reinventing the wheel
  • don't fully think through every point of interaction
  • fail to design for contingencies

I'll add that an organization that splits its UX team from it's FE dev team is set up to fail in the realm of user experience. I've worked in both situations and the situations where the UX team has no development responsibility, there are huge amounts of inefficiencies throughout the project as so much has to go back and forth between the separate departments without any true iterative design.

An analogy is an architect that has no practical building experience. Said architects exist, and some are quite famous, but for most architects, to be good at what they do, they have to design structures that can be built in terms of engineering, budgets and timelines.

A UX team with no front end development skills is like a painter with no brush skills. ;)


I think for a UX designer it's important to understand the basics of frontend development. You should know what HTML, CSS and JS is, how it's interpreted by the browser and how the web works in general. But I don't think it's necessary to have in depth knowledge of all possibilities. That said, it's essential that UX designers, frontend developers and graphic designers work together very closely.

Additional thoughts: I don't think it's usually a good idea when one person is responsible for two different disciplines (coding and UX design) because there aren't many people who can be very good at two things (usually you have to focus to become the best). And there's the danger that a UX person who codes the page himself will only design stuff that he knows how to code.

I'm aware that this probably isn't a very popular opinion, but I think specialists working together closely is what produces state of the art solutions and pushes the boundaries of what's possible. Remember the time when we were called Webdesigners? Programming, frontend, design, project management etc. was all done by one person. Was it fun? Sure! Did it produce good results? Rarely.

In my company frontend development and UX and UI design is one team (2 coders, 2 graphic designers, 1 UX architect) and I think that's the way it should be.

  • I agree, though say those are required skillsets rather than necessarily individual people. The key is that the UX team has a solid generalist skill set with the required specialist skill sets for the particular project.
    – DA01
    Commented Jul 19, 2011 at 14:58
  • You're lucky that you have a frontend development team. Some of us without that many resources have to actually become proficient with UX/UI architecture simply because there's no one else with it on their radar.
    – Nic
    Commented Jul 19, 2011 at 21:06

I'm not sure that a UX professional who knows about front end development would make for better or poorer UX per se, after all, the UX person should be aware of progress through the lifecycle and reign it in where it's going astray. If we did our work and passed it on to the next group without so much as another glance, you'd end up with the classic tree swing scenario.

Which brings me the point I want to make which is that having knowledge of the front end developer area, being familiar with their skills, their tools and their language and terminology is only going to greatly help the communication of ideas at many levels between groups, whether as part of a formal specification - or just coffee room chat.

And that goes for all the groups involved in producing a product - graphic design, marketing, branding, front end development, content managers, technical writers, and the boardroom - all the stakeholders. The UX field is broad and to understand all these roles, be familiar with their world, and to empathize with them allows the UX professional to communicate much better, both in understanding the needs of other groups and in conveying their own ideas, designs and reasoning.

Thus it makes for a more efficient process, and perhaps a slightly friendlier one, if other groups respect the fact that they understand each others language. It's a bit like us Brits going abroad and being accepted by the French a bit more for at least trying to speak their language a little bit.

I'm not sure that knowledge of the front end is a problem as the user experience is so much more about the users, that it's quite a different mindset, far removed from worrying about the capabilities of the developer's tools or technical limitations of the development environment.

Does the end result (the user experience) improve as a result? I'm not sure it does. Is the efficiency of the process from concept to completion improved - definitely.

Communication matters.

  • 2
    I agree. Sadly, many larger organizations have very formal splits between groups. I current work in an org with a split between UX and FE Dev where both answer to separate bosses, separate budget pools, etc. So, sometimes the communication loops suffers greatly at the hands of antiquated corporate org charts.
    – DA01
    Commented Jul 19, 2011 at 14:54

Specialization is the foundation of our modern economy. In the days of yore, an artist was required to mix their own paints. Now they can buy them in the store in any hue (please note that I am not an artist). I feel that this split is analogous - front end developers are the paint mixers to the UX professional. Nevertheless, an strong understanding of your tools is essential to any professional.

UX professionals should develop a strong working knowledge of the things that are easy and the things that are hard to do within the framework that they choose. Commonly used are HTML/CSS, MS Windows API, Flash, maybe even the console. Occasionally a framework is developed specifically for the application, such as in video games. Knowing what can be accomplished with the framework is essential. As an understanding of the framework grows, so too does the ease of implementation.

On the matter of general purpose programming in specific; this is a valuable skill - but not essential for a UX professional. As the fields are still somewhat overlapping, in the present day it has a greater import than it will in the future, but I do not see it becoming redundant any time soon.


From the users perspective I can see that it would be an advantage to have a UX designer that is not a front-end developer. That way, when designing a UI, they are not at all swayed by technicalities. If that person will have to ultimately code the solution themselves then each design decision will involve balancing the users needs with how difficult it is to build (and also with what cool things they have seen recently that they would like to have a go at building :)).

I'm speaking from experience as I am both a UX designer and a front-end developer.

  • But is it bad to be 'swayed by technicalities'? I find UX designers that poo-poo said limitations are more often than not, not very good UX designers. Design is very much about the medium one works in and all mediums have a defined range of capabilities. A good designer doesn't consider them limitations, but merely the framework of the medium they are working in. A good design solution also has to be a pragmatic one most of the time.
    – DA01
    Commented Jul 19, 2011 at 14:56
  • @benb - The only problem with this is, when the developer decides not to listen because of the technicalities, or blames technicalities for his laziness to implement a solution. It is helpful to have an understanding so that you can work with these people, be able to call their bluff, or assist them in coming up with a workable solution. Commented Jul 20, 2011 at 13:25

I think they should have a solid grasp of the basics, just as a front-end developer should have a solid grasp of the basics of UX.

That isn't to say it's necessary for them to be able to sit down and code up the whole interface, but they should be able to converse with developers in their own language (and vice-versa), and possibly pair-program with a developer who is having some trouble getting something to work as designed.


Technically, UX is a form of Design. In Front end software, you can have multiple specializations: designer, developer, and architect. UX typically sits in the "designer" category with an emphasis on conceptual drawings, workflow diagrams, and other "high-level" creatives.

Architects and Developers leverage these, along with other design assets, to produce the application.

Software development is largely dictated by environments. In other words, you can only design what the browser or device is capable of. It is EXTREMELY helpful if the UX designer is familiar with the technical constraints of CSS3, for example, so on the one hand he will push for cool stuff that CSS3 can do, but on the other hand is aware of and will work around things that CSS3 can't.

It's been my experience that the best designers can code their designs, and vice-versa: the best coders have amazing sense for design.

While it is possible to have UX people who can't do a lick of code, I would argue against it. Look for people who can build what they dream up - or at least know how to build it.


There are two angles:

  1. If you work for an organization where you are required to wear multiple hats, the ability to code while engaging in standard UX tasks may indeed be relevant.
  2. As one that has practiced UX full-time since 2005, I have never been required or asked to code. The companies were all well-structured and well-established in their respective business categories. There were always people on-hand who had the responsibility of coding, so it was never a point of focus of concern for me. Also, those same individuals provides insights about constraints associated with code. There was no need for me to possess such first-hand knowledge.

In short, considering that true UX is comprised of one or more methods, disciplines, and deliverables from usability and heuristics, information architecture, interaction and interface design, and/or UX research, a person truly engaging in UX won't have time to code. Again, working at a company such as a start-up may require you to get your hands dirty. Coding is not, however, a main core element associated with true UX practice.


It all depends on the context of the organization, the type and cycle of the project, as well as other factors.

In my opinion: Yes ,designers who can't code will say that this knowledge is unnecessary, while the market will verify itself.

Technologies, frameworks and libraries are developing so fast that the boundary between design and coding is disappearing.

However, if we separate the fields of design and front-end programming, we can see the detailed components (animations in UI or unit tests in the frontend).

So in this context a lot depends on the current needs and scopes that the project supports or should support.

Elementary knowledge of front-end is necessary, I would go a step further and give designers access to repositories on the git, because designing takes considerably less time than coding.

The monthly project can be implemented up to half a year (depending on the complexity)

So when the system is already designed and ready for programming, the designer could at this time take care of real programming support (even in terms of aesthetics, not to mention communication with the API) instead of generating unnecessary shots on dribbble portals.

Much depends on the life cycle of the product (I mean, when the project is already mature, the task of UX is to verify / test hypotheses with users, so in this phase, when the system is already functioning programming or creating architectures is no longer as needed as at the beginning.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.