New answers tagged usability-study
Don't be misled by the term guerrilla usability testing. It basically just means that you are very creative in the way you gather your findings and willing to cut corners on the methodology as compared to traditional usability testing. There are two kinds of approaches to usability testing. You can test your design in one big bang, if you are pretty ...
You generally expect a button to show what action it will perform, not the current state of what it toggles. Consider the play/pause button of a media player. You press play-icon [ > ] and it changes to [ || ] to indicate the action performed when clicking again is now to pause.
Arrows pointing in our reading direction (right or down) point forwards. Buttons should indicate what happens when clicked. The arrow on a dropdown button should point right or down as it indicates new content will be visible once clicked. Once the dropdown has been opened, clicking the button again should close it. Therefore the arrow should point upwards ...
A button should show what will happen when it is next clicked - not point to something else. When the button above a closed menu is clicked, the content will drop down - so the should point down (to where the content will appear) When the button above an open menu is clicked, the content will move up into the button - so the arrow should point up.
Since you're asking about the direction of the arrow, you might like to check out the Microsoft standards for glyphs and arrows. Scroll down from here, to the table that lists the different types of arrows and glyphs. It says things such as this: Chevrons point in the direction where the action will occur, to show the future state. Arrows point in the ...
I would consider two things here: Visual connection to action Common standard implementation To the first point - visual connection: If you see an arrow that points up, you expect something to happen in that direction. You will automatically look up, not down. So every action that goes to a different direction will feel alien, detached. So this argument ...
I think input text (from)+ slider + input text (to) better solution. In this case you can set your own range without checking few checkboxes. But if you want minimize request on server each time when customer change slider range then you can add button "ok" in this case user set range - press ok - and see the results. See example
i"d say 1 of the two: 1: dont state the limit at all. When you finally can enforce, warn the "lower teir" users about the upcoming limits, giving them the option to Upgrade with great value... 2: inform your "lower tair" users that "You won a time limited free "higher teir" unlimited account." this ways turns the table in your favor i suppose.
Does anybody have any data that suggests that this can erode the trust the user has in a product, even if they are technically getting more than they were promised? This is only half the problem. The other half is that, 'some' customers that have been paying higher-tier may feel ripped off if they find out later out that their particular needs ...
If users sign up without knowing the limits and you suddenly enforce them, notified or not, people will be upset. The best thing to do is inform them up front, wether you can enforce it or not.
For qualitative research the general consensus is that 5 is enough for each task based usability test of an iteration, but definitely recruit new participants for a new task based test of an iteration. You may have already read this but it can all be found here: http://www.nngroup.com/articles/why-you-only-need-to-test-with-5-users/
Top 50 recent answers are included