Take the 2-minute tour ×

To me this is a simple question – of course not. But on several questions and answers lately I need to fight for this opinion. I might be wrong, so I need to know. Do user experience practitioners ever have to worry about the implementation of design choices [i.e. code]?

share|improve this question
Looking at it from the other side, as a programmer, it's really hard for a developer to talk to a ux/graphics person who cannot comprehend the limitations of what can and cannot be done with code. –  Alex Stone Nov 28 '12 at 20:33
@AlexStone I could agree on that, but we work in an environment without properites, and therefore anything is possible. Things that were impossible yesterday are possible today. However, and this important, there might be a business decision involved saying this is too expesive and therefore we need to think different. But worry on code to begin with? I disagree but respect your point of view (and will soon be severly punished for this comment). –  Benny Skogberg Nov 28 '12 at 20:42
The better the understanding of code and development concepts, the better the perspective with which to craft a strong user experience. –  DesignerGuy Nov 29 '12 at 0:57
Someone needs to tell me where all these jobs where I don't have to code and can just focus on "pure" UX are. I haven't found one yet! –  Rachel Keslensky Nov 29 '12 at 1:49
Does an architect have to worry about engineering? Ideally, they do. –  DA01 Nov 29 '12 at 17:59
add comment

11 Answers

up vote 51 down vote accepted

I think the process of producing software is much more efficient if the designers (or those that contribute to the design) have a strong technical understanding of the medium. For instance, in designing a website it helps to understand what can be achieved via CSS because if you design things that can't be expressed with CSS and require images instead (or maybe some JavaScript), this can have ramifications in development time, page load time, and different looks across different devices.

Theoretically a UX practitioner needn't understand the technology behind the medium, and given enough time and money and good developers could make the design happen, but that's not an optimal way to operate.

A UX practitioner, for the sake of an efficient process, needs the strong technical understanding of the medium, and given that, he/she would likely understand some of the languages involved. A UXer needn't necessarily be an expert in these languages, but more he/she understands the better.

share|improve this answer
I like your point of view. And it is very relevant and makes me wonder if there is a cost/benefit graph that one could lean toward when designing. The more benefit (to users) the more its allowed to cost (in developer hours) to implement. Nice answer! +1 –  Benny Skogberg Nov 28 '12 at 20:50
I always thought understanding the medium was important. I remember when the web first started catching on and there were programmers on one side doing stuff and print graphics people on the other side doing stuff, and neither side really understood the medium! –  obelia Nov 28 '12 at 21:23
In the aircraft design world, the old theory used to be let the design team dream it, then pass it off to some engineers who had to figure out the nuts and bolts to make it happen, then hand it off to the guys building it to work out the tooling. It usually meant many trips back down the chain when one group realized it wasn't feasible. The new school puts them all at the same table which saves a lot of headaches and reworking of designs. The same could be said here: put the dreamers and implementers together at the same table to work out the product. Each side will learn from the other. –  tpg2114 Nov 28 '12 at 21:59
The flip-side of that is all the opportunities lost due to assumptions about what ISN'T possible. I've seen that in waterfall work environments. –  Erik Reppen Nov 29 '12 at 4:32
As Erik Reppen comments, it is a flip side that the UX designer might think something is not possible based on some basic coding knowledge, while a good programmer see possibilities to implement a better design. It is better to do as tpg2114 say; let the designers and programmers work together, so the designers can create a stunning design, and the programmers can give live feedback on how this is feasible or not. See this answer for more depth. –  awe Nov 29 '12 at 13:13
show 2 more comments

Of course we have to!

Well, maybe not technically understanding or knowing the actual syntax of the implementation of a feature, but we should understand and be aware of how much effort goes into implementing certain features, ie. how expensive they are. Good UX doesn't come cheap all the time concerning the time it takes to realize the design.

UX people are in my meaning usually part of the driving force that makes key decisions on what route a product should take. The UX teams come with ideas, which are designed with ID's, IA's, GD's, and later realized by the dev team.

If the UX people keep coming with solutions that clogs up the dev team then the production will stagger.

A UX person should therefore have some idea of what is practically doable in a dev point of view, but not necessarily know how to implement the designs.

