Hacker News Reader

Comment by timr | Hacker News Reader

All too often, "UX Designers" end up marginalized because they're wankers - people who don't code and don't design, but want to get right in the middle of things and fling around opinions. Especially dangerous are the representatives of this breed who want to "manage process" as a way of "designing the product". Hiring that kind of person is a great way to get a useless bureaucrat on your team.

There are good designers who specialize in user experience, but those people are also good at marketable skills like graphic design, coding or statistics. Everyone on the team is responsible for good user experience. The existence of a person who does nothing more than "UX" is a process smell.

View on HN

Yes, and terrible engineers can also completely ruin the process. As can a terrible manager. What's your point?

A real UX person will be able to and should provide high-fidelity mocks of the entire flow, preferably with an interactive demo of some kind. They will certainly have design skills and preferably programming skills. However, those high-fidelity mocks are the last stage in the UX design process. If all you want are those final mocks then you are doing nothing more than asking for a new coat of paint, and what you really want is a graphic designer.

So, you're right, everyone on the team should be responsible for good UX, but it really helps to have someone who can slam together some mocks after the meetings, or whose job it is to come up with a completely new idea to solve our nasty onboarding flow problem. Because George, the guy who's in charge of making sure our DB doesn't implode under load? He might be able to help out with the UX, but he's already got a full-time job to do.

Your image of a UX person that produces no mocks, no prototypes, no designs, and just sits in meetings is a sad one. Those people should be fired, because they are not doing anything -- certainly not UX.

If a UX designer produces mocks and designs, they're a designer. If they produce software prototypes, that's called an engineer.

My point is that "UX Designer" is a largely unnecessary job description that is filled by quality execution in more traditional roles.

Sadly, "designer" is a poorly-qualified term. When I hear someone say that it's hard to tell whether they mean a graphic designer or a UI/UX designer (or possibly even a product manager or something).

And yes, there is a huge difference between the two. UI/UXers need to have extremely strong graphic design skills (and for 98% of the projects out there, they will be good enough by themselves), but for a perfectly-tweaked, masterfully perfected paint job to layer over the final UX, you should hire a graphic designer for a final pass (Apple does this, for example). Similarly, graphic designers, if asked to design UI, will usually produce something that looks gorgeous and is completely unusable (or, more frequently, completely ignores the corner cases that end up being deal breakers).

Or perhaps you mean _product design_, which involves a terrifying gestalt of UI/UX design, technical design (eng), and market planning/vision (management, PM, ...?). The person (or people) in charge of that varies by project and company, but in the most successful cases seems to be either someone who is good at all three or a 2-4 man group of representatives from the three domains.

"Or perhaps you mean _product design_, which involves a terrifying gestalt of UI/UX design..."

Terrifying, indeed. The people who obsess over terminology are, in my experience, often the same people who bring the least practical talent to the table.

Are you arguing that there is no difference between UI designers and graphic designers? It may all seems like "silly design stuff" but I promise you -- there's a big difference between the two. For example, UI designers usually need to be able to code (if perhaps only rudimentarily).

Or perhaps you're implying that there is no difference between UI designers and product designers? Admittedly, sometimes those are the same person, but usually the person who fills the PD roll is a manager or CEO (if at a startup). They'll certainly consult with the UI designer (and eng), and they may design most of the product with the UI designer. Or they may not. Not necessarily the same job. It really depends on the people and the company.

If this seems like bullshit to you then...I'm sorry? That's how most of the industry works (at Google, at Apple, at ...). There are not these strange creatures called "designers" who do everything and have all skills (some do exist! but they are shockingly, painfully rare. And they're usually not in charge, so it's hard for them to do product design).

Maybe you meant something more specific, but you seem to be implicating yourself. Here's what you said above:

"If a UX designer produces mocks and designs, they're a designer. If they produce software prototypes, that's called an engineer."

I'm a UX designer and I do both code and design.

You must know both to be a real UX designer. That's the person you want, and yes we're expensive. We may not be the best at either one, but our ability to bridge the gap between the two gives us a unique perspective that allows us to make experience improvements.

