How much should a UX professional know about front-end development?

Question

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.

Answer 1

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

Answer 2

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.

Answer 3

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.

Answer 4

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

Answer 5

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. ;)

Answer 6

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.

Answer 7

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.

Answer 8

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.

Answer 9

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.

Answer 10

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.

Answer 11

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.

Answer 12

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.

Answer 13

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.