- This topic has 9 replies, 10 voices, and was last updated 8 years ago by
.
-
Posts
-
What is the best practise for usability testing? I’ve read suggestions before that you should read everything and look at everything but is that the case? How important does usability rate in terms of testing a product? And is usability different from UX?
The best practice is to let users test the software – starting with a scaled down, not yet very functional interface design prototype.
Use tools to learn what users do, what they avoid and where they struggle.
Improve the design.
Rinse and repeat.Where I have seen usability testing done best was when it was managed by people with anthropology and social sciences backgrounds. – It’s all about people.
@jesper-lindholt-ottosen That’s great that you have such opinion <3 I’m a tester with cogsci and anthropology background and I use that wide perspective every day 🙂 from observing the scrum meetings to advising in frontend behaviour and erorr validation.
Even today I put a suggestion to make diverse error markups, not just letting the users READ the error content – because as mobile app user who e.g.is walking the street scrolling contents on smartphone – I don’t want to read things when using app, I want to see them at once 🙂I agree with @kasper, user will be the measure and guidance to improve the usability of the product. Usability is a key aspect of the software, if user cannot use it, is hard to have the desired impact, otherwise it will be needed a lot of specialized consultancy that client/users not always have available. Better is an easy and simple to use software, with the corresponding technical info written available for more details.
Interesting topic.
I did not know about the difference between Usability and UX, so had to google it. (my fav explanation among Searched results : http://www.slideshare.net/domain7/ux-vs-usability)
Important best practices are already laid out here, 1 that I would like to add, is to prepare “wireframe” and share it with end-users. It serves two purposes,
1 -> It works as illustration.
2 -> Changes in wireframe is in-expensive and the end-user is on board with the idea. Behavioral feasibility, factor is also checked via this practice.Hi Swasati, nice article explaining the difference between the two. Even I was not aware of it 🙂
I would say that UX as we see it today includes usability testing.
A lot of the most recent work around UX, removes it from the realm of testing and puts it more into the world of the customer and the people that work with the customer to build the product.
What in the old days was a detection activity, it has moved, in line with lean and agile practices, towards the dimension of build usability in through short and early fast feedback loops with real customers.
I am particularly impressed with the work of Geoff Goethelf around utilising the power of the full delivery team to design a UX strategy for our products. Far away from the more commonly known designer-centric approach.
Geoff, in his book, Lean UX ,describes this approach clearly and with very useful and easy to follow examples and practices.
I’d recommend Geoff’s book and if you get the chance, also to go and attend his workshop on the same topic. I personally attended it earlier this year and it was worth every penny.
Just to clarify, I do not work with or for Jeff and do not get any income from the sales of his book or his workshops.
Usability testing is very important and I completely agree it’s about people. Things never change though. These 10 steps are based on Jacob Nielsen’s Usability heuristics released back in 1994….
1. Visibility of system status: The system must always keep the user informed about what is going on. This is done by feedback within reasonable period of time. From a testing point of view, it is necessary to understand, define and quantify ‘reasonable’.
2. Match between the system and the real world: The system must speak the users’ language, using familiar words, phrases and concepts. It must avoid using system- oriented ‘jargon’. It is necessary to follow real-world conventions as much as possible, making information appear in a natural and logical order.
3. User control and freedom: It is a fact of life that users will often make mistakes. This creates the necessity for needing a clearly marked “emergency exit” to leave the unwanted state without having to go through an extended procedure. It is important that the application supports ‘undo’ and ‘redo’ facilities.
4. Consistency and standards: Users should not have to wonder whether different words, situations, or actions mean the same thing. The specified platform conventions need to be followed, allowing a user to be comfortable with the ‘look and feel’ of the system.
5. Error prevention: Even better than good error messages is a careful design, which prevents a problem from occurring in the first place. When error messages occur, they need to be necessary, or alternatively be avoided by better design.
6. Recognition rather than recall: Objects, actions, and options need to be visible. The user should not have to remember information from one part of the dialogue or process to another. Instructions for use of the system should be visible or easily retrievable whenever the user requires them.
7. Flexibility and efficiency of use: The system needs to be as flexible as possible for differing levels of users. It is sometimes useful if experienced users can tailor frequent actions. Accelerators, unseen by the novice user, may often speed up the interaction for the expert user such that the system can cater to both inexperienced and experienced users.
8. Aesthetic and minimalist design: Dialogues should not contain information, which is irrelevant or rarely needed. Every extra unit of information in a dialogue competes with the relevant units of information and diminishes their relative visibility to the user.
9. Help users recognise, diagnose, and recover from errors: Error messages should be expressed in plain language and contain no codes (unless as part of an error message that may help the troubleshooting process). They must also precisely indicate the problem, and constructively suggest a solution.
10. Help and documentation: Even though it is better if the system can be used without documentation, it may be necessary to provide help and documentation. Any information should be easy to search, focused on the user’s task. It must list concrete steps to be carried out, and not be too large.
The important thing is to watch and understand what users actually do. Do not believe what users say they do. Definitely don’t believe what users predict they may do in the future. People don’t want to compute. They want to write reports, find information, create art, prepare budgets, manage their schedules, and send messages to one another.
Take a look at my article from back in April 2004….
http://www.professionaltester.com/magazine/backissue/18/ProTesterApr2004-Ambler.pdf
Chris Ambler
What a delight that Usability is discussed already prior to the conference. I already see quite some good references in this topic. If you are coming to Eurostar I’ld be more than happy to chat about it. Also on wednesday my talk will be about usability testing and more input from the user in testing. Come and visit and let’s chat https://conference.eurostarsoftwaretesting.com/conference/programme/2016/#event-140
- You must be logged in to reply to this topic.