While thinking about Kibbee's post (which is a response to Ryan's post) I was thinking about how dumb users are. Like Kibbee was saying when you ask for feedback on functionality, and all they can "see" are the fonts, colours, and other things that are really not that "important".
Let me digress for a moment. People generally recognize minor differences of how people act as dress as "style". No one agrees on style, but there is a pseudo "safe area" that people are able to slightly deviate from before it's "wrong". Let me provide some examples:
- wearing a baseball hat sideways is "style", wearing it on your foot is "wrong"
- wearing sandals to work is "style", wearing them with socks is "wrong"
These things are "wrong" because they are far enough away from my definition of style.
When I come across code to understand it, it has to conform to what I consider "correct" (or close enough) for me to understand it. I guess some people would call it style since the code could work the same way (from the api level) as something that I'd write. However, if the style of code is far enough out of my comfort zone, all I can see is "wrongness". If someone asks me to just ignore that "unimportant" thing, I have can't.
So when you're dealing with alpha testers, it may not be that they don't "get it" when it comes to providing quality feedback, it might just be that what you are showing them is so far out of their comfort zone that all they see is "wrongness". I can see how it's easy to get bogged down with the little tweaks, but if those are what is causing the barrier that's preventing your testers from giving useful feedback you're got 2 options: 1) get other testers or 2) just do the tweak. I suspect doing the tweak will take much less time than finding new testers.
I wouldn't say all the interface tweaks are unnecessary. Actually, they are very necessary to have a good product. However, in alpha testing, I think it's important to not worry about exactly how the UI works, and worry about whether or not you have all the right functionality. On well designed software, it's usually much easy to change and adjust the interface near the end of the project, than it is to change the underlying functionality. Let's say you're keeping a database of people. You spend all you're time programming the functionality, and then once everything is supposed to be feature complete, they decide that they want to be able to keep multiple addresses attached to a single person. Might not be difficult, depending on how you designed it, but not having that requirement, and thinking it was unneccessary, you might have made it difficult to add that feature. Instead of offering good suggestions, into the actual functionality they needed, they offer suggestions on the esthetic's, and end up with a product that looks nice, but doesn't really do what it needs to do.
ReplyDeleteI'm not sure that I got my idea across. I'm not saying that the users are just focused on the "look", I'm saying that they might not be able to get *past* the look to evaluate the functionality.
ReplyDeleteIf the look is far enough off from what they see as correct, then it becomes a "blocker" issue. It masks all other issues and you're not able to get the feedback from the users that you want.
This is more of an observation of myself and how I can't read code if the style is bad enough. I can't ignore it and just "move on" to looking for bugs.
Another observation about users: to them the interface *is* the application. They feel that suggestions about changing the interface *are* good suggestions. I think that if you say "don't worry about the interface, that's not important" they:
1) don't really understand how the interface is different from the application
2) might be less willing to provide more suggestions because you are dismissing something that they feel is important
I thought this post sounded familiar. Check out a blog post I wrote in October 2005:
ReplyDeletehttp://www.ryanlowe.ca/blog/archives/001373_fanconcert_dev_process_retrospective_1.php
I came to the same conclusion: too many usability or style problems can be a distraction for people and they won't give good feedback.
---
A software engineer's job is decoding user feedback into working software. Some of that feedback is very important, irrelevant or too early (like fine UI details). It's your job to listen to people and prioritize everything.
If you stop listening to your users and fixing things, they'll stop giving you feedback -- because what good is feedback that isn't responded to? If users are obsessed with the UI, obviously something needs to be done.
Having said that, you can "train" people to give better feedback as well -- when they give a list of things they think are "wrong", they are just going on assumptions they have made. In the alpha stages your vision of the software might not be obvious, so have a conversation with people. Also, it's useful for people to know what level of feedback you're interested in and what you're not.
Finally, keep in mind that YOU are the software expert. People can tell you when usability is difficult but it's your call on how to fix it. Most people don't know a thing about good usability (they just know bad usability), so specific feedback from them isn't much good. They should be concentrating on how well the software helps them to whatever task it's designed to do (workflow).
Good point. That's funny that you came to the same conclusion like 2 years ago and I'm sure that I read it. I gotta start retaining more. :-/
ReplyDeleteMy eureka moment was that *I* am a dumb user too... a dumb user of code. I suffer from the same types of distractions.
----------
On the topic of usability, I just finished reading "Don't Make Me Think!" (second edition) by Steve Krug. It came highly recommended from UI designers that I work with. Short, interesting and worth the read.
A couple of notes for that book:
1) have a common look so that people can figure out where they are
2) they have to quickly figure out "what" your site is
3) don't put "instruction text" because no one reads it
4) design for the web: people scan, they don't read
3) don't put "instruction text" because no one reads it
ReplyDelete4) design for the web: people scan, they don't read
I have big problems with these points. These kinds of people drive me crazy. If you aren't going to bother reading what's on the screen right in front of you to figure out what's going on, or aren't willing to do any learning, even for applications that you are going to use every day, or even just once a week, or maybe that you are only going to use once or twice, then, don't complain when the application spits out a wrong answer because you used it incorrectly. It sounds mean sometimes, but RTFM. People expect software to just work, and to be infinitely intuitive to the point where someone can sit down, and immediately understand it. To take an analogy from my current life, lets look at putting together a baby's crib. This isn't easy, especially if you just jettison the instructions and start bolting things together. Of course if you did this, and then the thing fell apart, people would say you were an idiot. The instructions are there, and you are expected to follow them. Nobody questions reading the manual in this situation. However, when people go over into the computer world, to something much more complicated than putting together a crib, like, let's say, using a spreadsheet program, they figure they shouldn't have to read anything they see, and everything should just work, regardless of whether they are entering the right commands, or to put it to the crib analogy, putting the bolts in the right holes.
Personally I don't read the instructions until I run into problems.
ReplyDeleteBefore using, I didn't read the instructions for my:
1) cell phone
2) router
3) microwave
4) cable box
5) nintendo
6) car
...
I don't think that it's a software thing that people don't read instructions. I think that it's a *people* thing.
I'm assuming that the crib instructions were more like pictures than a novel... If that was the case I'd say that those were easier to scan then read.
Intuitiveness in software takes time and effort to develop, constantly refining a design until someone new to the software can 'pick it up' quickly, usually without having to read a manual. Apple's hardware and software is probably designed for people to use without a manual.
ReplyDeleteIntuitiveness is a great design goal but it's not going to be there for early testers (how this discussion started).
You can waste effort doing too much usability and design early on (in alpha) -- because the overall function of the software can change at this early stage. For example, you could make a part of the software work beautifully and intuitively and then discover that it isn't needed any more, or it was replaced with another solution.
You have to balance that side of the argument with just enough usability and design that they don't become distractions to good feedback.
Agile development is efficient development: moving quickly as well as giving the users what they need to make the software useful to them. Sometimes you need to be destructive and get rid of code.
Mostly agile development is about solving the big problems first and then solving progressively smaller and smaller issues found by regular feedback.
I'll let you guys read the book, but I think that it's more along the lines of if the user goes into the "manager users" section of the application and there is an "Add" button, it's unnecessary to have text that says:
ReplyDelete"In order to add a new user to the system, please press the 'Add' button which will take you to the next screen where you can specify the username and permissions."
1) Don't add instructions if you don't need to
2) Make things as clear as possible. If you had called the button "create new user and rights". That takes more time to process and understand than "Add"
Please read the book if you can find it. It's short. ;-)