The Half Life team (A first-person shooter game) really knows how to get user feedback right. This is what they do:
For every scene in the Half Life series of games they develop, they write down expectations. When expectations don't line up with what playtesters end up doing, they know they need to do something. Examples: - We've developed this scripted sequence where an enemy gunboat appears but crashes into something. We expect the player to look at it. Many playtesters didn't, so we put a lone enemy with bad aim very near the point where the gunship appears so all players look there. - Players are supposed to use the gravity gun to pitch many bugs into the pit here. They didn't, and we couldn't find a natural way of pointing it out, so instead we added a bunch of precarious ledges on the pit which makes gravity gun pushing much harder, but that's okay, because almost nobody does that, and staring in abysses and fighting while walking on small ledges is fun too. - A non-player character is with you most of the way, and for the story line we want you to care a lot about her. During a sequence where plotwise you're supposed to hurry, but adding an actual count- down wasn't realistic and wasn't fun according to our playtesters (note: for enjoyment, you can outright ask - same for how nice your user interface is found, or how fast users THINK they can do stuff. Perception is at least as important!) - so we need to create a fake sense of urgency. We used to have that character lead you, and keep reminding you to hurry up, but that bossy behaviour got people angry at her quickly, which ruining the immersion in the plot later in the game, when she gets hurt. So, instead, she doesn't nag and follows close behind, and we semi-randomly blow up stuff and let stuff fall down or collapse close, but not too close, to you, to really give the impression this building is falling apart and you need to hurry up. We also removed quite a few puzzles to make sure the pacing is very fast. Then we added truly random sounds of explosions so there's no repetition that desensitizes you to it and keeps you on your toes. It's a combination of killing things that just cannot work, adding the littlest of touches to make sure users do what the designers intended, and making changes in spirit to roll with what users are actually doing whenever that seems like as good or better an idea as what the designers had in mind. There's definitely no "Ask the user what they want" in there - which indeed never gets you to the true innovations (but its still an improvement compared to much of what's out there!) I think the general halflife approach is very sound: As a developer/ designer, write down how you think a clueless user is supposed to go about discovering and using a certain feature. Then see if the expectations match up. If not, try to figure out why not, and be very flexible in how you align expectations with reality (hint the user, make a tweak, take a completely different approach, or kill the feature entirely / implement different but similar functionality). You develop the basics of the design, you don't let your users do it, but once YOU decide 'multi touch is the way to go', for example, then making this work properly becomes an evolutionary process that bounces between you thinking up something and your interface testers dictating the direction in which you evolve the interface. Nobody said this was going to be easy. On May 30, 9:59 am, Michael Neale <[email protected]> wrote: > Not surprisingly, Apple spent big money on researching this in the > 80s: > > http://www.asktog.com/TOI/toi06KeyboardVMouse1.html > > that is a good example: people say keyboard shortcuts are faster, > stopwatch (for same users) shows mouse is faster (this was some time > ago now - 20 years since 1989 ! WOW !). > > On May 30, 3:51 pm, Joshua Marinacci <[email protected]> wrote: > > > That wasn't my intent. Good designers are no rarer than good > > engineers. It requires a good mix of talent and skill. What I meant > > about ignoring users is this: You must listen to your users but you > > must also watch them. People often say something different than what > > they actually do. And people will ask for a feature because it seems > > logical to them, not because it's actually the best feature. After > > all, they aren't the feature experts: you are. Often, once you show > > people the right answer, even if it's not what the asked for, they > > will love it. There weren't millions of cellphone users clamoring for > > multi-touch phones, but once people saw the iPhone most of them loved > > it. When to listen to your users and when to ignore them (but still > > address their concerns), requires skill and experience, but it > > definitely can be learned. Usability is as much about anthropology > > and psychology as it is about computer science. > > > - Josh > > > On May 29, 2009, at 5:24 AM, Reinier Zwitserloot wrote: > > > > Never thought of it like that, Joshua. Huh, this thread is kind of > > > making it sound like being a good designer is a rare feat reserved > > > only for those akin to a deity on this world. Eh - practice makes > > > perfect, I guess. I do stand by my point that in many cases, people > > > weren't even trying, and if you do try, you'll get something passable, > > > even if it isn't quite perfect. > > > > On May 29, 8:14 am, Joshua Marinacci <[email protected]> wrote: > > >> Part of the art of UI design is knowing when to listen to your users > > >> *and* when to ignore them. Most of the many UI flaws in Windows > > >> remain not because Microsoft's designers are unaware of them. :) > > > >> On May 28, 2009, at 9:52 PM, Michael Neale wrote: > > > >>> OH, also, and when you fix something, there will be the 10 angry > > >>> emails from people who don't like it now, who liked it then, or > > >>> don't > > >>> like change, or just like to write angry emails. > > > >>> You know when Toyota changed the Landcruiser from having a basic > > >>> metal > > >>> dashboard to a modern one they got death threats ! > > > >>> On May 29, 1:09 pm, Ryan Waterer <[email protected]> wrote: > > >>>> I think that you hit upon a very important aspect of good design -- > > >>>> that it > > >>>> is consistent throughout the user's experience. If even one part > > >>>> of the > > >>>> experience is less than satisfactory, then the designers have > > >>>> failed. The > > >>>> user walks away with a bad taste in their mouth. > > > >>>> I'd love to hear Josh's thoughts once JavaOne is over. Best of > > >>>> luck! :) > > > >>>> --Ryan > > > >>>> On Thu, May 28, 2009 at 8:49 PM, Reinier Zwitserloot > > >>>> <[email protected]>wrote: > > > >>>>> Here's a fine example of how clearly somebody wasn't even thinking > > >>>>> straight. This is linux, doing a major update in ubuntu. Just a > > >>>>> few > > >>>>> things sprang to mind: > > > >>>>> The theme: Every so often I get a dialog box that tells me that > > >>>>> I've > > >>>>> changed some settings file and now apt-get doesn't know what to > > >>>>> do; > > >>>>> replace, keep the old one, attempt to merge it. This dialog is so > > >>>>> ridiculously insanely stupid that I don't get why microsoft isn't > > >>>>> showing this to the world and going: TADAAAAA - linux is an > > >>>>> amateur > > >>>>> toy that doesn't deserve to play in the real world. It's that > > >>>>> dumb. > > >>>>> We're using a gui based updater here that's just a light > > >>>>> frontend on > > >>>>> top of apt-get, which is a package manager that basically knows > > >>>>> dependencies and works it all out for you, and can even update > > >>>>> packages by taking down the service, replacing the files, > > >>>>> integrate > > >>>>> whatever changes to the settings files are required, download and > > >>>>> install all dependencies, then take the service back up. That's > > >>>>> quite > > >>>>> a feat, and apt-get is really cool. It's probably the principal > > >>>>> reason > > >>>>> why debian is cool, and ubuntu ate redhat's lunch (redhat uses > > >>>>> rpm, > > >>>>> which can't do all that). Now that you know, let's move on to how > > >>>>> this > > >>>>> fantastic tool turns into unbelievable suck, just because of bad > > >>>>> user > > >>>>> interface design. Compared to the mind boggling effort that goes > > >>>>> into > > >>>>> maintaining all those packages, keeping a fleet of mirrors running > > >>>>> to > > >>>>> serve all of them, and the effort that went into the technical > > >>>>> design > > >>>>> and development of the apt system, this is small fry: > > > >>>>> [ simple stuff that's easy to fix and should assault your senses > > >>>>> immediately. This isn't the kind of Joe Nuxoll style thinking > > >>>>> out of > > >>>>> the box stuff, just general: We need to make sure our user > > >>>>> interfaces > > >>>>> aren't explicitly out to shoot the user in the foot] > > > >>>>> A. it's an enormous dialog box that's totally empty, except for 1 > > >>>>> dropdown box. Anyone remember the microsoft shut down dialog > > >>>>> drama? > > >>>>> the entire screen as real estate, and you hide the important bits > > >>>>> in a > > >>>>> -drop down box-, that you have to click. WTF? Dropdown box > > >>>>> contains > > >>>>> the same 5 choices every time. Opening it just opens it across a > > >>>>> sea > > >>>>> of grey. If you're thinking of user interface design even a > > >>>>> little, > > >>>>> the first time you as a developer see this dialog box, you should > > >>>>> file > > >>>>> a 'critical' bug or fix it then and there. You don't let piss like > > >>>>> that go out into the world, period. > > > >>>>> B. One of the times the dialog box popped up it didn't even > > >>>>> have a > > >>>>> sensible file name. I had absolutely no idea what I was supposed > > >>>>> to > > >>>>> 'keep', 'replace', 'integrate'. > > > >>>>> Now lets dig deeper. We know that apt more or less forces this > > >>>>> situation, if you have any experience with the text output of the > > >>>>> apt- > > >>>>> get tool. But, even with the way apt works, we can do a better > > >>>>> job, > > >>>>> even if we're still not in Joe Nuxoll think: > > > >>>>> C. Give me the full path to the settings file, show the diff > > >>>>> between > > >>>>> the old and the new, and offer me an option to manually integrate > > >>>>> the > > >>>>> files. > > > >>>>> And now for the big whammy, let's redesign this entire thing so > > >>>>> that > > >>>>> it's actually, you know, usable by a mere mortal: > > > >>>>> D. There's such a thing as file system hooks. Apple uses it in > > >>>>> place > > >>>>> of a registry; all applications have a file in them that explains > > >>>>> which files they can open, and everything you put an app on your > > >>>>> harddisk, a system hook reads this information and makes sure > > >>>>> that, > > >>>>> when you right click on such a file, that app shows up in the > > >>>>> 'open > > >>>>> with...' dialog. There's neither a registry (windows) nor a big > > >>>>> settings file (linux) to worry about. When you delete the app > > >>>>> (there > > >>>>> are no uninstallers on os x, just delete it), the file system hook > > >>>>> removes that app from open with lists. You can apply the same > > >>>>> tactic > > >>>>> to settings files: *ANYTIME* I mess with a settings file, apt > > >>>>> should > > >>>>> be called so that it can inspect what I just did, see if it can > > >>>>> automatically integrate that change with a possible future update, > > >>>>> and > > >>>>> if not, back up the previous version, and send me a mail (or > > >>>>> better > > >>>>> yet, if we're on a GUI, show as I try to save it) how I can fix it > > >>>>> or > > >>>>> where I can edit it so that it does integrate properly. Note that > > >>>>> all > > >>>>> major linux file systems offer this feature. > > > >>>>> NB: For many apt-get installed tools, the settings file for that > > >>>>> tool > > >>>>> is managed by apt, but it 'includes' a special file that you can > > >>>>> safely edit without setting yourself up for future pain. However, > > >>>>> most > > >>>>> manuals on configuring the tool aren't debian/ubuntu aware and > > >>>>> point > > >>>>> you to the file you're not actually supposed to edit. Often there > > >>>>> are > > >>>>> some remarks in there by the debian package maintainer that you're > > >>>>> not > > >>>>> supposed to edit this file, but, yeah, as if I'm going to read all > > >>>>> of > > >>>>> those! How perfect would it be that, on saving, apt-get runs in > > >>>>> the > > >>>>> background, automatically diffs my changes, and tries to > > >>>>> automatically > > >>>>> move them to the right properties file, -or-, mails me this plan > > >>>>> so I > > >>>>> can confirm or deny it. > > > >>>>> E. Upgrading debian or ubuntu takes a day or two. That's because > > >>>>> for > > >>>>> every conflict and settings problem you get a dialog box. I'm not > > >>>>> going to sit and stare at my computer for the 1 or 2 hours total > > >>>>> runtime it takes to process all updates, so what ends up happening > > >>>>> is > > >>>>> that it just sits there, idle, showing a dialog box, and every > > >>>>> hour or > > >>>>> 3 I check in, turning the process into a long and painful process > > >>>>> that > > >>>>> I loathe. There's no excuse here: the gui tool (and probably apt- > > >>>>> get > > >>>>> itself) should figure out all conflicts beforehand, and toss all > > >>>>> dialog boxes my way BEFORE starting the actual process of > > ... > > read more » --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/javaposse?hl=en -~----------~----~----~----~------~----~------~--~---