share|improve this answer
+1 On this I can agree! It really is a business desicion on how much time (= how expensive) a solution really is that makes the point. Not the implementation code itself. Thanx @AndroidHustle –  Benny Skogberg Nov 28 '12 at 20:44
@BennySkogberg Thank you too Benny! :-) –  AndroidHustle Nov 28 '12 at 22:33
add comment

An anecdotal perspective ...

On a couple of occasions, I've worked with supposed 'UX Experts' that know nothing of the implementation. In those cases my role was primarily as Creative Director but I found myself progressively taking on the UX role. The reason being, the expert didn't have the breadth of knowledge to push the experience beyond copy cat patchwork. The problem became evident over time and my role concomitantly expanded.

With apps and sites you have to understand what can be done in order to provide complete direction. You don't have to code it (as others have said) but you definitely have to be able to push the dev team a bit. Otherwise, they'll just say "it can't be done" ;)

share|improve this answer
Fair points, but (just playing devils advocate here) would you knowing what can be done limit what ideas you come up with? If you know the limits it's harder to think past them. –  JonW Nov 28 '12 at 22:20
That's the key to being a good UX advisor: Know the tech enough to push the limits but maintain the ability think like a human not a machine. That's why you need separate roles for UI/UX and development. –  plainclothes Nov 28 '12 at 22:47
@JonW, counter to that point, if you know the limits, you can come up with creative solutions to get around them. If you pretend that there aren't limits then you're ignoring reality, if you abide by the limits then you're stuck at status quo. –  zzzzBov Nov 29 '12 at 0:03
"That's why you need separate roles for UI/UX and development" I disagree. I think. The individuals can be different people (or the same) but they very much have to both be encompassed under the same UX umbrella. In the end, the UX the user has is very much related to the UI that is built. –  DA01 Nov 29 '12 at 18:16
@plainclothes why do you feel they need to be distinct? I'd say the skillsets need to exist within the process, but they don't necessarily need to belong to separate people, IMHO. –  DA01 Nov 29 '12 at 21:14
show 4 more comments

The short answer is no, having no knowledge of code won't prevent you from making a career out of UX.


Having a good working knowledge of how things can be implemented, what is possible, what isn't, will always help. Understanding the technical processes on a basic level can prove tremendously beneficial when it comes to conveying your ideas to the development team. Development teams famously won't like the idea of changing something they deem to work perfectly well as it is, they'd rather be working on that much bigger project, it's your job to convince them and push things through. Having a basic level of technical knowledge can add a lot of weight to your argument.

All I can say is, it has helped me a great deal.

share|improve this answer
+1 I like the oposite stance "won't prevent you from making a career out of UX". Good one! –  Benny Skogberg Nov 28 '12 at 20:52
add comment

It depends on your slant. I've know UX people who focus on research or IA and don't get involvted with UI or prototyping, but I also know some (like me) that are 100% fluent in HTML and CSS (or Less, compass, sass, etc etc) and a bit of jQuery and coffeescript that helps prototype and provide things to developers to help get the message across. But I also provide pixel-perfect mockups as well.

Really, UX should have a deemphasis on code obviously. Or at least just stick to HTML and CSS. But if you know how to leverage things like the Bootstrap css boilerplate and Less.css and such, it really can help get the point across.

If you're talking production implementation of code that is pushed live - no. Front End Developers or Backend Engineers need to write and maintain that code. Problem is - they can't always be relied on for the HTML part since they may not really focus on the implementation of layout and UI design.

But I agree - other than fiddling with jQuery and coffeescript for rapid prototyping, it's probably not a UX requirement that you actually write production code.

share|improve this answer
+1 for "they can't always be relied on for the HTML part", I've seen this too often. You got a great point there! –  Benny Skogberg Nov 28 '12 at 21:13
Uh... focusing on implementation of UI and layout design pretty much describes "front end developer." Try bringing them into design discussions. You might find they give more of a damn about the designs if they actually have some input at the initial conceptualization phase. You might also be surprised at how much they actually care. –  Erik Reppen Nov 29 '12 at 5:10
@ErikReppen is correct, though it's important to note that a lot of dev teams don't even have front-end dev experience beyond what their code framework's WYSIWYG IDE produces. Ideally, the UX team is the front end dev team (be it formally or informally, but I agree that the front-end devs need to be a part of the UX Process) –  DA01 Nov 29 '12 at 18:08
add comment

