One of my friends got an offer from his company to evolve his current position into a UX position. A while later, they have an actual project on which he could work as a UX designer. The only thing they ask is how fluent he is with a specific image editing software.
I joined a large company as a UI developer and got sent on a UX course due to this misconception. A happy accident I guess as it worked out the best for everyone.
I would say 95% of initial impression I've had is that I'm a "look and feel" person. Even after long, very specific conversations, it still comes out as "look and feel." And honestly, that's what most people care about since they can see it. As long as that doesn't impeded the work that goes behind it, I don't think that will change. You just need your boss, and bosses boss, and maybe an executive to understand what you're doing so you don't just look like a wasted headcount that should be doing JUST look and feel, but isn't.
So basically he is saying that some parts that have been traditionally considered a part of UI design are not a part of UI design but of UX and that is why UX and UI are different.
"Boohoo, nobody takes me seriously, they all think I just make pretty dialogs."
I know that feeling but I don't think coming up with more names and vague definitions that nobody knows is going to help.
Performance and Speed is UX. Something UI designers never really will understand. It's not just UX, but the only UX that's actually quite objective. No one ever goes "Oh gosh this app is too fast"
Another non developer talking about things that they can't implement.
I agree. That's one of those places where being in a UX role is way outside of UI design, and I'm taking the apps on-site with customers (I am mostly b2b) and observing and testing them as they use it. Recording their responses, as well as the applications. When logging in to the system takes 40 seconds because of database performance (or lack of), that's a UX insight that needs to be observed and reported. That's not something I can control but it has a huge impact on the user's experience.
There's an element of user-advocacy that I'm doing where I take the experience they are having and translate it back into business, design, and development goals as when someone is trying to use an enterprise piece of software and the experience is terrible, that is going to fall on designers, developers, PM's, and all the other people involved in the creation of the "thing" which becomes the user's experience.
That's another ambiguous situation. I go spend 2 days with users out at a company HQ, and I come back with tons of data that now has to be consumed by devs, designers, pm, marketers, executives, QA, customer service etc etc. The experience of what we build is a collection of every role in the entire company as far as the user is concerned, and all those various business roles need that UX information brought back. So at this point I'm so far from UI and visual design I'm closer to a PM or product owner now, but soon will be jumping back into the design an development realm to start to fix those experience problems.. unless the problems result in bad business drivers or invalid use-cases, so then I'm back at the PM and management table,
I still can't find a clear distinction about what I'm supposed to say I do. I just know that there is a certain disservice to just tell people "UI design, look and feel."
I have another set of people, the product designers, who will strongly disagree on your unqualified use of word "design", saying that design is the all encompassing use of a "thing" in a context. Largely being what you call UX.
My larger point is that the geeks of the web, in trying to come up with pointlessly precise definitions of what they do, rebase themselves from where they came from.
I totally agree with "trying to come up with pointlessly precise definitions of what they do"
what i am trying to say is, what makes product successful is not the interface design.
I don't care if your product looks so beautiful and lovely if i can not use it with bad bandwidth for example, or on my mobile.
I don't care how cool colours you use, if i need to click everywhere to find what i am looking for.
> "trying to come up with pointlessly precise definitions of what they do"
A few years ago I was following a few IA (Information Architecture) blogs, but dropped them quite quickly, because that was pretty much the main concern of theirs :)
For me, when some people say "design" they mean "style". For example, someone works in the UI layer? That's the visual style of the application. I think in the early days of the web, "design" was co-opted from traditional print graphic designers as a way to draw a distinction from then; a web designer. However, I think its much more important to emphasize the capital D Design that occurs in software development, as in your cake example. So I would adjust your example as such:
"visual style is like the strawberries on the cake, Design is the recipe. UX is how the cake tastes i.e. the culmination of Design and attention to detail during the assembly process"
That's a good way of putting it. I would add that someone, a UX role perhaps, also has to have researched/figured out the answers to "A cake for who?"
"What is the occasion?"
"How big does this cake have to scale?"
"Do we know if this certain bride has any certain preferences"
"Wait how did we determine this is a wedding cake?"
"My bad, it's a birthday party. But this was a pretty dope wedding cake we built don't you think? Tastes great!"
"But it was for a 6 year old boy's birthday"
"Look we don't have time to muck about with look and feel. It's a cake. It's a birthday, just fucking ship it." =D
The one thing that consistently confuses me is that when someone explains what UX is, it always ends up being explained in a very nebulous way where a UX designer seems to have authority over virtually everything in a company, and responsibility over very little.
It can occasionally feel as though UX people want to be PMs, UI designers, marketers, developers, and data analysts all at the same time, but of course when pressed, they "aren't supposed to be about UI / PM / dev / etc.".
The list is a great example. "Company Culture evangelism" is a UX discipline? Really?
No, they want to work with the PMs, UI designers, marketers, developers, and data analysts, enabling them to have the right tools to make better choices.
But "work with" as a very euphemistic term. Are they instructing the PMs etc., or are they acting on their orders?
I know that in an ideal world it's 50/50, but I don't think a position that is involved in every single step of the project has any chance of success unless you happen to also be in charge.
> Are they instructing the PMs etc., or are they acting on their orders?
What does a consultant do? A UX designer is basically another name for a consultant who, by training, knows a lot of stuff about the experience your users will have with your product. Like with any consultant, the relationship can be anywhere from asking them direct questions, to getting them to make you mock-ups, to modifying your product, to having them tell you what to do. As with any other consultant, you hire them for their perspective and experience, not for some particular skill.
A UX guy is not necessarily good at creating pretty designs--although he'll be able to tell you, using user-testing et al, whether a design is pretty. And so forth, for each thing they do. It's not a collection of skills; it's an approach.
(A similar question might be "what does it mean to hire a scientist?" Not skills; approach.)
Being an internal consultant is often what happens. It's a horizontal role that might look like it's owning a bunch of things, but really it's support various needs in various domains that have a touch on the user/customer "experience."
So yeah, I'll be in a PM meeting and then leading the PM meeting. Then I'll go out and into a meeting where we're analyzing analytics on the website, then to a meeting with devs on how we're implementing the interface literally, and getting me set up so I can run builds, edit the html/css, write all the front end views while devs create the models.
And then the CEO pulls me aside and wants to know what 'I'm doing to help turn this company culture into one that is user-centered and customer driven."
So it is like being a consultant on this huge spectrum of "customer/user experience" touch-points, and it's way more than just 1 or 2 people can do. And then all of this is rolled up into the perception that you're there for "look and feel" which probably only takes up 15-20% of your actual job.
You've made a really good summary of how I feel often.
You get it more than most. This is right on target.
It goes from 50/50 one day, to 90/10, to 10/90. And yes, often as I have lived and witnessed, UX is set up to fail through that structure, especially when they don't actually "own" anything.
They are contributing to their ideas, providing insight to help them make decisions.
A project manager will want to know how much time is needed and when to do user research, diary studies, usability sessions, surveys, wireframes, user stories, etc, etc.
A UI designer will want to work with the UX professional to understand what the user goals are, the user journey is. The UI designer will then design a UI to satisfy that story.
Marketers will communicate with the UX professional to give insight into the market needs, what competitors are doing, who the target customers are, and they work together to produce a coherent marketing message that matches the product.
Developers will work with the UX designer to understand the user impact of design decisions, the goals they are achieving, how to format usable error messages that fit a wider consistent experience, making sure that the press of a button doesn't have a 5 minute delay.
The UX professional is the user's stakeholder to make sure everyone is building something with them in mind. Without that everything is very siloed.
So yes, when I say they work with them, I really do mean it. They don't instruct, they don't follow, they simply collaborate.
Often the PM is doing design because the designers don't exist. When you are lucky to have designers, the PMs focus more on project requirements and project management and the designers focus on definition, but they obviously have to work together. In heavy design oriented orgs, you even have UX PMs who are responsible for managing design schedules and coordinating between designers and the rest of the project members.
I have definitely been a UX PM, even having a former VP of Engineering saying that the 3 "UX people" in the company were the only people providing the "tactical PM role" since PM's were stuck writing PRD's (waterfall product requirement documents). Maybe that's part of my skew as well is that I've always been a primary (diluted, overextended) stakeholder in design, PM, research, and development.
I think the best mental model for UX is a sort of advance QA.
QA teams don't instruct or manage the dev and design teams, but their sign-off is an essential part of the product release cycle. QA represents the user in the process--the customer who will be disappointed when they encounter a broken feature.
The purpose of the UX discipline is basically to represent the user earlier in the process--to identify aspects of the product that might be frustrating or disappointing even if they are designed and coded properly. The earlier those can be spotted, the less money and time will be wasted.
I think UX often is a thin, horizontal role across many others. My personal experience has been that yes, there are significant aspects of PM, UI, marketing, development, data analysis, etc that are thrown my way and I am supposed to "help shepherd" them. It's not that I demand those jobs, but they just become part of the horizontal UX ambiguity. In the last 3 places I've worked, part of that horizontal role has been just what you describe. There are other people there too, but as the "UX person", I was expected to be involved in all of that. And sometimes, even expected to own it.
"Company Culture evangelism" is a funny one because yes, at 2 companies part of the "UX" job, by request of C-level execs, was to work daily on spreading and educating on a "user centered culture" throughout the company :D
Great Article. UX is the new buzzword in pretty much every sector at the moment, especially financial, my last contract was "UX Developer" I'm not even sure what it means, but from my day to day, I wrote javascript HA!
I guess I should also keep an eye on UX gigs then. I'm a programmer and tended to ignore UX positions because I figured it might be a whole separate discipline. But I can do javascript just fine. (I'm not much good at graphical design, though.)
Who doesn't understand the difference between Interface and Experience? Clearly using tools with virtually no interface at all can be a great experience.
So let's take all this stuff that a UI designer does, claim that a UI designer doesn't do them and can't possibly understand them, and invent a new term, UX, to mean the thing that UI design used to mean. Okay.
Well, no. All those people who were already doing those things are UX designers now. I think the point of the rename is mostly that "UI designer" is limited and derogatory in the perception it encourages, like "code monkey" or "web designer." Nobody just does UI, so nobody is, or was ever, just a UI designer.
UI designer is not really a job title. Visual and interaction designers are common titles, UX designer is used in orgs who don't want to distinguish officially, though designers usually have strength in one area over the other.
At least that is the way it seems to work at big companies. I'm sure smaller companies use whatever the manager thinks of.
That reminds me of the universities that I went to that tried to rename the Graphic Design departments to "Communication Design" or "Graphic Communications" or anything but the image of a lowly pixel pusher. Graphic Design has been greatly devalued by the prevalence of the adobe suite of software- it used to be about solving large organisational problems. now people just think "The way it looks" and that perception has become impossible to shake. It's a real problem.
I don't think it's solved by coming up with new airy fairy words that nobody understands, and are never clearly defined. It gives the strong impression that it's not a real job. Like "social media consultant".
Since when UI ( =User Interface) is only visual? To me it seems as UI got too narrow understanding of just visual in the wild (i.e. general population) and then people who really understand what they are doing decided to rebrand themselves as too many people saying they are related to UI where just visual design related...
Yes and no, IMHO. The list on the left are all tools to solve interaction problems. But, I think "UX" professionals tend to fall into the trap that this is a process needed for every problem. Sometimes, good UX is just UI/Visual design. And, that is just fine.
Hello, I wrote this article. I can check one thing off my bucket list - an article of mine on the front page of HN (spot 28 as I write this).
Reading the stuff here in HN, I agree with almost everything said. My intent wasn't to take a hard line tone, and in retrospect after getting tons and tons of feedback, I'd write it differently, but I'll take this chance to clarify some things, both for myself and for others.
It is not written in a snarky or superior voice. It wasn't a rant. If it sounded so, I apologize. It also comes off as a list of "this is what a UX job title should be", which also wasn't my intent. The simplest way to say what I was trying to convey is that if you label yourself as anything "UX whatever", it is perceived as "graphic artist for interfaces."
The article often seems to convey that UX "owns" all these different things, like it's a panacea role above all others. It's not.
It's not something that I can clearly define. On the little 2-column lists, the things on the left were supposed to be things that I/we "do" in the sense of what often becomes the reality of the job, not in the sense of responsibilities that should be granted to use to be accountable for. And if that large list does become the reality of the job, it's more than anyone can or should do. It was intended to be a "these are some of the things a UX person might be responsible for." And yes there are some silly ones on there.
I don't think UX is in a position of being a land-grab of everything that isn't writing code because "it's what we do", but it's more of a "this is what we are often doing" list. And some of the things on it should be owned by other discrete jobs careers. The motivation to write the article came from being in role after role where that list on the left was the list of things I was inadvertently responsible for, but "graphic designer for interfaces" is all that is seen by others, which isn't fair to UX people who don't focus on interface design, and isn't fair to interface designers who don't focus on the UX work that isn't based on UI or visuals or interaction.
It's sort of just a response to the introductory conversation I have the first few weeks at any job. "What is your role here?" "Well I'm the new UX guy." "Great! Our stuff is ugly, you're gonna give it that sexy look and feel?" "Yes, but I am going to be doing other things that sort of result in that look and feel you want" And then when I list off some of those things, typically the other person looks at me like I'm a lunatic and we both end up confused on what I'm actually supposed to be doing, and the disappointment that I'm not just there for look and feel.
But for sure, the article is not meant to be a land-grab or king of the hill situation of "UX OWNS EVERYTHING", but just a glimpse into the terrible ambiguity of what UX is and how the very common initial perception of "graphic designer for interfaces" makes it even more unclear.
46 comments
[ 4.4 ms ] story [ 99.9 ms ] threadOne of my friends got an offer from his company to evolve his current position into a UX position. A while later, they have an actual project on which he could work as a UX designer. The only thing they ask is how fluent he is with a specific image editing software.
Another non developer talking about things that they can't implement.
There's an element of user-advocacy that I'm doing where I take the experience they are having and translate it back into business, design, and development goals as when someone is trying to use an enterprise piece of software and the experience is terrible, that is going to fall on designers, developers, PM's, and all the other people involved in the creation of the "thing" which becomes the user's experience.
That's another ambiguous situation. I go spend 2 days with users out at a company HQ, and I come back with tons of data that now has to be consumed by devs, designers, pm, marketers, executives, QA, customer service etc etc. The experience of what we build is a collection of every role in the entire company as far as the user is concerned, and all those various business roles need that UX information brought back. So at this point I'm so far from UI and visual design I'm closer to a PM or product owner now, but soon will be jumping back into the design an development realm to start to fix those experience problems.. unless the problems result in bad business drivers or invalid use-cases, so then I'm back at the PM and management table,
I still can't find a clear distinction about what I'm supposed to say I do. I just know that there is a certain disservice to just tell people "UI design, look and feel."
Design is like the strawberries on the cake, UX is, how the cake tastes.
My larger point is that the geeks of the web, in trying to come up with pointlessly precise definitions of what they do, rebase themselves from where they came from.
what i am trying to say is, what makes product successful is not the interface design.
I don't care if your product looks so beautiful and lovely if i can not use it with bad bandwidth for example, or on my mobile. I don't care how cool colours you use, if i need to click everywhere to find what i am looking for.
"visual style is like the strawberries on the cake, Design is the recipe. UX is how the cake tastes i.e. the culmination of Design and attention to detail during the assembly process"
The one thing that consistently confuses me is that when someone explains what UX is, it always ends up being explained in a very nebulous way where a UX designer seems to have authority over virtually everything in a company, and responsibility over very little.
It can occasionally feel as though UX people want to be PMs, UI designers, marketers, developers, and data analysts all at the same time, but of course when pressed, they "aren't supposed to be about UI / PM / dev / etc.".
The list is a great example. "Company Culture evangelism" is a UX discipline? Really?
I know that in an ideal world it's 50/50, but I don't think a position that is involved in every single step of the project has any chance of success unless you happen to also be in charge.
What does a consultant do? A UX designer is basically another name for a consultant who, by training, knows a lot of stuff about the experience your users will have with your product. Like with any consultant, the relationship can be anywhere from asking them direct questions, to getting them to make you mock-ups, to modifying your product, to having them tell you what to do. As with any other consultant, you hire them for their perspective and experience, not for some particular skill.
A UX guy is not necessarily good at creating pretty designs--although he'll be able to tell you, using user-testing et al, whether a design is pretty. And so forth, for each thing they do. It's not a collection of skills; it's an approach.
(A similar question might be "what does it mean to hire a scientist?" Not skills; approach.)
So yeah, I'll be in a PM meeting and then leading the PM meeting. Then I'll go out and into a meeting where we're analyzing analytics on the website, then to a meeting with devs on how we're implementing the interface literally, and getting me set up so I can run builds, edit the html/css, write all the front end views while devs create the models.
And then the CEO pulls me aside and wants to know what 'I'm doing to help turn this company culture into one that is user-centered and customer driven."
So it is like being a consultant on this huge spectrum of "customer/user experience" touch-points, and it's way more than just 1 or 2 people can do. And then all of this is rolled up into the perception that you're there for "look and feel" which probably only takes up 15-20% of your actual job.
You've made a really good summary of how I feel often.
It goes from 50/50 one day, to 90/10, to 10/90. And yes, often as I have lived and witnessed, UX is set up to fail through that structure, especially when they don't actually "own" anything.
A project manager will want to know how much time is needed and when to do user research, diary studies, usability sessions, surveys, wireframes, user stories, etc, etc.
A UI designer will want to work with the UX professional to understand what the user goals are, the user journey is. The UI designer will then design a UI to satisfy that story.
Marketers will communicate with the UX professional to give insight into the market needs, what competitors are doing, who the target customers are, and they work together to produce a coherent marketing message that matches the product.
Developers will work with the UX designer to understand the user impact of design decisions, the goals they are achieving, how to format usable error messages that fit a wider consistent experience, making sure that the press of a button doesn't have a 5 minute delay.
The UX professional is the user's stakeholder to make sure everyone is building something with them in mind. Without that everything is very siloed.
So yes, when I say they work with them, I really do mean it. They don't instruct, they don't follow, they simply collaborate.
QA teams don't instruct or manage the dev and design teams, but their sign-off is an essential part of the product release cycle. QA represents the user in the process--the customer who will be disappointed when they encounter a broken feature.
The purpose of the UX discipline is basically to represent the user earlier in the process--to identify aspects of the product that might be frustrating or disappointing even if they are designed and coded properly. The earlier those can be spotted, the less money and time will be wasted.
"Company Culture evangelism" is a funny one because yes, at 2 companies part of the "UX" job, by request of C-level execs, was to work daily on spreading and educating on a "user centered culture" throughout the company :D
I have seen a lot of companies doing that, they also guess a UX designer could do everything...
At least that is the way it seems to work at big companies. I'm sure smaller companies use whatever the manager thinks of.
I don't think it's solved by coming up with new airy fairy words that nobody understands, and are never clearly defined. It gives the strong impression that it's not a real job. Like "social media consultant".
Reading the stuff here in HN, I agree with almost everything said. My intent wasn't to take a hard line tone, and in retrospect after getting tons and tons of feedback, I'd write it differently, but I'll take this chance to clarify some things, both for myself and for others.
It is not written in a snarky or superior voice. It wasn't a rant. If it sounded so, I apologize. It also comes off as a list of "this is what a UX job title should be", which also wasn't my intent. The simplest way to say what I was trying to convey is that if you label yourself as anything "UX whatever", it is perceived as "graphic artist for interfaces."
The article often seems to convey that UX "owns" all these different things, like it's a panacea role above all others. It's not.
It's not something that I can clearly define. On the little 2-column lists, the things on the left were supposed to be things that I/we "do" in the sense of what often becomes the reality of the job, not in the sense of responsibilities that should be granted to use to be accountable for. And if that large list does become the reality of the job, it's more than anyone can or should do. It was intended to be a "these are some of the things a UX person might be responsible for." And yes there are some silly ones on there.
I don't think UX is in a position of being a land-grab of everything that isn't writing code because "it's what we do", but it's more of a "this is what we are often doing" list. And some of the things on it should be owned by other discrete jobs careers. The motivation to write the article came from being in role after role where that list on the left was the list of things I was inadvertently responsible for, but "graphic designer for interfaces" is all that is seen by others, which isn't fair to UX people who don't focus on interface design, and isn't fair to interface designers who don't focus on the UX work that isn't based on UI or visuals or interaction.
It's sort of just a response to the introductory conversation I have the first few weeks at any job. "What is your role here?" "Well I'm the new UX guy." "Great! Our stuff is ugly, you're gonna give it that sexy look and feel?" "Yes, but I am going to be doing other things that sort of result in that look and feel you want" And then when I list off some of those things, typically the other person looks at me like I'm a lunatic and we both end up confused on what I'm actually supposed to be doing, and the disappointment that I'm not just there for look and feel.
But for sure, the article is not meant to be a land-grab or king of the hill situation of "UX OWNS EVERYTHING", but just a glimpse into the terrible ambiguity of what UX is and how the very common initial perception of "graphic designer for interfaces" makes it even more unclear.