<?xml version="1.0" encoding="UTF-8"?><rss xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:atom="http://www.w3.org/2005/Atom" version="2.0" xmlns:cc="http://cyber.law.harvard.edu/rss/creativeCommonsRssModule.html">
    <channel>
        <title><![CDATA[Stories by Tatev Hovhannisyan on Medium]]></title>
        <description><![CDATA[Stories by Tatev Hovhannisyan on Medium]]></description>
        <link>https://medium.com/@hovh.tatevik?source=rss-8eedd6a99fb0------2</link>
        <image>
            <url>https://cdn-images-1.medium.com/fit/c/150/150/1*dOo3z21LzF7dJWetkbP_xQ.jpeg</url>
            <title>Stories by Tatev Hovhannisyan on Medium</title>
            <link>https://medium.com/@hovh.tatevik?source=rss-8eedd6a99fb0------2</link>
        </image>
        <generator>Medium</generator>
        <lastBuildDate>Sun, 24 May 2026 21:04:56 GMT</lastBuildDate>
        <atom:link href="https://medium.com/@hovh.tatevik/feed" rel="self" type="application/rss+xml"/>
        <webMaster><![CDATA[yourfriends@medium.com]]></webMaster>
        <atom:link href="http://medium.superfeedr.com" rel="hub"/>
        <item>
            <title><![CDATA[4 Reasons why research participants (unconsciously) lie and how to prevent it]]></title>
            <link>https://medium.com/design-bootcamp/4-reasons-why-research-participants-unconsciously-lie-and-how-to-prevent-it-d2a966741b0b?source=rss-8eedd6a99fb0------2</link>
            <guid isPermaLink="false">https://medium.com/p/d2a966741b0b</guid>
            <category><![CDATA[user-experience]]></category>
            <category><![CDATA[research]]></category>
            <category><![CDATA[market-research]]></category>
            <category><![CDATA[ux]]></category>
            <category><![CDATA[ux-research]]></category>
            <dc:creator><![CDATA[Tatev Hovhannisyan]]></dc:creator>
            <pubDate>Fri, 26 Nov 2021 11:40:36 GMT</pubDate>
            <atom:updated>2021-11-26T11:40:36.864Z</atom:updated>
            <content:encoded><![CDATA[<p>When doing user research with participants, we frequently consider that the information they are providing may be flawed. And, well, that is possible since we’re talking to real people and they may provide faulty information, even without having that intent in mind.</p><blockquote>If we try to separate error types in participant responses, we will see the following causes of errors: memory, motivation, communication, and knowledge. The good news, however, is that there are methods to combat these error traps and obtain truthful information.</blockquote><p>Let’s go over the causes of such errors and what we can do to recognize and prevent them.</p><figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/0*51VxSeWhmcibBppa.png" /><figcaption>Old man remembering</figcaption></figure><h3>The error of memory</h3><p>Our memory can be quite fallible sometimes. Chances are any information you ask a participant to recall is no longer sharp in their memory. Activities and experiences may be forgotten, or the time at which they happened may be remembered incorrectly.</p><p>Big or important events (like the date of your child’s birth, school graduation, or getting fired from a job) generally tend to be remembered well. So do events that are repeated frequently, like the daily commute to work. Other events, however, may have various levels of sharpness in your memory, and the information may easily become distorted in time.</p><p><strong>How to prevent it:</strong></p><p>First, make your questions as specific as possible. When interviewing a participant, ask for behavior within an exact time period, rather than generally asking about participants’ usual behavior.</p><p>While generally, people think that shorter questions are best (as they reportedly have a higher answer rate), I advise giving some additional context or conditioning to questions that inquire about past events.</p><p>Remember that for regular, frequent behavior, respondents will estimate the number of events by using the basic rate they have stored in their memory. The accuracy of these estimates can be improved by asking about exceptions to respondents’ normal behavior.</p><p>Secondary records, like checking the bills, the mobile photo gallery, or asking other household members for input will help reduce or eliminate errors caused by memory distortion, as well as possibly provide additional detailed information.</p><p>Another method you may utilize is diary studies, an excellent source for collecting qualitative data during a prolonged period of time through participant entries of their activities or experiences.</p><figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/1*-kvEMvEtyrn0ZgRzQyQaGw.jpeg" /><figcaption>Photo by <a href="https://unsplash.com/@yasinyusuf?utm_source=unsplash&amp;utm_medium=referral&amp;utm_content=creditCopyText">Yasin Yusuf</a> on <a href="https://unsplash.com/s/photos/know?utm_source=unsplash&amp;utm_medium=referral&amp;utm_content=creditCopyText">Unsplash</a></figcaption></figure><h3>The error of motivation</h3><p>Sometimes participants have their own motivations that may contradict their ability to provide you with honest answers to your questions. For opinions that are controversial, somewhat shameful, or otherwise sensitive, participants may consider the truth somewhat too personal to share, fearing the consequences, and thus opting to give false and more neutral replies.</p><p>Particularly in the case of in-person interviews, there’s an increased probability that the respondents will try to present themselves to you in a more favorable light.</p><p><strong>How to prevent it:</strong></p><p>If there is any chance that the respondents may be afraid of other parties overhearing their conversation with you and the consequences it may have on their careers or relationships, it’s best to hold the conversations in a neutral location. For example, an employee might be reluctant to talk to you about his personal life while in the office. Similarly, a teenager might deny ever smoking cigarettes if her parents are present.</p><p>Questions that can be labeled as sensitive or polarizing need to be formulated differently to get honest information, even on polarizing topics or socially undesirable behavior experiences.</p><p>Note: the book<a href="https://www.amazon.com/Asking-Questions-Definitive-Questionnaire-Questionnaires/dp/0787970883/ref=sr_1_3?crid=276G2TG5GPC79&amp;keywords=asking+questions&amp;qid=1637250233&amp;qsid=133-4869643-2125657&amp;s=books&amp;sprefix=asking+questions%252Caps%252C317&amp;sr=1-3&amp;sres=B08R11JVYW%252C1545322996%252C0787970883%252CB09HRJ4SMX%252C0979416361%252C0978440749%252CB0863B566H%252CB00IA0ZQHY%252CB00ULZFRLG%252C0807765910%252CB07MMZ2DVV%252C1632861054%252CB00UASFC7S%252C1784529079%252CB004XG2CJY%252C0062651595%252CB08QQ4RT4Z%252C1633625060%252CB07BTN2S3H%252C0190057378"> <em>Asking Questions</em></a> by N. Bradburn, S Sudman, and B. Wasnik has a whole chapter devoted to carefully formulating threatening questions about behavior in a way that keeps the reports un-skewed.</p><figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/1*dsCLua-wdb1qDvvAfz8MmA.jpeg" /><figcaption>Communication Photo by <a href="https://unsplash.com/@lunarts?utm_source=unsplash&amp;utm_medium=referral&amp;utm_content=creditCopyText">Volodymyr Hryshchenko</a> on <a href="https://unsplash.com/s/photos/communication?utm_source=unsplash&amp;utm_medium=referral&amp;utm_content=creditCopyText">Unsplash</a></figcaption></figure><h3>The error of communication</h3><p>Sometimes respondents do not fully understand what they are being asked and answer the question in terms of their own (somewhat limited) understanding.</p><p><strong>How to prevent it:</strong></p><p>The same words may mean different things to different people.</p><p>Vague words may be interpreted less broadly than the researchers may have intended. Examples of such words include “enough, young people, generally, regularly, anyone, anybody, sometimes, fair, most.” Try to avoid vagueness and be specific about time periods or other categories you’re inquiring about.</p><p>Also, avoid any special terms or slang that may be unfamiliar to the user. Use words that virtually all respondents will understand or explain the term in the question (this isn’t always a good idea for all types of interviews). If the sample is homogeneous and most respondents would use the same slang, however, the use may be helpful to aid in the flow of the discussion.</p><figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/1*1SmNYd1MtrW5TtRno5ruQg.jpeg" /></figure><h3>The error of knowledge</h3><p>Sometimes the user just doesn’t know the answer to what’s being asked of them, yet still answers the question without indicating their lack of knowledge.</p><p><strong>How to prevent it:</strong></p><p>Respondents will generally give more accurate information about themselves than about relatives, friends, or coworkers. Answers about behaviors and experiences of others can still be valuable to your research but be careful to refer to them as speculations on the participants’ side, not factual data.</p><p>The best thing you can do to ensure the participants are answering the question you meant to ask is to probe further and request examples or stories about the topic. Keep in mind that you should be careful not to put the participants in a situation where they feel they are being caught for telling a lie or that they’ve somehow failed a test.</p><p>User research can be an invaluable source of knowledge. Acknowledging that humans are flawed and may at times provide faulty information is not a reason to abandon the research practice but rather a call to take the specificities of being human into account when shaping your questions and methods.</p><img src="https://medium.com/_/stat?event=post.clientViewed&referrerSource=full_rss&postId=d2a966741b0b" width="1" height="1" alt=""><hr><p><a href="https://medium.com/design-bootcamp/4-reasons-why-research-participants-unconsciously-lie-and-how-to-prevent-it-d2a966741b0b">4 Reasons why research participants (unconsciously) lie and how to prevent it</a> was originally published in <a href="https://medium.com/design-bootcamp">Bootcamp</a> on Medium, where people are continuing the conversation by highlighting and responding to this story.</p>]]></content:encoded>
        </item>
        <item>
            <title><![CDATA[Prototype testing — the complete guide]]></title>
            <link>https://medium.com/design-bootcamp/prototype-testing-the-complete-guide-15b28d7a3efc?source=rss-8eedd6a99fb0------2</link>
            <guid isPermaLink="false">https://medium.com/p/15b28d7a3efc</guid>
            <category><![CDATA[ux-research]]></category>
            <category><![CDATA[product-design]]></category>
            <category><![CDATA[idea-validation]]></category>
            <category><![CDATA[user-research]]></category>
            <category><![CDATA[prototype]]></category>
            <dc:creator><![CDATA[Tatev Hovhannisyan]]></dc:creator>
            <pubDate>Fri, 03 Sep 2021 05:08:27 GMT</pubDate>
            <atom:updated>2021-09-03T05:08:27.032Z</atom:updated>
            <content:encoded><![CDATA[<h3>Prototype testing — the complete guide</h3><p>So, you’ve worked relentlessly on creating your new product or adding the coolest new feature and are impatient to hand it off to development. But are you actually confident that what you’ve designed solves a need, is going to be usable, and have you considered all the flows the users might go through to achieve their goals?</p><blockquote>To feel more confident in your design, consider building fake façades, imitations of products that will capture the experience without going through the extensive process it takes to build the real thing just yet. Prototype tests do just that.</blockquote><h3>Why do it?</h3><p>✅ To validate the ideas</p><p>✅ To minimize costs</p><p>✅ To uncover opportunities</p><p>✅ To get unbiased feedback</p><p>✅ To discover minor bugs</p><h3>How to do it?</h3><p>Well, that’s what this article is about!</p><p>In my experience the easiest way to dissect a prototype testing experiment is by separating it into three phases:</p><ol><li>Script writing</li><li>Preparing files</li><li>Moderating</li></ol><p>On their own, each phase has its best practices and popular pitfalls, but together they form the experience the test participant will have from the session and each will directly impact the results you obtain.</p><h3>Script writing</h3><h4>1. Test for what’s important, focusing on a few high priority hypotheses</h4><p>Create a hierarchy of priorities of hypotheses you need to validate foremost before moving forward with product decisions. Especially if you have a complicated product, de-emphasize the actions you’re not prioritizing to test within that research session and focus on topics that will enable you to tick the big questions off the list.</p><p>When considering the priorities, remember to get the input of other stakeholders, since there may be hypotheses that the Product Manager, UX Designer, or Engineering Manager may have that you didn’t consider previously but which are critical for overall product development.</p><p>Focus on a maximum of 2–3 topics for the research during each session. Jumping from one topic to another will break the storytelling process of the user and might result in missing information that the interviewee would otherwise give outside of just answering the questions or performing tasks.</p><p>Also, be careful not to fall for the loophole of having few but very vague goals. It’s one thing to say, “I want to test the prototype,” and completely different to say, “I want to explore how the users navigate through the hospital signup flow when they are in an emergency.” Unfortunately, you won’t be getting far with the first approach.</p><h4>2. User test VS Usability test</h4><p>Once you have your goals in mind, it’s important to decide what exactly you’re trying to achieve — gathering qualitative feedback or a list of usability issues and ideas. Most prototype testing sessions I’ve observed have focused on the usability of the prototype, trying to see if the product is usable or not, how participants interact with it, where they get stuck, etc.</p><p>Qualitative user research sessions on the other hand would be focusing on the need of the users in the first place — what are the user’s expectations, how do they perceive the product, when do they imagine they might need it.</p><p>While both test formats are completely legitimate and useful, it’s important to decide what you want to focus on. Is it to validate the need in the first place or to see if the users can add items to the cart and proceed through checkout?</p><h4>3. Start with a mindset or scenario and utilize the Jobs To Be Done Framework</h4><p>Participants must have a certain level of contextual understanding before they jump into testing your product. When will they feel the need for your product? Where will they be? Are there any external or internal influences to be expected? If you’re familiar with the Jobs To Be Done Framework, this could be the perfect time to use a Job — what is the thing the user is trying to achieve in their life when using your product?</p><h4>4. Ask participants about their expectations</h4><p>This can be done on a more general or local level. Explore what the participants expect to happen after they click a button or when/how they expect to interact with the product. Questions on expectations are crucial, especially towards the beginning of the conversation before the mental model of the participant adjusts to the product you’ve presented them with.</p><p>Some great follow-up questions to a task the participant has performed are to probe, “does this meet your expectations?” and “what did you expect instead?”</p><h4>5. Dry run</h4><p>Most of the time, prototypes aren’t as complete with all of the actions users might consider doing during the test. The best way to minimize wasted time re-running interviews and usability sessions with your precious users is to perform a dry run (also known as a pilot test) with other people before the session. The pilot tester can be a colleague that hasn’t worked on your product or even a family member if your product category permits it. The important part is that you keep it as realistic as possible, using the same script as you plan to with the user.</p><h3>Preparing Files</h3><h4>6. Pick the right fidelity level</h4><p>The depth of the insights you gather from your prototype test is in direct correlation with the fidelity level of your prototype.</p><figure><img alt="Low fidelity paper prototype test" src="https://cdn-images-1.medium.com/max/1024/0*GWa4AXOGYdLfttfc" /></figure><p><strong>Low fidelity / Paper prototypes</strong></p><p>Excellent for: Initial architecture and idea validation</p><p>Advantages: Quick, easy, no commitment, easy to modify</p><p>Disadvantages: Somewhat unrealistic experience, little visual presentation</p><p>Best used for: Small usability tests and initial product feedback</p><figure><img alt="Mid-fidelity prototype test with wireframes" src="https://cdn-images-1.medium.com/max/1024/0*qTBVfhvQMcwR7z9J" /></figure><p><strong>Wireframe or mid-level fidelity prototypes</strong></p><p>Excellent for: Getting more product-focused feedback</p><p>Advantages: Building blocks can be reused and adapted quickly</p><p>Disadvantages: Dummy texts and wireframe components may provide an unrealistic experience</p><p>Best used for: Multi-page prototypes with different flows and user subtasks</p><figure><img alt="High fidelity prototype test with device" src="https://cdn-images-1.medium.com/max/1024/0*utf8q3oB_1FxRme7" /></figure><p><strong>High fidelity or complex prototypes (including developed product tests)</strong></p><p>Excellent for: End-to-end user flow experience feedback that can include feedback on elements of UI</p><p>Advantages: Realistic, easy to test</p><p>Disadvantages: Hard to modify, drastic changes can be too late to implement</p><p>Remember, when building a prototype not EVERYTHING needs to be functional, but rather just enough to have a smooth testing experience to generate data points.</p><h4>7. Use realistic, non-distracting content / scenarios</h4><p>Form fields with Batman’s personal information and adding ‘lorem ipsums’ are easy options, but will keep the scenarios unrealistic, taking the concentration off from the product. Avoid these extremes whenever possible and test with content that will help users focus on the task at hand rather than on the distracting made-up content.</p><h4>8. Don’t forget prototype-specific test factors</h4><p>Most prototyping tools have a feature that highlights the clickable area whenever the user clicks anywhere on the screen. Obviously, this is not going to be the case when the product goes live and the hints may guide the users where to click to proceed, so you might consider disabling the highlights for a more realistic test.</p><p>Will the users be under any time constraints when using your product in real life? Account for that as well or you risk validating a solution that will be inconvenient in the real usage environment.</p><p>An example of this may be prototype testing ticket selling machines at train stations. These users are most likely under stress since their train is about to leave, there’s a huge queue behind them, and they’re not performing this type of action daily, so it is important to account for this during testing.</p><h4>9. Test in the right environment</h4><p>What is the context in which the users will be interacting with your product? The ideal place would be the actual environment in which the product will be used. Unless you expect the real use to be in a calm environment with no distractions, avoid testing at usability labs as much as possible and opt for more close-to-reality options, like testing at participant’s home, a busy cafe, or even in traffic (ensuring safety first, of course).</p><p>Another tip would be to test outside of your company premises, as the excitement of visiting a cool office or the view of a team looking busy working on the product may lead the tester to highlight positive feedback only.</p><h3>Moderating</h3><h4>10. Informing users</h4><p>Prototypes are different than final products, obviously. You know it, the Product Manager knows it, but the user might not be as familiar with the concept. It’s best to inform the user that:</p><ul><li>This is a prototype test so some of the functions will be disabled during the session.</li><li>You want them to stick to the scenario, however, provide verbal feedback about anything else that they’d expect to see in the live product.</li><li>In case you have the highlight feature enabled for the prototype, the clickable areas that the user will see will be highlighted. This is not part of the product itself but the testing tool, so remind them it won’t be highlighted when they use the product in real life.</li></ul><h4>11. Encourage participants to think aloud and share “It would be great if…”</h4><p>Like with any qualitative research, the point of prototype testing isn’t just to receive answers to the specific questions you ask or tasks you give, but also to learn about the thought process of the testers, their expectations, what mismatches they experience, and more. Ask users to think out loud as they navigate the product and encourage them to share additional feedback and contribute ideas.</p><h4>12. Reverse the questions addressed to you as a moderator</h4><p>During any moderated prototype testing session, you will hear questions like, “can I do X with this?”, “why did this page reload?”, “what should I do to get to the next screen?” A LOT. You will naturally be inclined to answer them (at least some), but this is highly inadvisable. To begin with, the participant will stop feeling like the one doing the testing and will feel more like they are being tested, causing them to try to answer all the questions in “the right way”.</p><p>The best response you may have to such questions addressed to you is to reverse them and ask the participant what THEY think is going on. Variations of, “what do YOU think this change means?”, “what makes you say that?” and “how would you explain what you should do next?” are here to save you at such times.</p><h3>Final Thoughts</h3><p>In his book, Zen and the Art of Motorcycle Maintenance, Robert Pirsig has a quote that 50 years later, stays true, no matter the field of study:</p><p>“An experiment is never a failure solely because it fails to achieve predicted results. An experiment is a failure only when it also fails adequately to test the hypothesis in question or when the data it produces don’t prove anything one way or another.”</p><p>Similarly, the point of prototype testing shouldn’t be confirming what you expect and moving forward, but testing hypotheses and gathering data that will enable you to make informed data-driven decisions. Most of the time this will include iterating, iterating, and iterating again until you get a product version that has just the right balance of everything.</p><img src="https://medium.com/_/stat?event=post.clientViewed&referrerSource=full_rss&postId=15b28d7a3efc" width="1" height="1" alt=""><hr><p><a href="https://medium.com/design-bootcamp/prototype-testing-the-complete-guide-15b28d7a3efc">Prototype testing — the complete guide</a> was originally published in <a href="https://medium.com/design-bootcamp">Bootcamp</a> on Medium, where people are continuing the conversation by highlighting and responding to this story.</p>]]></content:encoded>
        </item>
        <item>
            <title><![CDATA[3 Surveys to do quarterly for ux monitoring]]></title>
            <link>https://uxplanet.org/3-surveys-to-do-quarterly-for-ux-monitoring-58e8774649d1?source=rss-8eedd6a99fb0------2</link>
            <guid isPermaLink="false">https://medium.com/p/58e8774649d1</guid>
            <category><![CDATA[ux-research]]></category>
            <category><![CDATA[surveys]]></category>
            <category><![CDATA[strategy]]></category>
            <category><![CDATA[user-research]]></category>
            <category><![CDATA[analysis]]></category>
            <dc:creator><![CDATA[Tatev Hovhannisyan]]></dc:creator>
            <pubDate>Thu, 13 Aug 2020 08:03:49 GMT</pubDate>
            <atom:updated>2020-08-18T11:09:42.026Z</atom:updated>
            <content:encoded><![CDATA[<h3>3 Surveys to do quarterly for UX monitoring and strategy.</h3><h4>This article will tell you about 3 survey types that you can carry out to measure your customers’ satisfaction and see your progress quarter by quarter.</h4><p>Organizing and conducting impactful user experience (UX) research is often harder than it seems — there’s always a backlog of tasks marked “urgent”, dozens of usability tests, preference tests, competitor researches, and many more.While these types of research are definitely important, they are not giving you a full picture of where your product and your brand are at the moment, as well as how the changes in design or functionality are affecting the user perception and experience.</p><blockquote>To learn how your product is performing, you need to carry out repetitive, identical research that will monitor the growth or decline of user satisfaction through time and changes.</blockquote><figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/1*plJtHFklQo4ag96sxFgVmA.jpeg" /></figure><p>By conducting and analyzing UX research quarterly, you will be able to track overall user satisfaction and compare how your efforts have been affecting their perception of the product, brand, and specific features.</p><p><strong>Why do this quarterly?</strong></p><p>Well, if your product is evolving and your designs are changing periodically, you NEED to have a clear understanding of how satisfied your current users are with the product in general and its specific parts. Moreover it is imperative to be aware of how well your brand is being perceived and how easy it is to interact with. Without this, you might struggle to successfully cater to your users’ specific needs.</p><h3>1. User Satisfaction Survey</h3><p>Also known as Customer or Client Satisfaction Survey (CSAT), this type of survey will help you measure how satisfied your users are with your brand, its services or features.</p><figure><img alt="" src="https://cdn-images-1.medium.com/max/889/1*QlZ6T-9T8iAeE-K9vQi04A.png" /><figcaption>Satisfaction Meter</figcaption></figure><p>Knowing which areas your users are most satisfied with, as well as what they find worthy of improvement, will help you narrow down your list of priorities and decide on potential improvements to make.</p><p><strong><em>How to create a User Satisfaction Survey</em></strong></p><p>A typical Satisfaction question would be along the lines of: “How satisfied are you with the product/service you used?” with a rating scale from “Completely Dissatisfied” to “Completely Satisfied”. The rating scale will help you compare the satisfaction level of today with that of last quarter.</p><figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/1*I4pX6yauAS_2hK7nqIM52w.png" /><figcaption>“How satisfied are you?” question with a rating scale.</figcaption></figure><p>Another good question to ask your users is “What do you like/dislike the most about our product?” This will be a good opportunity for them to describe what irritates or delights them the most about your product.</p><h3>2. Net Promoter Score (NPS) Survey</h3><p>The Net Promoter Score helps you understand how loyal your customers are to your company. It also allows you to identify which user groups are less likely to recommend your product. This valuable information will come in handy when you make future marketing and product decisions.</p><p>The main objective of this survey is to divide your users into three main categories:</p><p>1. Detractors (dissatisfied users who will discourage other people from using your product);</p><p>2. Passives (who will neither bring nor discourage future users);</p><p>3. Promoters (satisfied users who will bring in new users by being your advocates).</p><p>With NPS, you can measure the satisfaction and praise of your customers on multiple levels — from overall product experience to individual features or actions taken.</p><p><strong><em>How to create a Net Promoter Score Survey</em></strong></p><p>The NPS survey is probably the most hassle-free way you can go about measuring customer loyalty.</p><p>The main question is “How likely is it that you would recommend this product to a friend or colleague?” with a scale from 0 to 10 as quick answer options.</p><figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/1*XXLoYIVRw4mt07iEVLjxHA.png" /><figcaption>NPS Question “How likely is it that you would recommend this company to a friend or colleague?” — image by SurveyMonkey</figcaption></figure><p>People who rated the product from 0–6 are the Detractors — they are the unhappy, dissatisfied customers that will most probably quit using your product, and may even discourage others from trying it.</p><p>Those who rated 7–8 are the Passives that are satisfied but are not brand advocates. These are the users that may switch to another brand if it offers better quality or pricing.</p><p>Finally, those giving a 9–10 are the Promoters — the satisfied, enthusiastic users that will stick with your brand as long as they can, and will also encourage their friends or colleagues to give your product a try.</p><figure><img alt="" src="https://cdn-images-1.medium.com/max/815/1*r8Yn5sykO00oSDGF_ZERRg.jpeg" /><figcaption>Net Promoter Score — image created by HelpShift</figcaption></figure><p>The NPS is measured on a scale from -100 to +100, with higher scores meaning more loyalty.</p><p>To calculate the NPS, subtract the percentage of Detractors from the percentage of Promoters, while ignoring the Passives.</p><blockquote>NPS = %Promoters — %Detractors.</blockquote><p>If you only want to measure your user satisfaction score, one question should be enough. However, if you are eager to understand the reasoning behind the score, you can set up some additional, detail-specific questions. It is important to note that follow up questions will not be directly a part of your NPS score, however, they will give you the insight you need to enhance your product. One possible follow-up question may be “How can we make your experience better?”</p><p>You can also ask a demographic question about the user’s age, gender, location, and more — but do so only if you’ll be using the information to interpret the score and if it will be valuable to you.</p><h3>3. System Usability Score (SUS) Survey</h3><p>The System Usability Scale provides a quick, easy to analyze and reliable information about the usability of your product.</p><figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/1*fc4D7D9urHFu0rbm8cpP2Q.jpeg" /><figcaption>Usability Test Sticker — by David Travis on Unsplash</figcaption></figure><p><strong><em>How to create a System Usability Score Survey</em></strong></p><p>As outlined by John Brooke in 1986, it consists of a 10 item questionnaire with five response options for respondents; from Completely agree to Completely disagree.</p><p>Here’s the list of questions that your interviewees/testers need to agree or disagree to:</p><ol><li>I think that I would like to use this system frequently.</li><li>I found the system unnecessarily complex.</li><li>I thought the system was easy to use.</li><li>I think that I would need the support of a technical person to be able to use this system.</li><li>I found the various functions in this system were well integrated.</li><li>I thought there was too much inconsistency in this system.</li><li>I would imagine that most people would learn to use this system very quickly.</li><li>I found the system very cumbersome to use.</li><li>I felt very confident using the system.</li><li>I needed to learn a lot of things before I could get going with this system.</li></ol><p>Interpreting the scores can be a bit tricky. So here’s a detailed step guide:</p><figure><img alt="" src="https://cdn-images-1.medium.com/max/1008/1*pXCkbcpFVC9bRiiiSm86Og.png" /></figure><ol><li>Convert the scores to 1–4 points (with Strongly Disagree = 1 point, and Strongly Agree = 4 points) and add the scores.</li><li>Multiply the sum by 2.5 to move from a 40-point scale to a 100-point scale.</li><li>Compare your score. Generally, a score above a 68 would be considered above average and anything below 68 is below average.</li></ol><h3>Putting it all together</h3><p>Carrying out consistent research quarterly will give you a better idea of your users and the way they feel about your product. This valuable information will eventually pave the path to success for your product.</p><img src="https://medium.com/_/stat?event=post.clientViewed&referrerSource=full_rss&postId=58e8774649d1" width="1" height="1" alt=""><hr><p><a href="https://uxplanet.org/3-surveys-to-do-quarterly-for-ux-monitoring-58e8774649d1">3 Surveys to do quarterly for ux monitoring</a> was originally published in <a href="https://uxplanet.org">UX Planet</a> on Medium, where people are continuing the conversation by highlighting and responding to this story.</p>]]></content:encoded>
        </item>
    </channel>
</rss>