Does a painter have to worry about oils and canvases? Does a landscape architect have to worry about drainage, and soil conditions? Does a fashion designer have to worry about fabric weaves and stitching patterns?

Sometimes, no. They can simply be the aesthetic gurus. But most do. Like any craftsman, understanding the medium one is working is is part of the craft. A carpenter that understands wood grains is going to have a better finished product than one that doesn't.

How MUCH does one have to understand the medium in detail? Well, that all depends on a whole lot of factors.


In reading through all the answers, there seems to be two common POVs:

  1. UX users should understand the code so they can design what's practical
  2. UX designer's shouldn't understand the code so they aren't limited in any way.

I think both point of views can be accommodated by stating The UX Process needs to assist in developing the UI.

In other words, whether one knows code vs. doesn't isn't so much of an issue at the individual level as it is a the team level.

The team involved with producing the product's experience--namely the UI--does have to understand the code required to build the presentation layer.

So I think this becomes much less of an issue of individual skill sets and more of an issue about team structures and project development processes.

Agile seems to help with it. Regardless of the corporate org chart, an Agile process tends to force the larger team to constantly be in sync with each other. The person designing the wireframes has to constantly be in contact with the person designing the database tables.

Waterfall processes have a much more difficult time with this. In a waterfall process, those designing the UI have to design something ahead of time that is implementable. So in that situation, they either need to have code folks on the UX team, or they need to reach out and bring in the UI developers into the loop.

share|improve this answer
add comment

You could turn this question around. "Should a good developer know about User Experience?". I think many of us would answer a resounding yes. However equally you are not expected your colleagues to become an expert.

I think the truth is the more you work in development the more you understand something about the constraints of technical medium you are working with. However I think a valuable role is the one pointed out above sometimes questioning the status quo is a useful step in taking it beyond those constraints.

Much of this relationship has to do with respect for each others perspective and an openness to learn new things.

share|improve this answer
add comment

First of all: GREAT question!

To me the question isn't "should a UX professional KNOW how to code."

The question that was asked is: "should a UX professional THINK about code".

For me, the former is no. The latter is a resounding YES!

I recently read about the concept of "I" shaped people--in contrast to "T" shaped people. This really is the crux of my point:

This idea ["I" shaped] was crystallized in my mind thanks to another Englishman, one of the early pioneers of human-centered design, Brian Shackel. I once asked him if he had noticed any particular attributes that distinguished the students that went on to do remarkable things compared with the rest. His answer was as immediate as it was insightful.

He said: "The outstanding students all had an outstanding capacity for abstract thinking, yet they also had a really strong grounding in physical materials and tools." By this, he meant that they could rise above the specifics of a particular problem to think about them in a more abstract, and in some ways, more general way. Getting Their Hands DirtyAt the same time, as they were growing up, all had been deeply involved in things such as fixing bicycles or cars.

In fact, it didn't matter how this was manifest. What was important that they had a "can do" and "have done" competence in some aspect of the messy, dirty, and fascinating world of physical materials and tools. In short, they were firmly grounded in reality.

If one were to take the position of "I live in an abstract world and if I can think it, my work is done", then you are not being a collaborative partner with your developers.

To "worry" about code is to open the door for finding new ways to solve existing problems both in design and implementation. To not "worry" is to draw a line and say "outside of my sandbox, it's not my problem" which isn't going to do much good for anyone.

A good design is not an abstraction, it is a living/working thing that a user interacts with. Knowing how your design decisions might relate to implementation (code) allows you to moderate your abstract design, and creates an open channel that encourages developers to engage and try to work creatively to find the best solution.

If your abstract design comes back from dev because of a problem in implementation, being able to understand the developer's language and relate to their needs is going to be critical to getting the revised design right.

Taking a look at the same question from the opposite end of the equation, do UX practitioners find developers who lack basic UX concepts and say they dont have to "worry" about it are easy to work with? If they focus solely on code without any awareness or intellectual curiosity about "why" their code needs to be written in the first place, does that make you as a UX professional feel respected? Do you look forward to working on a project with that developer?

For me personally, I like to extend the user centered design tenet of empathy to encompass not only the end user, but all users of the design, which includes those who must implement them. As a result, I worry about code.

