Should usability research be performed through grounded theory--where results of a usability test determine how the product gets changed--or through traditional empirical theory (whether that is experimental, quasi-experimental, etc.), where the researcher begins with a specific question or hypothesis and tries to solve this through usability testing? What is tested? When testing in usability, is the item being tested? Yes. Is the user's ability to test the software being tested? Absolutely not.
How, then, does the usability researcher proceed to determine A) the product of the usability test (end result) and B) where the user fits into the usability test?
The product of a usability test should always be the tested item's improved capability to fulfill its intended function; how often should the intended function be adapted when users--who are very smart human beings, generally--use the item in an unintended-by-the-creator fashion?
Usability testing relies upon de-centering the user, giving the user no anxiety about how s/he performs, no leeway to consider whether or not s/he has a place in the product testing. Let me offer a sentence: "The user working with an item provides feedback on the effectiveness of that item's design toward fulfilling an intended purpose." "Working with an item" is the subject of this sentence--NOT the user; similarly, working with the item is the subject of a usability test, and combining multiple workings with the item provides results from which conclusions may be drawn (grounded) or that will respond to the questions asked.
I am fairly new to being on the testing side of usability testing; I've performed multiple usability tests as a user for various friends, and I've often discussed iterative design and usability in my work, simply because these are incredibly important issues in digital curation. But when I go to the testing side of things, I have to de-center myself, to recognize that I am not performing usability testing for any purpose beyond what the software is doing; the user and I (as the tester) are irrelevant and replaceable. What is important is the results of working with the item, and how I as a usability researcher structure those results back toward item redesign. There is not a third product that emerges from this researcher, for instance as a friend and I were discussing, improved software training; there is no room for a third product because usability testing is about the action performed with the item, and how combined actions contribute to an improved item.
Showing posts with label research. Show all posts
Showing posts with label research. Show all posts
Friday, January 28, 2011
Sunday, January 23, 2011
Learning through observation
I am enrolled in a usability research course this semester, and my first assignment for class was to conduct a site visit, to observe someone doing his/her job. This goes directly to usability research because, to perform usability testing, one must learn to observe users, must learn to pay attention to what users do--only to take in, not to assign value, criticize, or make judgment. Just to observe.
I greatly enjoyed the site visit, and I will post my write-up on here, if I get permission from the person I visited. I visited one of my former colleagues, to observe her as she created catalog records for materials; when we worked together, I never had time to do this--I was always simply a beneficiary of her labor, and I had no need to pay attention to how metadata in my system originated with this person. Now, I have learned the process that goes into creating a record--both creating a record for our own university's search engine, and a record with OCLC, that can be localized and adapted to other libraries' holdings. (I have lots of librarian friends who are welcome to post on the actual process that I watched; I'm just stating what I observed, in my own words. Please feel free to say, "You were watching this person do XYZ.")
What hit home even more to me was the goal of user observation. In understanding what people are doing, in recognizing how they make things happen--in whatever job they do, it matters not--could be making smoothies or making metadata--developing a habit of shutting one's critical brain off, that part of the brain that says, "This user did this badly, and should have done this instead, and that's how I would fix it because I know better,"--and being able to get into the habit of watching what people and respecting their work as people who use tools, teaches us how to perform usability research. Usability research is not at all about, "Here's what would fix this product." No. It's about, "Here is how this user uses the product. Here is how the product was designed," and then letting whomever hired the usability researcher know about user habits and design intents; it's not about making judgments and criticisms.
Iterative design--the constant re-evaluation of how users use a product to redesign that product--requires constant observation, constant taking in, constant understanding what people are doing with a product. Iterative design in software and websites is becoming increasingly important, particularly in terms of library/archive websites, which are constantly gaining new information, new data, and which aren't necessarily being redesigned to accommodate this new data. For instance, at ALA in San Diego this year--which I did not attend, merely heard about it--OCLC announced a new tool that harvests data from digital archives and allows their materials to be available on OCLC, which basically means that OCLC now recognizes digital materials (that have proper metadata and OAI-PMH harvest capability) as physical holdings at local libraries. This is huge--and now it is contingent upon local libraries to design their sites to be even more usable, and to constantly revisit their designs--iteratively design based on how users use their information--so that they can support the high traffic that will begin to appear.
It's an exciting time. Questions of quality metadata come heavily into play, and quality metadata will rely upon strong observation of how people search. Not observation with the intent of, "I can fix this whole situation because it's not currently usable," but observation with the intent of, "Here is how users are using this right now. This is what I'm learning and taking in."
I greatly enjoyed the site visit, and I will post my write-up on here, if I get permission from the person I visited. I visited one of my former colleagues, to observe her as she created catalog records for materials; when we worked together, I never had time to do this--I was always simply a beneficiary of her labor, and I had no need to pay attention to how metadata in my system originated with this person. Now, I have learned the process that goes into creating a record--both creating a record for our own university's search engine, and a record with OCLC, that can be localized and adapted to other libraries' holdings. (I have lots of librarian friends who are welcome to post on the actual process that I watched; I'm just stating what I observed, in my own words. Please feel free to say, "You were watching this person do XYZ.")
What hit home even more to me was the goal of user observation. In understanding what people are doing, in recognizing how they make things happen--in whatever job they do, it matters not--could be making smoothies or making metadata--developing a habit of shutting one's critical brain off, that part of the brain that says, "This user did this badly, and should have done this instead, and that's how I would fix it because I know better,"--and being able to get into the habit of watching what people and respecting their work as people who use tools, teaches us how to perform usability research. Usability research is not at all about, "Here's what would fix this product." No. It's about, "Here is how this user uses the product. Here is how the product was designed," and then letting whomever hired the usability researcher know about user habits and design intents; it's not about making judgments and criticisms.
Iterative design--the constant re-evaluation of how users use a product to redesign that product--requires constant observation, constant taking in, constant understanding what people are doing with a product. Iterative design in software and websites is becoming increasingly important, particularly in terms of library/archive websites, which are constantly gaining new information, new data, and which aren't necessarily being redesigned to accommodate this new data. For instance, at ALA in San Diego this year--which I did not attend, merely heard about it--OCLC announced a new tool that harvests data from digital archives and allows their materials to be available on OCLC, which basically means that OCLC now recognizes digital materials (that have proper metadata and OAI-PMH harvest capability) as physical holdings at local libraries. This is huge--and now it is contingent upon local libraries to design their sites to be even more usable, and to constantly revisit their designs--iteratively design based on how users use their information--so that they can support the high traffic that will begin to appear.
It's an exciting time. Questions of quality metadata come heavily into play, and quality metadata will rely upon strong observation of how people search. Not observation with the intent of, "I can fix this whole situation because it's not currently usable," but observation with the intent of, "Here is how users are using this right now. This is what I'm learning and taking in."
Subscribe to:
Posts (Atom)
