UX is not UI
helloerik.com
helloerik.com
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
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."
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".
I have seen a lot of companies doing that, they also guess a UX designer could do everything...
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.
> "trying to come up with pointlessly precise definitions of what they do"
"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"
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.
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.