Edited to add a practical example: The Art and Practice of Content Assembly: Where IA and CMS Meet

There’s a murky space where Information Architecture and Content Management meet. This is a God-forsaken back alley where dirty deals are negotiated and where idealism and purity go to die. This is the place were your wireframes are sacrificed on the altar of your CMS.

The most common cause of death? Managing content assembly, which is the seemingly simple concept of getting multiple items of content into a group

As I mentioned above, your design is a conversation between you and a dev. This is what the dev thinks:

Wireframes are great for this – “we’re going to have this menu here, and these links here, and some related content over here…” etc. Information Architects just go crazy with this stuff, and they really should because that’s their job.

Sadly, my job is to make all that stuff work. When I see any listing of content in any form on a wireframe, I’m automatically thinking “how am I going to get that content to appear in that spot within the capabilities of this CMS?”

Depending on your platform, there are different "ways" in which that platform structures content. Being aware of that implementation should inform design. Your design can actually become better if you are aware of what will and wont work well in the implementation. What might be a less "pure" design might be a more effective (read: "better") design if it avoids a particular weakness in the ability of the platform to implement. It's one of the intangibles that are inevitably a function of a well received design.

share|improve this answer
add comment

I believe that the best UX guys have experience in implementation, i.e. the coding side as well as UX. This allows them to understand what the limitations are of the web browser, server-side language, JavaScript library etc.

share|improve this answer
But it also limits them to what they know is possible. If all you have is a hammer everything looks like a nail. –  Stewart Dean Apr 24 '13 at 10:25
add comment

I think it is more important that the UX designers don't get held back by limitations they think are there, but might be fully possible to implement. In HTML5/CSS3 there are very few limitations, and almost anything is possible.

I am currently working on a pilot project where there are 2 UX people designing the look and feel, and I am working with another programmer to implement it in HTML/CSS. There are some things that can seem complicated to do, but really isn't, and other things that can seem easy that is actually a bit tricky to implement because of some CSS issues.

My experience here is that the best is to let the UX people design the look, and leave the "how to implement" to the programmers that knows how to do it. I actually find it stimulating to get good looking design and try to implement it. It is a good feeling that what I implement looks good, instead of having a boring "easy to implement" look that is result of something the designer thinks is easy to implement based on basic html/css knowledge. I love to work with people that is very good at user experience and graphic design, so I can implement something that looks good.

There is also the possibility to give feedback to the designers that a particular thing they request would be technically difficult to achieve. Then make a decision how important that design feature really is and make a decision if it is necessary to invest the time and effort it takes to implement it.

share|improve this answer
This is a common viewpoint, and won't necessarily say it's wrong. That said, to counter it, it's not about 'limitations' but rather it's about understanding the medium one is working in. I've been on both sides and, as when on the developer side, have had to build very specific UX 'wants' that are really impractical compared to an equally suitable alternative implementation. I find UX teams that have little to no understanding of the actual medium can produce designs that are very inefficient to implement. –  DA01 Nov 29 '12 at 18:05
And...actually, when on the UX side, being able to produce presentation layer code, I can often help developers exceed their typical limitations. So, IMHO, a UX team that has some presentation layer dev skills is only a good thing--not a limitation. –  DA01 Nov 29 '12 at 18:06
I strongly disagree with "In HTML5/CSS3 there are very few limitations". There are many cases of applications originally attempted in HTML5 that ran into limitations and a switch to other technologies was required to succeed. There are many free native apps (e.g. Facebook app) that were built because of the limitations of web technology. –  obelia Nov 29 '12 at 18:19
add comment

The answer is a good UX practitioner COULD code but DOES NOT on a project.

If you code during a project then it WILL alter the outcome. There is a difference between the ENGINEER mindset and the ARCHITECT mindset.

If given a choice between a solution that is good for users that is difficult to implement and something that is easy to implement that is okay for the user then an engineer will pick the second. An architect will pick the first.

The engineering mindset is engaged if you are involved with implementation. That includes Coding AND detailed Visual Design.

In short if you do code and create visual design on a project then you can produce something that works and is okay. If you want good rather than okay then the UX practitioner must NOT Code or Design on a project but be the UX Architect.

For more about this read About Face by Alan Cooper.

share|improve this answer
add comment

Your Answer