The problem is that "designer" can mean very many different things to different people. There's a large chunk of the world that always read "designer" as "graphic designer". Mixed up with this is the problem that the various communities of practice are, I think, searching for a more common identity.

In the development world we have "developers" or "engineers" - which include all of: * back-end coders * front-end coders * devops * folk focussed on building automated tests * folk focussed on tool development to support the rest of the team * database experts * etc.

... and we're also quite happy to have people be good at bits multiple categories and be

In the UX community we have: * interaction designers * graphic designers * UI designers * content strategists * usability testers * user researchers

And like the dev world there are people who are good a bits of multiple categories, but there isn't really a good general identity. As I said "designer" is often seen as just graphic design. UX Designer is a ghastly clumsy phrase, but at least it doesn't suffer that problem.

Clearly, you've had interactions with fakers who call themselves "UX Designers".

Real UX Designers are not process managers - they are folks who are vital to any product development because it's their responsibility to think about and WORRY about user needs, user goals, and user objectives and then design a product/site/app that meets and exceed these user objectives.

This thinking and worrying results in design documents as high-level as application architecture or as layout specific as UI sketches and fully baked UI mockups. Within the UI mockups, they're in charge of naming conventions, layout, structure, content hierarchy, and so forth.

This thinking and worrying also results in clickable prototypes (usually in the form of HTML only prototypes or InvisionApp prototypes) that brings together the user flows, architecture, and user goals into something the entire team can wrap their heads around.

Finally, the UX designer is instrumental in testing and validating design decisions and product design decisions in a live app. This involves knowing what to test, how to test it, and then iterating on the designs to make sure the feedback from users is reflected in an updated UI or a revamped flow.

This stuff sounds like a complete antipattern to me. Who shouldn't be thinking about users? That's not a specialty.

Prototypes and architectures divorced from working code are the kinds of thing that bog a project down and get in the way of people doing the real work, i.e. making the actual product.

I know what programmers do and I know (more or less) what visual designers do and I know what the decision-maker for a product does. I don't know what a "UX Designer" does, other than claim to do all the product thinking. In my experience, they mostly talk vaguely about how important they are.

This stuff sounds like a complete antipattern to me. Who shouldn't be thinking about users? That's not a specialty.

I agree that everybody should be doing it. However - there are elements of it that are skilled and tricky to pick up. Having experts around is handy. They can do stuff better, help facilitate and teach the rest of the team, and get things moving more quickly.

I'm about half dev and half UX in my skill set. I can train anybody to do some basic usability testing in an afternoon. But that person is going to miss some stuff that I see because I've been doing it for fifteen odd years and am bloody good at it. Ditto for user interviewing. Ditto for interaction design.

You get exactly the same thing on the dev side. Everybody should have some basics about operations, database design, system architecture, etc. But in any team more than two or three people you'll usually find some folk who are experts. They'll be the DBA gal or the devops guy.

That's doesn't mean having a DBA or a devops person requires the rest of the team suddenly forget about all their database/operations knowledge, or that the rest of the team shouldn't be involved in DBA/operations work. But having an expert around is useful. They can help you solve problems that you may not have come across before. They can help teach you new and better ways of doing things.

The great DBA and devops folk get the rest of the team up to speed with database/operations work as much as possible so they can focus on the really hard problems that are going to get in the way of the rest of the team's work.

That's what good UX folk do too (in my experience). They help get the whole team focused on thinking about users, and focus on helping solve the hard UX issues that are going to get in the team's way.

Prototypes and architectures divorced from working code are the kinds of thing that bog a project down and get in the way of people doing the real work, i.e. making the actual product.

No argument from me. No argument from most UX folk I know either :-)

I don't know what a "UX Designer" does, other than claim to do all the product thinking. In my experience, they mostly talk vaguely about how important they are.

Yup. Those people suck. As do some developers with "software architecture" type titles :-)

> it's [Real UX Designers'] responsibility to think about and WORRY about user needs, user goals, and user objectives and then design a product/site/app that meets and exceed these user objectives.

I know what you think you're saying, but read it over to yourself a few times. This is a tautology: you're saying that UX Designers are good because their responsibility is to do what UX Designers do.

