5 ms·

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

by dos1 14y ago

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

utopkara 14y ago
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.
- ahmadss 14y ago
  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.
  - utopkara 14y ago
    "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.
    - adrianhoward 14y ago
      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?
      - utopkara 14y ago
        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.).
        adrianhoward 14y ago
        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 http://www.infoq.com/presentations/Design-Never-Stops :-)
adrianhoward 14y ago
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-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.

by dos1 14y ago

utopkara 14y ago

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.

ahmadss 14y ago
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.
- utopkara 14y ago
  "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.
  - adrianhoward 14y ago
    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?
    - utopkara 14y ago
      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.).
      - adrianhoward 14y ago
        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 http://www.infoq.com/presentations/Design-Never-Stops :-)

adrianhoward 14y ago

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