![\"5-things-ux-designers-never-say-FI\"](\"http:\/\/yushengteo.com\/blog\/wp-content\/uploads\/2015\/05\/5-things-ux-designers-never-say-FI@2x.png\")
<\/p>\n<\/p>\n
I’ve recently stumbled upon\u00a0an insightful\u00a0podcast<\/a> by Laura Klein<\/a> and Kate Rutter<\/a>, in which they discussed, and provided solutions to avoid, the\u00a0top five things that\u00a0UX (user experience) designers\u00a0should never say. These include misguided questions that UX researchers often ask their\u00a0customers, as well as mindsets that some UX designers have (but shouldn’t).<\/p>\n You should listen to their podcast. But if you can’t spare the time (or the\u00a0internet bandwidth on your mobile device), I’ve summarised the key reasons why these five statements are taboo, and what you should ask (or do) instead for each case.<\/p>\n <\/p>\n Here’s the rundown:<\/p>\n While this question helps you start a conversation, it\u00a0doesn’t tell you nearly<\/em> enough.<\/p>\n Many UX designers will listen to\u00a0the answer, and then stop there because, well,\u00a0they’re happy with what they hear. And that’s bad, because what you should really be asking isn’t just what users like – or hate -, but\u00a0why\u00a0<\/em>they do.<\/p>\n If you have to ask users what they like, at least follow up with\u00a0why<\/em>\u00a0they do. Ask:\u00a0why<\/em> did you find this feature cool? Or generally,\u00a0why<\/em> did you feel X about this feature?<\/p>\n Knowing why your user likes or dislikes your product gives you actionable information. Consider this:<\/p>\n Scenario A<\/strong><\/p>\n Q: What do you like about the product?<\/p>\n A: Oh, I like the cool animation that I see\u00a0when I press the buttons in the app.<\/p><\/blockquote>\n If you stop here, you might end up thinking to yourself: We’ve got to add more animations to the app!\u00a0<\/em><\/p>\n Which is a fair enough proposition, except that,\u00a0if you followed up with a\u00a0why\u00a0<\/em>question:<\/p>\n Scenario B<\/strong><\/p>\n Q: Why do you like the animations?<\/p>\n A: Hmm.. I think it’s because it gives me some sort of feedback, like I know for sure that the app’s transmitting\u00a0the data.<\/p><\/blockquote>\n Now you’ll know that it’s\u00a0really the feedback loop, not the animations per se, that users want.<\/p>\n Don’t get this\u00a0wrong, data is great; it lets you know what users are doing far better than talking to\u00a0them individually. But the problem, like #5 above, is that it doesn’t tell you\u00a0why<\/em>.<\/p>\n Talk to your users. Like,\u00a0real people<\/em>. Figure out\u00a0why<\/em> they’re\u00a0spending so much time on that pricing page; is it because they’re really considering signing up, or because they don’t understand the way you charge them?<\/p>\n Again, like #5 above, you can only work on improving your product if you know why the current one isn’t working (as well as it should).<\/p>\n The\u00a0draw of surveys is\u00a0its\u00a0ability to get quantitative data at scale. The drawback, however, is that\u00a0they don’t give you the insights you need to improve on your product.<\/p>\n To start off, multiple choice survey questions shut off all other possible options; instead of finding the actual problem,\u00a0you’re basically asking your users to pick from your pool of hypotheses.<\/p>\n On the other hand, if\u00a0your survey is qualitative, you’re essentially\u00a0asking people to write down what they think or feel. As a general rule, people\u00a0hate\u00a0<\/em>writing. Especially when they know they’re helping you do your job (you’re supposed to be the one who’s doing the writing in an actual user interview!). In the end, you’ll probably get lousy data.<\/p>\n Go out and talk to real human beings.<\/p>\n Hey, if I need<\/em> to talk to people, surely focus groups is the solution, right?<\/p>\n Nope, not quite. If you place\u00a0a group of\u00a0strangers in a room, and ask them for their opinions on certain issues, chances are you’ll get\u00a0similar answers from all of them. Because that’s the social\u00a0<\/i>thing to do. Humans are troublesome like that.<\/p>\n Ask your users questions, one user at a time. That’s how you can go deep and get insights from each of them.<\/p>\n First, to\u00a0whom <\/em>(and implicitly, why<\/em>)\u00a0you are showing it to\u00a0greatly\u00a0affects the level of fidelity required of your product. If you’re showing your prototypes to fellow designers for directional\u00a0feedback, then napkin sketches might\u00a0work fine. If, however, you’re showing your prototypes to users to get usability feedback, then you might need more than that (because users might not be used to thinking in terms of paper<\/em>).<\/p>\n Next, what do you mean by\u00a0finished<\/em>? Nothing is perfect, and so long as there are imperfections, there is\u00a0room\u00a0for improvement. And so long as there is\u00a0room for improvement, there is no\u00a0final<\/em>.<\/p>\n As a designer, shake off\u00a0the mindset that you own<\/em> the product (or design). You don’t.\u00a0Your users do, eventually.<\/p>\n Next, be\u00a0a better designer, by\u00a0opening up your ideas and work to constructive criticism. Learn how to take feedback, how to resolve different perspectives (and nasty colleagues), and how to design for someone other than yourself.<\/p>\n Humans are social creatures. The most reasonable, social thing to do after being interviewed for over an hour\u00a0by someone about\u00a0a product, is to lie and say “Yes<\/em>, I think I might\u00a0buy your product”.<\/p>\n And even if they really think\u00a0that they’ll need your product in the near future, humans suck so much at predicting future behaviour that they’re probably wrong.<\/p>\n Let’s assume that\u00a0your product solves a problem (it should). Instead of asking people if they\u00a0want<\/em> to\u00a0have this\u00a0problem solved, ask questions that will uncover whether they’ve\u00a0tried<\/em> solving it. In other words, do they have the intent<\/em> to solve<\/a> that problem? If they do, and if your product solves that problem, then chances are they’ll really\u00a0buy it.<\/p>\n Consider this:<\/p>\n Scenario A<\/strong><\/p>\n Q: Will you buy the product (an app that aids you in\u00a0losing weight)?<\/p>\n A: Yeah, I’d love to lose some weight! I’ll buy anything\u00a0that helps me to that.<\/p><\/blockquote>\n At this point, all seems to be going well: after over an hour of interviewing and explaining how your app works, this person says that s\/he’ll\u00a0buy your product!<\/p>\n But consider how the situation quickly changes once you start\u00a0finding out about the\u00a0intent\u00a0<\/em>to solve the problem:<\/p>\n Scenario B<\/strong><\/p>\n Q: What are some measures that you’ve taken to lose weight in the last 6 months?<\/p>\n A: Oh,\u00a0I cut down on my beer intake.\u00a0I\u00a0only drink one\u00a06-pack a week now.<\/p><\/blockquote>\n Well, now you know that this person isn’t even in your target market to begin with. There’s no\u00a0intent<\/em> to solve the problem that your product is about.<\/p>\n Here are the are 3 key takeaways from this podcast:<\/p>\n I’ve recently stumbled upon\u00a0an insightful\u00a0podcast by Laura Klein and Kate Rutter, in which they discussed, and provided solutions to avoid, the\u00a0top five things that\u00a0UX (user experience) designers\u00a0should never say. These include misguided questions that UX researchers often ask their\u00a0customers, as well as mindsets that some UX designers have (but shouldn’t). You should listen to their… <\/p>\n#5: What do you\u00a0like about the\u00a0product?<\/h2>\n
The Problem:<\/strong><\/h4>\n
What You Should Ask:\u00a0<\/strong><\/h4>\n
What’s The Difference?\u00a0<\/strong><\/h4>\n
![\"dr-who-why\"](\"http:\/\/yushengteo.com\/blog\/wp-content\/uploads\/2015\/05\/dr-who-why.gif\")
#4: We don’t need to talk to users, we have the data!<\/h2>\n
The Problem: <\/strong><\/h4>\n
What You Should Do:\u00a0<\/strong><\/h4>\n
What’s The Difference?\u00a0<\/strong><\/h4>\n
#3: Let’s do a survey (or a focus group).<\/h2>\n
The Problem with\u00a0Surveys:<\/h4>\n
What You Should Do:\u00a0<\/strong><\/h4>\n
The Problem with Focus Groups:<\/strong><\/h4>\n
What You Should Do:\u00a0<\/strong><\/h4>\n
![\"awkward-group-hp\"](\"http:\/\/yushengteo.com\/blog\/wp-content\/uploads\/2015\/05\/awkward-group-hp.gif\")
#2: I’ll show it (my design) to you when it’s finished!<\/h2>\n
The Problem:\u00a0<\/strong><\/h4>\n
What You Should Do:\u00a0<\/strong><\/h4>\n
#1: Would you buy this product (if it comes out)?<\/h2>\n
The Problem:\u00a0<\/strong><\/h4>\n
What You Should Ask:\u00a0<\/strong><\/h4>\n
What’s The Difference?<\/strong><\/h4>\n
![\"i-tried\"](\"http:\/\/yushengteo.com\/blog\/wp-content\/uploads\/2015\/05\/i-tried.gif\")
Conclusion:<\/h2>\n
\n
Don’t only\u00a0care about what’s happening; you need to know\u00a0why\u00a0<\/em> they happen as well (#5, #4).\u00a0<\/strong><\/h3>\n<\/li>\n
Don’t be afraid of hurting your designer ego (#5, #2, #1).\u00a0<\/strong><\/h3>\n<\/li>\n
Don’t be lazy (#5, #4, #3, #1).<\/strong><\/h3>\n<\/li>\n<\/ol>\n","protected":false},"excerpt":{"rendered":"