And it's fundamentally wrong: the real party whose responsibility it is to make sure all that stuff happens is the product owner (entrepreneur in this case). The UX Design just has a job to do. The fact that it's a definable job isn't an argument that it should be someone's sole responsibility.

>Everyone on the team is responsible for good user experience. The existence of a person who does nothing more than "UX" is a process smell.

In all the good startups I've known, everyone was responsible for sales, hiring and creating an awesome work environment. Does that mean that sales and HR people are similarly "process smells"?

So true, so well said. Could not have said it better.

>Everyone on the team is responsible for good user experience.

True

>The existence of a person who does nothing more than "UX" is a process smell.

Depends on what you call UX. My definition of the noun "UX designer":

1. Participates in Observational Research (Watches customers use your software) right along side the product owner and developers. Any one who makes software design decision should be apart of the regular feedback loop. This can even include sales people if they are making design and feature decisions. If this doesn't happen you build the wrong software wich is a really bad ROI. (Note if you are building software where you accurately represent the user, such as github.com, Then this research can be skipped.

1.b Mentors new hires (dev, po, qa, etc) on how to get the most out of most out of observation research. Answers questions with reasons based on facts and proven knowledge. It is the UX designers job to help everyone take his or her job. UX is the whole teams job.

2. Participate in research debriefing with the rest of the team.

2.b Mentor new hires, and all I said above. UX is the whole teams job.

3. Use the "scenarios", "personas" and "activities" distilled from the debriefing to create a story map with the whole team (Dev, Po, QA, etc). From this story map "User Stories" and tasks are created.

3.b Mentor... and so on as said above.

4. Guide developers and mentor developers interested in making wire proto types to usability test.

5. Participate in Usability testing of said wireframes workflows.

5.b you know the drill, same as above.

6. Debrief on the results of usability testing.

6.b same as above...

7. Iterate on wireframes if necessary.

