"UX designer" is a bit of an ambiguous phrase, and it gets the correct amount of sarcastic scorn for being a buzzword.
But I think it means something more important: as you say, good UX requires a recognition that everything that goes into your application contributes to the experience. Software design, copy, marketing, UI, etc. etc. Everything. We all know this and understand this.
What UX is, then, is software quality systems engineering. "Everything that goes into the experience" is no longer simply visual design or UI components, but a complex web of inputs and influences to manage in order to ensure quality. A good UI designer has one piece of that puzzle and ensures the visuals and interactions are spot on, but a good UX designer takes all that and more into account and extends their influence to many other areas outside the visual. It's not their job to do all the work, but it is their job to manage the systems in place to ensure the experience is high quality.
Software is getting more complex and more interesting. The "UX designer" moniker is just a response to that; a recognition that UI designers are becoming more holistic and with wider reach. They are becoming quality management systems engineers. This requires more than just UI design, though most UI designers probably naturally have the skills and knowledge to make it happen.
It's a positive development IMHO. You may not like the broad nebulous term UX, but I think if we think of it more as systems design, maybe we can start to pin it down and make it a useful job title.
I see strong parallels between UX designer and game designer. It was not until more recently that it has become generally accepted that everything from time killing mobile games to enterprise software demands good UX. Decades ago game designers figured out that a good UX meant a larger player base and ultimately more sales -- rather than contracts and inescapable legacy lock ins.
UX is about creating a clear, intuitive experience for the user (the front and back end work that makes that possible.) This is done through consistency of patterns, both unique to the application and drawn on existing and historical work (also makes for a good argument against software patents, but that is another issue.) At the very least, this requires some one or a group of people to create an agreed upon design document from the start.
Steve Jobs view of the liberal arts goes a long way in explaining UX. Everything matters. That hardly means every single team member should be an omniscient visionary with hundreds of niche interests.
Another problem with people conflating "UX Designer" with "UI Designer" is that if you put "UX" in a job title hoping to get "UI" folks, you will get the wrong people. I have seen this first-hand now with two companies: the job title was set by someone who didn't really understand the difference and instead of getting qualified visual/interface designers applying for the role we got people who draw boxes and arrows, extremely low-fidelity wireframes, and user researchers. Not people who cranked hard on the actual product, but people who did a lot of "meta" work that only affected the product in passing.
In larger companies there may be a need for "UX" designers like that, but at small companies when people all need to wear multiple hats, you don't just want a wireframer or flow diagrammer... you want a designer who can think about the overall experience, then design it, then create the actual pixels, then hopefully write some front-end code as well. I have yet to meet anyone who considers themselves a "UX Designer" to be able to do any of that.
You mean, you got real designers when what you really wanted were production art technicians? Sounds even worse than that: you got interaction designers when you might have been happy with visual designers.
Most good designers don't have time to write code, but some bad/mediocre ones are ok at with it as they are less specialized. It's rare that designers would even have time to write code even if they could or wanted to; usually developers are blocked on them, not vice versa.
So what you want is an interaction+visual designer who can also do production and on top of that can write code. And you probably want them also to be good. Your company is screwed.
The best designers I have worked with write code or wrote code at one point in their career. It is difficult working in a medium you do not understand.
The worst designers I've worked with were the ones who knew how to write code and picked up illustrator by playing with CS...hey look I can draw! Really, the training and practice that goes into a good designer is huge, if they also learn writing code, something has to give. Visual designers are much more difficult in this regard than interaction designers, who are often just former programmers anyways (though the best ones I've worked with schooled as...architects).
I've worked with really truly horrible designers who started as coders.
But the worst UI designer I ever worked with knew how to draw pretty pictures and utterly refused to view the web as a separate media from print. Technical constraints were utterly ignored as were, frankly, a number of business constraints (Which is what really got him in trouble). A total failure.
Knowing the stuff that goes on around your UI is actually an asset. And knowing the tech deeply enough to code it is of immense value. Of course you still have to be good at your core craft.
If you are a front end programmer, do you think knowing how to sketch and design grids helps you implement good designs? Perhaps, but can you actually hire those people and have them be the best programmers at the same time? Much harder. Why would you expect from designers what you don't expect from designers? Keep in mind that good designers are as hard, if not harder, to hire than good programmers.
Designers do understand the domains they are working in, otherwise they aren't very good. The developers are not that far away, so there is interaction if the spec goes somewhere where they can't (hardware constraints for phone UI, for example). On the other hand, knowing how to program would help a designer check the dev's bullsh*t that something can't be implemented, and they are just being lazy or toxic.
The reason I expect a good designer know something about the media they are working in is because this is been very traditionally part of the job. Designers have been expected know what inks can and can't be reproduced on which materials. Or which printing process will be most economical etc.
As you point out only the truly bad ones don’t know the baseline capabilities of their platform be it app or web design...
But for as for the good ones, that do know their media, - well, I don't find it odd that some would find the best way that they could learn the constraints of their media was to play around with HTML and CSS directly (or Interface Builder). And I do think that people who have of done that are actually a bigger asset that's than people who have just read up. I assume this is because they have a more visceral feel for the costs of their designs.
This does not mean that I expect my designers to code, or do production work. It just means that those designers who are capable of hacking out a toy system seem to be more capable of designing things that implement easily. And that saves me money.
I see where our disconnect is: I haven't worked with web designers, rather designers for much more technical software products where the coding tasks are much more involved. So I would also expect a web designer to play around with HTML/CSS, but then that is completely irrelevant when we are building a computer vision product, or a toolkit to support the app platform of a mobile phone. The designers might use HTML/CSS as a prototyping tool, but there are other better suited tools out there since...none of them are close to production reality anyways. There even some domains, like NUI, where separate prototyping roles are required because traditional design tools aren't good enough.
So ya, given simple web/phone apps where HTML/CSS or interface builder are relevant, you could expect designers to be more involved with tweaking production assets directly. But I've never worked on those applications before, and the technical barriers for what I have worked on are quite high; expecting the designer to participate in modifying code assets is a bit crazy!
What is special about programming that hinders a designer's skill development so much? It seems like you could just as easily say that learning how to play golf could have the same effect. There is, after all, only so much time in the day – something has to give, but the sentiment, which many people seem to share, only seems to be directed at programming specifically.
The reason for the (false) stereotype is that programmers so often have one-track specialized minds, due to many factors. But it's false: with a little effort and an education that doesn't mould people into code monkeys, programmers can branch out.
As well they should: the greatest value programmers can offer is if they use their programming skill to improve other areas of their company or solve problems in a domain outside programming itself. It is an exponential sort of value increase. We need more programmer generalists, and we need to encourage and embrace them.
Jack of all trades, master of none? Generalists are great at impoverished startups where workers have to wear many hats, they don't work so well on larger projects with larger staffs where special skills become more appreciated. Being a generalist is usually a quick ticket to a PhB role.
"if they also learn writing code, something has to give"
Disagree. This is a false limit, and a false criticism rooted in ignorance and lack of experience. I don't know what else to say other than as a designer with a CS degree, I actually take offense to this statement. I know how much greater value I offer and would like other designers and programmers I work with to reach similar levels of integrated skill.
Specialization is for the industrial revolution—the technological age requires expert polymaths.
If it wasn't clear, CS in my previous post meant adobe creative studio, not computer science. I just realized these acronyms clash.
Designer have lots of skills, so much that even they have to specialize often along additional axises that might not even be obvious to us (motion or color design as a specialization of visual). We are happy to just get one who has promising design skills, and most of the designer+programmers I've interviewed just don't even come close, sorry.
How many programmers can draw? Is it a hiring requirement?
You seem pretty intent on drawing a negative picture of people who can do both design and code, labeling them the worst designers you've ever worked with or a jack of all trades whose ultimate route is some idiot manager role.
There's nothing but benefit for a designer to also pick up some coding skills or a developer gaining an appreciation of design and interaction. And I see no reason someone can't excel at both if they truly desire.
Perhaps the worst designers you've worked with did both, but don't let bad logic lead you to think that the best designers do not.
It takes 10,000 hours of practice to become a good programmer, it takes a similar amount of practice to become a good designer. Yes, if the person spends 20,000 hours, they might be able to do both well. If the designer just learns some action script and never practices, then they aren't really learning to program.
I guess you guys live in a hiring environment where good designer/programmers are easy to hire. For us, just getting good designers, or good programmers, is hard enough. The ones who claim to do both are not good enough at either to make it worth our time. We also suffer from a shortage of good designers compared to good programmers, so dev is always blocked on design and even if designers could code, they would never be given time to do so, they just so many other things to do! After a few years, their programming skills would become stale, and it would just be a waste. You sort of have to practice continuously to keep your skills up.
> "meta" work that only affected the product in passing
UX is basically a continuation of the project manager role (depending on what a given shop interprets that as). It is meant to steer the entire product design (and I don't mean PSD files) from the ground up, so it's not really "in passing".
Also, most UX people I know do have a decent skill at PS, so I guess they are listening to that concern.
Well put. The user experience is everyone's responsibility. I've seen a number of teams that let the 'UX Specialist' dictate the entire UI. Usually research that does not account for cognitive bias is done in place of testing. Effectively you are basing the entire UI on the opinion of one person. That is always a bad idea.
News flash: titles are useless. what does a "CEO" do at a five person startup. You can call them anything you want, but someone needs to be responsible for owning a design process.
He said "Stop quibbling" meaning do not quibble(Argue or raise objections about a trivial matter). Not over semantics, not over syntax. Have meaningful debate and discussion.
UX is quite simply put "the elimination of frustration"
Do you know who is responsible for creating a good user experience?EVERYONE ON YOUR TEAM. EVERYONE.
I understand the sentiment that the OP is trying to bring, but this statement is akin to stating something like "everyone is responsible for the commercial success of the business".
The role of a UX designer (or perhaps a UX Lead in this case) is to take on the responsibility of ensuring that frustrations of the customer are eliminating by all means possible. The problem is that not everyone in your organization - no matter how big or small - has the time to be able to empathize with your customers. So it's slightly disingenuous to assume that everyone bear that responsibility. It's the UX Lead/Designer's responsible to engage with the customer and feed that back in a meaningful way to the people responsible for actually cutting the code that renders the experience.
I agree and disagree, only in the sense that - everything impacts a user's experience. The entire team should have that on their mind to a varying degree.
I like this explanation. Often you read articles about self proclaimed UX experts talking about their research and thinking about the product is what makes a product have a good UX.
Nope, its the iterative process. Good UX people, Good developers, and short iterative cycles. Not just market research. A good UX guy listens to the developer too.
I don't care much about the terms, but my general test is this: would this person be useful on a small team?
A software "architect" who can't be a developer wouldn't be useful on a small team. A "UX" designer who can't create mock ups, wireframes, or actual code (certainly CSS/HTML, let's hope for javascript) wouldn't be useful on a small team.
I have trouble believing that people who wouldn't be useful on a small team would be useful on a large team.
Reading this made me wonder if the author really has a good understanding of what's going on in the UX field. Maybe he's run into a few people calling themselves UX designers and then generalizing from a small sample into the entire field? I don't know. Here's some things that I wish everyone understood:
1. UX designers aren't solely in charge of the user experience - Yes, UX designers have been saying that from day one. UX is about breaking down organizational barriers and facilitating collaboration across disciplines. That's fundamental to the concept, because looking at a product from a user's perspective, you don't see organizational divisions, internal politics, fiefdoms dominated by specific disciplines and so on. Users experience a product in a holistic way, but organizations are fragmented into specializations. Poor UX is often the result of organizations optimizing for the efficiency of division of labor without understanding the tradeoff for the end user. That's a fundamental mismatch that UX tries to remedy.
2. UX designers didn't take ownership away from anyone. When the discipline was first emerging, very few people cared. Over the last 15 years, the trend has been UX designers saying things like "How do I get my developers to care about the user's experience?" Now UX is starting to become strategically important, and (some, not all) developers realize that they're getting left behind. That's not UX designers doing it to you, that's a self-inflicted wound. I started as a developer 10 years ago, but quickly realized that UX was the future, and made the switch. UX designers have been banging the drum for 15 years trying to get everyone working together. A lot of developers are only now starting to wake up and realize they need to be involved, but find themselves at a 10-15 year disadvantage. Others stepped up and took ownership over something that no one else cared about and today they have experience, knowledge, skills and a track record in a strategically important area. Sorry about that. We tried to tell you.
3. Elliot comes off pretty naive when he talks about iteration. That's a pretty new idea in software, which has historically been dominated by a requirements-oriented traditional engineering mindset. As a result, some developers talk about iteration like they invented it, but other product design disciplines - architecture, graphic design, film, fashion, industrial design - have been doing iteration for many decades, probably even centuries. You know how designers talk about mockups? Here's the wikipedia definition of a mockup: http://en.wikipedia.org/wiki/Mockup
> "In manufacturing and design, a mockup, or mock-up, is a scale or full-size model of a design or device, used for teaching, demonstration, design evaluation, promotion, and other purposes. A mockup is a prototype if it provides at least part of the functionality of a system and enables testing of a design. Mock-ups are used by designers mainly to acquire feedback from users."
4. There are still many large barriers to developers participating in the UX process, but the important ones aren't about job titles. Here are some things developers need to deal with when getting involved in UX:
- Lack of career incentives - when you interview for your next job, are you going to be asked any questions about the UX of what you worked on? Is your performance at your current job evaluated in terms of your impact on UX? Do you hold yourself personally accountable for poor UX? If not, then like the chicken and pig fable, you're involved but not committed. It's one thing to say that everyone is responsible for a good UX. It's another to actually hold people (or yourself) responsible.
- Lack of empathy - you're building a product for someone else to use. If you privilege your own preferences and way of working, if you lack the flexib...
I have a feeling you over analyzed what I wrote. I wasn't saying UX isn't important - my job title is literally a UX engineer. The company I work with prides itself on the user experience coming first. So while it may be something I defend first, its something on everyone's mind - and when it isn't it can become a problem.
Steve Jobs for example cared about every little detail that impacted the user experience. He also wanted everyone in his company to care in the same way.
My point is just that while UX designers may be leading the charge, they largely need to get off any "high horse" they're on, and understand an entire team is responsible for a good experience, even if they are the driving force.
Getting whole teams involved in the process has been standard practice for UX designers for over a decade. For the most part, the problem has been getting non-UX folks to care at all.
What you describe sounds like a scenario where everyone wants to participate, but for some reason the UX designer refuses to collaborate? I've never heard of that happening, and it runs counter to my personal experience and pretty much every UX designer I've ever talked to, so my gut feeling is that you're reacting to a unique situation.
32 comments
[ 3.2 ms ] story [ 64.7 ms ] threadBut I think it means something more important: as you say, good UX requires a recognition that everything that goes into your application contributes to the experience. Software design, copy, marketing, UI, etc. etc. Everything. We all know this and understand this.
What UX is, then, is software quality systems engineering. "Everything that goes into the experience" is no longer simply visual design or UI components, but a complex web of inputs and influences to manage in order to ensure quality. A good UI designer has one piece of that puzzle and ensures the visuals and interactions are spot on, but a good UX designer takes all that and more into account and extends their influence to many other areas outside the visual. It's not their job to do all the work, but it is their job to manage the systems in place to ensure the experience is high quality.
Software is getting more complex and more interesting. The "UX designer" moniker is just a response to that; a recognition that UI designers are becoming more holistic and with wider reach. They are becoming quality management systems engineers. This requires more than just UI design, though most UI designers probably naturally have the skills and knowledge to make it happen.
It's a positive development IMHO. You may not like the broad nebulous term UX, but I think if we think of it more as systems design, maybe we can start to pin it down and make it a useful job title.
UX is about creating a clear, intuitive experience for the user (the front and back end work that makes that possible.) This is done through consistency of patterns, both unique to the application and drawn on existing and historical work (also makes for a good argument against software patents, but that is another issue.) At the very least, this requires some one or a group of people to create an agreed upon design document from the start.
Steve Jobs view of the liberal arts goes a long way in explaining UX. Everything matters. That hardly means every single team member should be an omniscient visionary with hundreds of niche interests.
In larger companies there may be a need for "UX" designers like that, but at small companies when people all need to wear multiple hats, you don't just want a wireframer or flow diagrammer... you want a designer who can think about the overall experience, then design it, then create the actual pixels, then hopefully write some front-end code as well. I have yet to meet anyone who considers themselves a "UX Designer" to be able to do any of that.
Most good designers don't have time to write code, but some bad/mediocre ones are ok at with it as they are less specialized. It's rare that designers would even have time to write code even if they could or wanted to; usually developers are blocked on them, not vice versa.
So what you want is an interaction+visual designer who can also do production and on top of that can write code. And you probably want them also to be good. Your company is screwed.
But the worst UI designer I ever worked with knew how to draw pretty pictures and utterly refused to view the web as a separate media from print. Technical constraints were utterly ignored as were, frankly, a number of business constraints (Which is what really got him in trouble). A total failure.
Knowing the stuff that goes on around your UI is actually an asset. And knowing the tech deeply enough to code it is of immense value. Of course you still have to be good at your core craft.
Designers do understand the domains they are working in, otherwise they aren't very good. The developers are not that far away, so there is interaction if the spec goes somewhere where they can't (hardware constraints for phone UI, for example). On the other hand, knowing how to program would help a designer check the dev's bullsh*t that something can't be implemented, and they are just being lazy or toxic.
The reason I expect a good designer know something about the media they are working in is because this is been very traditionally part of the job. Designers have been expected know what inks can and can't be reproduced on which materials. Or which printing process will be most economical etc.
As you point out only the truly bad ones don’t know the baseline capabilities of their platform be it app or web design...
But for as for the good ones, that do know their media, - well, I don't find it odd that some would find the best way that they could learn the constraints of their media was to play around with HTML and CSS directly (or Interface Builder). And I do think that people who have of done that are actually a bigger asset that's than people who have just read up. I assume this is because they have a more visceral feel for the costs of their designs.
This does not mean that I expect my designers to code, or do production work. It just means that those designers who are capable of hacking out a toy system seem to be more capable of designing things that implement easily. And that saves me money.
So ya, given simple web/phone apps where HTML/CSS or interface builder are relevant, you could expect designers to be more involved with tweaking production assets directly. But I've never worked on those applications before, and the technical barriers for what I have worked on are quite high; expecting the designer to participate in modifying code assets is a bit crazy!
As well they should: the greatest value programmers can offer is if they use their programming skill to improve other areas of their company or solve problems in a domain outside programming itself. It is an exponential sort of value increase. We need more programmer generalists, and we need to encourage and embrace them.
Disagree. This is a false limit, and a false criticism rooted in ignorance and lack of experience. I don't know what else to say other than as a designer with a CS degree, I actually take offense to this statement. I know how much greater value I offer and would like other designers and programmers I work with to reach similar levels of integrated skill.
Specialization is for the industrial revolution—the technological age requires expert polymaths.
Designer have lots of skills, so much that even they have to specialize often along additional axises that might not even be obvious to us (motion or color design as a specialization of visual). We are happy to just get one who has promising design skills, and most of the designer+programmers I've interviewed just don't even come close, sorry.
How many programmers can draw? Is it a hiring requirement?
There's nothing but benefit for a designer to also pick up some coding skills or a developer gaining an appreciation of design and interaction. And I see no reason someone can't excel at both if they truly desire.
Perhaps the worst designers you've worked with did both, but don't let bad logic lead you to think that the best designers do not.
I guess you guys live in a hiring environment where good designer/programmers are easy to hire. For us, just getting good designers, or good programmers, is hard enough. The ones who claim to do both are not good enough at either to make it worth our time. We also suffer from a shortage of good designers compared to good programmers, so dev is always blocked on design and even if designers could code, they would never be given time to do so, they just so many other things to do! After a few years, their programming skills would become stale, and it would just be a waste. You sort of have to practice continuously to keep your skills up.
UX is basically a continuation of the project manager role (depending on what a given shop interprets that as). It is meant to steer the entire product design (and I don't mean PSD files) from the ground up, so it's not really "in passing".
Also, most UX people I know do have a decent skill at PS, so I guess they are listening to that concern.
We don't need any more articles like these.
Do you know who is responsible for creating a good user experience?EVERYONE ON YOUR TEAM. EVERYONE.
I understand the sentiment that the OP is trying to bring, but this statement is akin to stating something like "everyone is responsible for the commercial success of the business".
The role of a UX designer (or perhaps a UX Lead in this case) is to take on the responsibility of ensuring that frustrations of the customer are eliminating by all means possible. The problem is that not everyone in your organization - no matter how big or small - has the time to be able to empathize with your customers. So it's slightly disingenuous to assume that everyone bear that responsibility. It's the UX Lead/Designer's responsible to engage with the customer and feed that back in a meaningful way to the people responsible for actually cutting the code that renders the experience.
Nope, its the iterative process. Good UX people, Good developers, and short iterative cycles. Not just market research. A good UX guy listens to the developer too.
A software "architect" who can't be a developer wouldn't be useful on a small team. A "UX" designer who can't create mock ups, wireframes, or actual code (certainly CSS/HTML, let's hope for javascript) wouldn't be useful on a small team.
I have trouble believing that people who wouldn't be useful on a small team would be useful on a large team.
An iOS developer who can design and knows how to blend colours and make smaller icons will basically outdo every UI/UX/YADAYADA designer everywhere.
Not to be confused with a graphic designer. That shit is actually difficult.
1. UX designers aren't solely in charge of the user experience - Yes, UX designers have been saying that from day one. UX is about breaking down organizational barriers and facilitating collaboration across disciplines. That's fundamental to the concept, because looking at a product from a user's perspective, you don't see organizational divisions, internal politics, fiefdoms dominated by specific disciplines and so on. Users experience a product in a holistic way, but organizations are fragmented into specializations. Poor UX is often the result of organizations optimizing for the efficiency of division of labor without understanding the tradeoff for the end user. That's a fundamental mismatch that UX tries to remedy.
2. UX designers didn't take ownership away from anyone. When the discipline was first emerging, very few people cared. Over the last 15 years, the trend has been UX designers saying things like "How do I get my developers to care about the user's experience?" Now UX is starting to become strategically important, and (some, not all) developers realize that they're getting left behind. That's not UX designers doing it to you, that's a self-inflicted wound. I started as a developer 10 years ago, but quickly realized that UX was the future, and made the switch. UX designers have been banging the drum for 15 years trying to get everyone working together. A lot of developers are only now starting to wake up and realize they need to be involved, but find themselves at a 10-15 year disadvantage. Others stepped up and took ownership over something that no one else cared about and today they have experience, knowledge, skills and a track record in a strategically important area. Sorry about that. We tried to tell you.
3. Elliot comes off pretty naive when he talks about iteration. That's a pretty new idea in software, which has historically been dominated by a requirements-oriented traditional engineering mindset. As a result, some developers talk about iteration like they invented it, but other product design disciplines - architecture, graphic design, film, fashion, industrial design - have been doing iteration for many decades, probably even centuries. You know how designers talk about mockups? Here's the wikipedia definition of a mockup: http://en.wikipedia.org/wiki/Mockup
> "In manufacturing and design, a mockup, or mock-up, is a scale or full-size model of a design or device, used for teaching, demonstration, design evaluation, promotion, and other purposes. A mockup is a prototype if it provides at least part of the functionality of a system and enables testing of a design. Mock-ups are used by designers mainly to acquire feedback from users."
4. There are still many large barriers to developers participating in the UX process, but the important ones aren't about job titles. Here are some things developers need to deal with when getting involved in UX:
- Lack of career incentives - when you interview for your next job, are you going to be asked any questions about the UX of what you worked on? Is your performance at your current job evaluated in terms of your impact on UX? Do you hold yourself personally accountable for poor UX? If not, then like the chicken and pig fable, you're involved but not committed. It's one thing to say that everyone is responsible for a good UX. It's another to actually hold people (or yourself) responsible.
- Lack of empathy - you're building a product for someone else to use. If you privilege your own preferences and way of working, if you lack the flexib...
Steve Jobs for example cared about every little detail that impacted the user experience. He also wanted everyone in his company to care in the same way.
My point is just that while UX designers may be leading the charge, they largely need to get off any "high horse" they're on, and understand an entire team is responsible for a good experience, even if they are the driving force.
What you describe sounds like a scenario where everyone wants to participate, but for some reason the UX designer refuses to collaborate? I've never heard of that happening, and it runs counter to my personal experience and pretty much every UX designer I've ever talked to, so my gut feeling is that you're reacting to a unique situation.