9 ms·

All too often, UI people end up being marginalized because management doesn't support them. Unless you just want "a new coat of paint" a good UX design will req

by ender7 14y ago

All too often, UI people end up being marginalized because management doesn't support them. Unless you just want "a new coat of paint" a good UX design will require some hard changes and product realignments. If the CEO is not interested in taking part in that conversation then you'll never be able to build a good product.

true_religion 14y ago
It depends.... 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.
timr 14y ago
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.
- 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?
- ender7 14y ago
  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.
  - timr 14y ago
    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.
    - ender7 14y ago
      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.
- ahmadss 14y ago
  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.
  - gruseom 14y ago
    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.
    - adrianhoward 14y ago
      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 :-)
- csmeder 14y ago
  >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".
- seivan 14y ago
  So true, so well said. Could not have said it better.
- bpm140 14y ago
  >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"?
malachismith 14y ago
Actually... most often UI people end up marginalized because they think their ideas and their needs are more important than they really are. Designers are, in general, their own worst enemies.
- woah 14y ago
  Interesting statement- any more concrete examples?
prodigal_erik 14y ago
"Never build a good product" is too strong. We as hackers have quite a few exceptionally powerful tools with terrible UIs (e.g., emacs) and it only really hinders the earliest portion of one's career before climbing the learning curve. Consumer stuff has a tendency to over-optimize for approachability, which my get you eyeballs but not dedicated power users whose lives revolve around tools.

by ender7 14y ago

true_religion 14y ago

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

timr 14y ago

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.

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?
ender7 14y ago
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.
- timr 14y ago
  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.
  - ender7 14y ago
    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.
ahmadss 14y ago
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.
- gruseom 14y ago
  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.
  - adrianhoward 14y ago
    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 :-)
csmeder 14y ago
>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".
seivan 14y ago
So true, so well said. Could not have said it better.
bpm140 14y ago
>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"?

malachismith 14y ago

Actually... most often UI people end up marginalized because they think their ideas and their needs are more important than they really are. Designers are, in general, their own worst enemies.

woah 14y ago
Interesting statement- any more concrete examples?

prodigal_erik 14y ago

"Never build a good product" is too strong. We as hackers have quite a few exceptionally powerful tools with terrible UIs (e.g., emacs) and it only really hinders the earliest portion of one's career before climbing the learning curve. Consumer stuff has a tendency to over-optimize for approachability, which my get you eyeballs but not dedicated power users whose lives revolve around tools.