Do user experience practitioners ever have to worry about code?

Question

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]?

Answer 1

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.

Answer 2

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.

Answer 3

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

Answer 4

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

But...

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.

Answer 5

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.

Answer 6

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.

ADDENDUM:

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.

Answer 7

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.

Answer 8

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.

Answer 9

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.

Answer 10

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.

EDIT:
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.

Answer 11

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.