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]?
-
36Looking 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 StoneNov 28, 2012 at 20:33
-
1@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 SkogbergNov 28, 2012 at 20:42
-
3The better the understanding of code and development concepts, the better the perspective with which to craft a strong user experience.– Andy FlemingNov 29, 2012 at 0:57
-
5Someone 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!– Raye KeslenskyNov 29, 2012 at 1:49
-
3Does an architect have to worry about engineering? Ideally, they do.– DA01Nov 29, 2012 at 17:59
14 Answers
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.
-
1I 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 Nov 28, 2012 at 20:50
-
1I 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!– obeliaNov 28, 2012 at 21:23
-
22In 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.– tpg2114Nov 28, 2012 at 21:59
-
3The 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. Nov 29, 2012 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.– aweNov 29, 2012 at 13:13
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. Good UX doesn't come cheap. It takes time to realize the design.
UX people are 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 IxD'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.
-
1+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 Nov 28, 2012 at 20:44
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" ;)
-
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, 2012 at 22:20
-
3That'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. Nov 28, 2012 at 22:47
-
1@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.– zzzzBovNov 29, 2012 at 0:03
-
1"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.– DA01Nov 29, 2012 at 18:16
-
1@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.– DA01Nov 29, 2012 at 21:14
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.
-
2+1 I like the oposite stance "won't prevent you from making a career out of UX". Good one! Nov 28, 2012 at 20:52
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) and a bit of jQuery and coffeescript that helps prototype and provide things to developers to help get the message across. (I also provide pixel-perfect mockups as well.)
Really, UX should have a de-emphasis 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.
Other than fiddling with jQuery and coffeescript for rapid prototyping, it's probably not a UX requirement that you actually write production code.
-
+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! Nov 28, 2012 at 21:13
-
3Uh... 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. Nov 29, 2012 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)– DA01Nov 29, 2012 at 18:08
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:
- UX users should understand the code so they can design what's practical
- 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.
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.
You could turn this question around. "Should a good developer know about User Experience?". I think many of us would answer a resounding yes. In the same way as you do not expect your developer colleagues to become experts at UX you need not be an expert developer.
I think the truth is the more you work in development the more you understand something about the constraints of the 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.
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.
-
But it also limits them to what they know is possible. If all you have is a hammer everything looks like a nail. Apr 24, 2013 at 10:25
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.
-
1This 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.– DA01Nov 29, 2012 at 18:05
-
1And...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.– DA01Nov 29, 2012 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.– obeliaNov 29, 2012 at 18:19
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.
In a practical sense, it could be problematic to design something that can't be build (for technical or practical reasons). A good understanding of the front-end and back-end technologies (not necessarily from a code level of detail) will help prevent this from happening. A good communication process between the designer and developer will help too, and generally if this is the same person then it is less likely to be a problem.
For another look from the other side: As a programmer on a small team with no UX expert, I find it incredibly important to understand usability, hence my presence on this site. Understanding the code when I work on interface lets me decide quickly not just what's possible, but what's feasible, while understanding Usability allows me to come up with solutions that don't make the User say "huh?" It may not be necessary for a UX expert to understand code, or a programmer to know UX, but as team sizes shrink, it becomes more and more valuable and important.
-
I'm in the same boat as you - I'm also a programmer on a team with no titular UX expert, and as far as I'm concerned that makes me, as the question phrases it, a UX practitioner. I deal with code in the majority of my workday, but I'm the line of defense between my users and bad UX. May 23, 2014 at 19:09
-
1I find developers that have an affinity for UI work are, by default, good UX designers--whether they intended to be or not. :)– DA01May 24, 2014 at 18:52
It really does depend on the size of the team and organization, I would argue within a smaller development team it would be beneficial to have some knowledge of front end coding (HTML5/CSS3).
Not only does this align the rift between design and development, but being able to implement what you preach is beneficial from a scalability and a 'whats possible?' perspective. But being careful not to lose sight of your primary purposes: building beautiful, simple solutions.
This UX Masters article sums this up well, its not a core function of a UX designer, but certainly a 'nice to have'
Another factor to consider is the designers willingness to branch out and learn these languages..