7.b same as above... (whole team involved, UX designer is mentoring, her job is to teach the team to make her job unnecessary.

8. By now hopefully we have spent very little man hours in finding a great solution to our goal. So we can code. Developers code and UX designer pair designs with them.

9. Team usability tests the product they just created.

9.b Same as above, mentors, etc

10. Debrief on usability test

10.b ...

11. Iterate on design, pair design with devs. Getting small details like padding and animation speeds right. With the goal of teaching the devs to the point that they can take the UX designers job.

12. Usability test again

12.b ...

13. debrief 13.b ...

14. Team releases product if its working for users.

15. Surveys and observational research to find out how effective is the "out put" (what we built) at creating "outcome" & "impact" (user time savings, user delight, increase in sales, brand loyalty, etc).

17. Debriefing on the Observational research, surveys, and quantitative data. Looking for things we could have done better. What worked well, what didn't, etc.

17.b ...

Note: the teams goal is not to maximize "out put". Many teams don't realize this. The teams goal is to _Minimize_ "out put" and maximize "outcome" & "Impact".

I think you just made timr's whole point. You could have just said "the UX guy runs the observational research and supervises wireframing and usability testing" but that just doesn't sound like a FTE.

For what it's worth, my experience matches timr's: if you get a developer and a designer to each read "The Design of Everyday Things" you'll get further and go faster than you would by adding a full time UX expert that can't design or code to the team.

Yes! Totally agree! There should never be a person whose sole job is "UX". I've encountered many of these people and have never seen one add value to a project.

As a further aside, I also despise "information architectures" which these UX people always want to hammer out. To me, information architecture is a buzzword and total crap. I want to see high fidelity design comps. No more Omnigraffle low fi wireframes. (And especially no Omnigraffle wireframes as a deliverable to developers to code real UIs!)

A good UX designer doesn't linger around after doing the job. Their utility drops drastically after the initial design. If they do have to stay, then they haven't done a good job of communicating the key points and observations.

A good UX designer SHOULD stick around because their utility after the initial design is to conduct usability tests, user research, and user feedback to make sure initial design decisions were sound and that the experience that actual users and customers have align with the goals of the business/organization (ie - conversion rates, profitability, ease of navigation, etc).

Ultimately, the UX lead helps with product decisions by leveraging said user feedback to suggest incremental changes to the product. If they simply leave after the designs are "done" and never touch the product or app again, then their utility is marginal to an organization.

"stick around ... to conduct usability tests, user research, and user feedback" is exactly the pitfall that UX falls into when it fails. We've seen it happen so many times, and en masse. This process-driven design fails, because it tries to put the designer in the middle of development, while taking away the responsibility for good design. It is attractive, because the UX designer can blame the users' "unexpected" behavior. It is attractive, because it exchanges the experience, with experiment. If the design is incomplete, it is incomplete, period. If the users have to be observed, let it be done, the development can wait. There is nothing worse than a designer who makes blind guesses about the design hoping that some miracle during the "usability test" will reveal a beautiful solution.

I don't care who does it - but doing usability testing, user research and user feedback isn't failure. It's validation. It's testing. It's closing the feedback loop.

That's not putting "design" in the middle of "development". It's making sure that we're actually doing what we think we're doing - building something that works and gives value to the user.

What's the alternative - just hoping that we got it right?

It does matter who does it, when it is done, and how the results are used.

Doing user study with the intention to iterate on the design after the development progress is already far into completion is failure of the designer. If the design is so weak that it hasn't been validated by users, then it is not finished yet, that's it. One has to straighten up the design and validate it with users first. And it has to be done -before- giving a detailed framework to the developers, and claiming that the design is good enough.

After the fact user studies to brush up the UI polish is fine, but that is not the core task of the interaction designer. It can be done by a different expert other than the designer if needed (a junior designer, a developer with interest in usability, etc.).

Ten years ago I thought this way. Now I don't.

I've seen too many successful teams work otherwise to think that way any more.

In my experience designers getting the design "right" before handing it over to developers is often just as wasteful, and goes wrong nearly as much, as the developers kicking off at the start and expecting the designers to "make it nice" afterwards.

Business folk, developers and designers need to work together right from the start. Figuring out the best ways to validate the assumptions that we're making so that we can be sure together that we're building the right product. Sometimes that's user research, sometimes that's validating business models, sometimes that's building stuff.

I've a 40m rant-ish presentation on design & how it should be an ongoing process over here if you're interested http://www.infoq.com/presentations/Design-Never-Stops :-)

Adrian, I finally watched your talk. Thank you for the link. It was a good talk. (Note to self: keep a few 40 minute talks handy in case the next discussion goes into a general area of interest :-)

My specific complaint will be that the talk occasionally digresses to what UX is, how a designer should be a good citizen, and how developers can be nice, etc. I am not familiar with the context of the talk, perhaps the general track had to have such discussions.

Nobody would argue that there would be no need to update the interaction as the product ages. However, that does not warrant the persistence of a designer in the middle of the development process. I am not referring to small changes to accommodate UI conveniences, about a design that did not fulfill its promise in the first place. A product design should not go out of date before it is released. A major revision is another story in itself, and that should be taken as a design update, and should be planned accordingly.

It is true that software is the most malleable product material ever, but the temptation to count on that malleability instead of focusing on good design only brings about frustration both on the side of developers and eventually on the side of designers, and most importantly on the side of customers.

Perhaps there is a bit of distrust between designers and the developers, as the developer has the final say in what is going to be done and what will be ignored, in addition to the need to update the design a little bit as the real usage data flows in. Or, perhaps the blanks in product requirements is a lot bigger in startups vs enterprise in a way that would effectively get the product change drastically every 3 months. I have only seen iterative design work well in indie games and small-time mobile apps, but those really do not count, as they would only be considered as prototypes in an enterprise environment, and you'd probably go about doing that much prototype while designing your framework.

Well - there's a lot more to IA than wireframes :-) Lou Rosenfeld's book "Information Architecture for the World Wide Web" is still a nice, small read if a little dated now and more oriented to content-based sites.

Wireframes are just one possible deliverable - a way of communicating the results of some kinds of UX work that include IA.

There's a lot of UX folk who hate 'em to - and would much rather spend their time working with the developers rather than waste a stack of time producing pointless documents.

See Jeff Gothelf's article on getting out of the deliverables business http://uxdesign.smashingmagazine.com/2011/03/07/lean-ux-gett... for example, or Google the stuff coming out of the Lean UX community.

Reply on news.ycombinator.com