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.

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.

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

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.

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.

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).

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

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.

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.

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.

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.

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 :-)

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.

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"?

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".

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.

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!)

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.

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.

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?

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.).

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 :-)

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.

in an early stage startup, you're still tossing around ideas and trying to find what fits with your target market. In that stage, you can't just contract out UX to a designer. You'll burn up all your runway doing so, as you iterate.

In my opinion its better to do UX internally, and coordinate with your designer for stylistic changes.

On a side note, the op is wrong when he writes "Bring in the UX designer before you’ve attempted any UI work." Yes you want to do UX first, but UI and UX are inseparable, because from the user perspective, the user interface(UI) always has a bearing on the user experience (UX). The UX should dictate the UI, but a good UX designer will always design the UI.

All startups work with constraints. For some startups design & UX are less important than for others.

Products CAN succeed with crap UX (though it can severely penalize the outcome).

Products CAN NOT succeed without _product_.

So if an entrepreneur has to pick between a rails developer and a front end dev, in some cases he has to pick the backend guy.

Rock, Entrepreneur, Hard Place

Which is indicative of the problem - UX is not just about the front end stuff it's about helping define what product to build.

Y'know all of that "Get out of the building" stuff that Steve Blank goes on about? The whole validating that you're actually really solving somebodies problem?

The UX world has a phrase for that. We call it "generative user research". We have a whole stack of useful toys in our toy box for helping folk do that well. We've already made, and learned from, the mistakes that I see folk in the lean startup world making.

I keep encountering companies that are just throwing money away building stuff too early, when a half dozen five minute conversations with some actual users would help them figure out what the right thing to build is.

The model of having the UX person in "control" sucks. They should be a peer team member not at the top of the hierarchy. But the value they bring is a lot more than just making-the-product-work-nicer. The real value, especially in early stage startups, is helping figure-out-what-product-to-build.

if i'm clear, you are saying, "the backend dev won't build the right thing if they don't don't a good UI person to guide WHAT to build".

Exactly ZERO startups that require _A_ backend to be built have succeeded with the right idea of what to build but no backend.

MORE THAN ZERO startups have succeeded by buildilng backends without consulting, often building the wrong thing first, or getting lucky, or with users that accept a SUBOPTIMAL (but better than status quo) experience.

In a perfect world you get infinite resources.

Obviously I'm painting this a clear either-or dichotomy, which its not, but the point is that sometimes, due to other constraints, an entrepreneur might have to make the call.

It doesn't make him a crappy entereprenur. Please understand that when you think "I won't work with him because he doesn't prioritize UX".

Absolutely. The thing I'd like to happen is for it to be an informed call. The stereotype I keep hitting about UX work is that:

* It's expensive

* It's more cost-effective to do it late than early

* It's just about making things "pretty" / "easy to use"

When in reality the opposite is often true. For example doing user interviews and user testing early is stupidly cheap if done right. It stops you wasting money by building the wrong thing.

Please understand that when you think "I won't work with him because he doesn't prioritize UX".

I do not and would not think that.

I do think that people who don't prioritise UX often (not always) don't understand the value that UX work can bring - and think that all UX work done by bringing in high-paid agencies / consultants that do all the work up front.

I'd try and educate them with examples of how it can help save them money in the very short term.

For example - a few months back I was talking to founder who was planning to spend about £20k to develop an "MVP" for this social recommendation site he was planning. We talked through a way he could test his idea with his real users for the cost of negotiating a poster placement at a local gig (free to very low 100s of pounds), thinking up a hash tag (free) and looking at twitter during a certain period of time (free). A five minute conversation saved that guy between 15.5 & 20k that he's going to be able to spend in useful ways to further develop the concept.

Another guy I talked to was doing his "get out the building stuff" and getting out to talk to users. He was getting great feedback and was planning to build. Five minute chat about interview style and it came up that he was, unintentionally, directing the interviews towards the solution in his problem space. Gave him some tips on non-directive questions and getting users to tell stories. Got a call two weeks later to say thank you and a nice bottle of booze in the post because - when he went out again and talked to users - he discovered some new and interesting differences in what folk were saying that radically changed what he was going to build.

(Note to self: find ways to get paid for five minute conversations in coffee shops, although the whisky was nice :-)

To pick a personal example we've got an in-house project aimed at the health/weight-loss for folk who "don't go to the gym". Coz I'm rubbish at following my own advice (and was in the target group so thought I was scratching my own itch) I started building our fantastic idea straight away - coz I had a couple of weeks free and, y'know, building shit is fun :-)

And yes - once we actually put it in front of users - nobody wanted it. We'd built the wrong thing. A couple of afternoons watching and listening and interviewing folk in that market told us what was wrong with the original idea, and has given us some great ideas for what we should be building instead (basically we were building something for folk with intrinsic motivation, we should have been building something for folk with extrinsic motivation). We wasted 14 days of work because I was too dumb to spend 1 day talking to people first.

I want UX skills understood and in the hands of everybody - because in my experience its the most effective way of building successful products cheaply.

Let's face it. As an entrepreneur, you have limited resources. There're only so many dollars in the bank account. These dollars have to be stretched to cover everything from pay and benefits to basics like coffee and internet access. Few entrepreneurs have room in their budget for deadweight, and a designer who proposes things that can't be implemented is deadweight of the worst sort.

Paul Rand

When, in fact, the positive ROI of usability improvement has been established for awhile: http://www.useit.com/alertbox/roi.html

A good UX guy will realize this and design to the situation, rather than preach some esoteric heuristics.

After all, a solid UX from the start will make it far easier to build and find success than having to re-invent the wheel (your product) later on in the cycle just to save some time and money at the start.

My personal opinion, of course.

You have to take a look at your competition. If a high quality experience doesn't matter then yes don't do the 29 things. However, remember "Design and UX is the new IP" - Ron Conway

And remember Paul Graham has said "always run uphill". He meant that when he could solve either a regular problem or a hard problem at Viaweb he'd always solve the harder problem as if he found it hard, his competitors would find it almost impossible.

So you can use UX and Design as your "barrier to entry"/"hard problem" amongst your competition. If you are solving some other non UX hard problem, then have a mediocre user experience if it makes sense.