Tag Info

Hot answers tagged

80

These are very popular quotes from Steve Jobs and are frequently pointed to as reasons why we shouldn't test. If Steve did it, so can we! The trouble is that most people miss several key points. The first is that they are not Apple: A Forbes article, Five Dangerous Lessons to Learn from Steve Jobs, lists these quotes as #1. Chunka Mui, the author of the ...


31

We're mixing two phases of the product development lifecycle. Jobs' quotes were focused on Focus Groups--where you are essentially asking the consumers what they want. This happens at the beginning of the development lifecycle (or even before that in discovery). Often, if you rely heavily on focus groups to drive product design, you tend to end up with ...


26

I have come across this exact problem on a project. Everybody on the team is already stretched to the limit to get a product shipped - and it's important to get it out before a particular international event (for example). So a UX review which happens too late in the development life cycle throws up some serious issues which no-one had foreseen. What to do - ...


21

Asking someone why he didn't notice something isn't likely to provide useful information. People will confabulate a response for the sake of their own mental consistency without even realizing they've done so. We can only focus on a few things at once; if we don't notice something, it's because we were paying attention to something else. He didn't notice ...


20

The general rule of thumb for usability is to start off with no feedback, but to then display some busy indicator after 200ms, and if the process normally takes 5 seconds or more to present a larger feedback element (usually with a time elapsed timer, but preferably not with a progress bar unless you're very sure how long it will take). If something is ...


17

My answer would be: usability testing isn't intended to design anything, it's intended to efficiently locate problems with a design. Good design requires vision, one or more talented designers, brainstorming, thinking things through, knowledge about your intended users, good design and prototyping tools, etc. One thing surprises me about the quote, though. ...


17

If a trial required me to enter these details before beginning the trial, I turn the other way and would not use the product at all. There is no good reason to gather these details in advance other than to increase the chance that the user will forget about the trial and get an automatic bill. I have all too often installed trial software and forgotten about ...


16

There are several reasons this practice is common: The company wants to know who you are so their salesmen can follow up with you and help you on to a purchase; The company may want to know if you are one of their competitors before showing you the product (the higher the barrier to entry is of the market, the more important this becomes); The company ...


15

The minimalists would say "when there is nothing left to remove" :-) Ok, Now seriously, an interface is complete when is satisfies all the goals you set for it - so if you don't have measurable goals you can't measure completeness - after all you can't measure fitness without knowing what you are supposed to fit to. A good example of goals would be: ...


15

There is no contradiction between being concerned with statistical significance and conducting usability tests with 3 to 5 users. Technically, “statistical significance” means the results you’re seeing cannot be plausibly attributed to chance. In scientific research, where the cost of reporting spurious results is high, “plausible” is generally defined as a ...


15

You are conflating 'subjective' and 'unreliable'. Usability tests aim to get reliable information about people's reactions. Self-reported opinions are also subjective, and are much less reliable indicators of how other people will react to the interface. If I test 100 people and their subjective opinion is that they hate an interface, I'm pretty sure that ...


15

+1 on "UX starting at day 0". [Minor caveat that I'm a dev and not a UX person so I might have a bit of a naive understanding of what is done/needs to be done from a UX perspective]. I have worked on Agile teams where UX folks were an integral part of the team and a few things that seemed to work well: Early UX involvement Often our interaction ...


14

In terms of navigation and hierarchy, Open Card Sorting should do the job. Open Card Sorting: Participants are given cards showing site content with no pre-established groupings. They are asked to sort cards into groups that they feel are appropriate and then describe each group. Open card sorting is useful as input to information structures in new or ...


13

I don't think there are any real cons because you can always just ignore the recommendations. The problem I see is that usually you won't get any new or useful ideas because (with some exceptions of course) users will only know what they want when they see it. Or as Henry Ford put it: "If I had asked people what they wanted, they would have said 'faster ...


13

Do you have to put 'OK' and 'Cancel' on the buttons? One of the problems with OK/Cancel in dialogs (and similarly, but worse, Yes/No) is that the user has to refer back to the original question to understand what the buttons will actually do. This is probably more of an issue than whether the OK or Cancel is on the left or the right. For example: Are ...


13

Short version: Do Formative Usability Testing at the start of the design phase, testing with paper-prototypes and similar. Do this to discover insights and shape the design direction. Do Summative Usability Testing during latter half of the development phase, testing with actual working prototypes. Do this to determine metrics (time on task, success ...


12

In an article written in 2000 Jakob Nielsen recommended that for qualitative user testing 5 users is the optimum IF you run 3 testing sessions across the project lifecycle. The premise behind the recommendation is that 5 participants will discover 85% of the usability issues. Over 3 rounds of testing, you should pretty much catch all of them with a ...


12

What you've got there is a null result - there's no real difference between the two. Let's backtrack from the percentages to actual numbers. Control (127): Submitted search 44, booked 6 Variation (123): Submitted search 34, booked 4 Just by eye balling the numbers it's not looking terribly compelling. If just one person less in the control and one more ...


12

The biggest difference is User Acceptance Testing generally verifies that the deliverable meets the agreed upon requirements whereas UT seeks to verify an implementation's approach works for the user base. For example, a Usability Test might test a screen where a user needs to organize data and go through a simple work flow. The Usability Test will verify ...


11

Sometimes your users and frustrated but they don't know how to express it or they're too polite to do so. Their expression might show that they found that form annoying, even if they tell you it's great! In addition the "major" facial expressions have been found to be largely innate and not bound to cultures, in fact many animals display similar facial ...


11

Here is what I would do to have A/B Testing done on Existing Customers / People who already have my app: Both the flows of the App you have in mind should be bundled as a part of the same app. You use the code injection to send information to Flurry. Use the same method to check how many users have downloaded the latest version of your App with both ...


10

What was maybe the biggest surprise to me in the first few usability tests I conducted, that people really blame themselves when they're unable to complete a task on an obviously bad UI. And I still like to be reminded how little people know about some domains. For example, how little people care about banking or telecommunications, how little jargon they ...


10

Alex's question was how to test an API, not what makes a good API. Post-deployment monitoring seems critical to me. It's very hard, if not impossible, to know in advance what uses developers are going to want to put your API to once it goes live. Logging good requests tells you which features are popular, but logging bad requests and user support questions ...


10

The basics of UX work can be done by almost anyone willing to spend some time and effort learning how. Steve Krug's "Rocket Surgery Made Easy" shows that well. However that doesn't mean that everyone is a UX expert. Think of UX like painting a picture. Anyone can paint, and almost everyone can paint something decent with a little time and effort put ...



Only top voted, non community-wiki answers of a minimum length are eligible