Jeff, no new achievements (that I know of) have actually been released for the medic. All that's happened so far is that someone found a bunch of logos & names for medic centric achievements.

Evan, but they *have* announced that achievements will be released. Also, IIRC the article I read stated the medic will be the first class to receive new weapons, which are unlocked when you reach a certain level of medic specific achievements.

>I suppose this is because Medics don't engage in much direct combat, so >they're not as exciting to play as, say, a Demoman or Soldier.

The other factor amongst gamers is that Medics/Healers are the first to be targeted and killed making them more frustrating to play.

>The other factor amongst gamers is that Medics/Healers are the first to be targeted and killed making them more frustrating to play.
Oh I'm not so sure... often they are hard to get if they are behind a spamming Heavy. And players are often targeting the Heavy, because they don't know better.

That was an awesome post! You put into words what I have been thinking/doing (and not necessarily succeeding at) over the past year.

Henry Ford said something like: "customer's can't envision the future, but they inform the present."

Nobody plays medic because the class got butchered in transition from TFC to TF2.

> The other factor amongst gamers is that Medics/Healers are the first to be targeted and killed making them more frustrating to play.

Heck, there's even a T-Shirt on this...

http://www.pennyarcademerch.com/pat070411.html

one of the things I use to help improve the software i write for my school is an error email account. i wrote an error class to send the details of errors to that account. i and the support staff can check that account and use the data to be proactive about fixing bugs and also as objective data to accompany help tickets that may stem from the bugs. we usually find that the source of the problem is users doing things we never expected them to do. it's an invaluable tool.

Hey Jeff. Cheers for the link back to ubercharged.net. Been following this blog for a while, but mainly from the day job coding side of things. Saw the link coming in when I was checking stats, and did a double take when I saw it was linking to my TF2 blog (my other blog is about coding at www.rawblock.com , but is in a state of a little disrepair at the moment), weird how the interweb works sometimes.

The new medic achievements have been due to be released in the "coming weeks" for a few months now. I guess that's running on valve time ( http://developer.valvesoftware.com/wiki/Valve_Time ), so it means we'll see a release any time in the next year or so :P

Take privacy into account of course.

Great post, I agree with a good deal of it. After working in sales for a while, I have learned that people say what they think that they want, but not what they need. You need to qualify responses that you get from users so that you truly understand the needs, instead of just blindly running off to meet their wants.

A great example of where "listening to the users" leads to very poor usability is the one and only: Microsoft Live.

I think you overstate the point that listening to users is a bad idea. In particular, the Team Fortress 2 argument doesn't really support your point of view. I actually play Team Fortress 2, as do some of my friends, and ask any of us why we don't play medic and you'll get the same answer without even having to gather detailed statistics.

Medics are the bitches of the game. They don't get to do much combat, and they get yelled at if they don't heal everyone who needs it, even though the best personal strategy for them to get more points is to stick like glue to one player. They spend all this time charging up their uber, which seems like it should be cool, and then what do they get to do with it? More holding the button down on the medigun, only this time instead of healing, it makes you invulnerable. Because actually letting them participate in combat with a super attack would've been too cool.

Your example on the Halo maps does support your argument. But Team Fortress 2 doesn't.

Although I agree with your post, I want to point out that adding 1920 x 1200 or 2560 x 1600 resolutions is usually nothing more than a menu item, an extra enumeration member, and two extra lines of code.

A comment on your example of Valve's hardware survey - it's also important to know how the data was gathered. In this case I believe the Steam application took the specs outside of game time, that is, in the background while you're doing your everyday tasks. In my case my computer (a laptop) is usually connected to a 1900x1200 screen which is fine for coding and desktop use, but for the newest games I usually drop it down to 1024x768. However, this means that I'd be reported as having 1900x1200, which wouldn't be so useful if they're deciding what gaming resolutions to support.

This medic argument brings up an important point. When you have data like this, how do you decide between multiple hypotheses of what the user actually needs?

Clearly, there are at least two competing arguments as to why the medic class is the least played. (This is just my interpretation from the comments here. I don't play TF2.)

1) Balance. The Medic class has fundamental weaknesses that contribute to a low desire for players to play this class that are best addressed by changes to the classes abilities.

2) Learning curve. The Medic is balanced, but is simply difficult to play. The best way to address this is to add additional achievements to reward skilled and dedicated Medic players to help them get through the learning curve.

3?) Fun factor. The Medic is balanced, but game play elements are not as fun as other classes. People like achievements though, give them those, because re balancing is hard, and costly to get right.

That 5.5% number simply doesn't provide enough information about what is going on. It would be interesting to see what the real process was to arrive at the answer they did. The canonical way to do this would be to gather some new data, designed to test the competing hypotheses, but in my experience this tends to be an "expert's" call. Time is a finite resource, so people tend to make do with the data they have.

I suspect part of the lack of medics is the results of the third and sixth charts, "Average kills per class per hour" and "Average lifespan per class in minutes" where medics are also at the bottom. I wouldn't play the thing where I get the least kills and die the most, either.

Your users are experts in what problems they have. But not necessarily experts in solving the problems.

"Listen to your users" is still a different concept to "outsource your entire product design department to the most vocal disgruntled user you can find".

You're conflating two issues. You MUST listen to your users, but you need to understand their needs. They DO know what they want. Sometimes what will make them happy doesn't even make sense, or no matter how wrong they are, sometimes they won't be satisfied until you give them something they don't need. There's just no way around that.

Great Article!

I have stumbled and watched so many others as well who "listen" to their users too much. Designing what the user says they want, rather than really listening, understanding and designing what they really want.

I still struggle from time to time, but life has become so much easier now that I listen correctly.

I think Apple does this well... think about it. The original pre-iPod user wants was something probably close to "I want to listen to my music, let me view any song, any album, sort, shuffle, pause, play and million other things, all with buttons" I can imagine a blackberry style amount of buttons to do that if handled by someone else (and I think I have bought some...), iPods really has only 2 buttons, sure one is more like a touch pad, but it is very very simple, and is easy for people like my parents just to hit "Play", while I am able to (using iTunes) create complex playlists to let me play graded songs from certain genres, periods of music and artists. It does anything I can think of (for the most part) and yet meets the "do not make me think".

Don't listen to your users, but pay attention to how they use your software.

Don't listen to your users, but pay attention to how they use your software.

It's been a while, but Great post! Waiting for stuff like this to come up is why I keep returning here :)

Now this article covers just what I meant back when the UnitTest/UsabilityTest article came out a few weeks ago.

As engineers we can get solid numbers about usability and this will almost always trump some designer's intuition and sense.

This is why I always look at my users using what I make, and why I always use my own stuff for a while before handing it out to others. We can eat out own dog food before having to force my customers to eat it.

What if we listen to what the users say, observe what they do, and carefully merge them.

This post has come at an extremely useful time - so thank you Jeff.

At uni, we've just been given basic design specs for a team project we have to work on over the course of the year for an outside client. As this is all of our first real-world applications that we're going to be developing, it's really helpful to have some ideas behind us that'll help us build a more useful system.

Cheers Jeff.

I guess it's hard coming up with a title, but the titles suck lately, and as others point out, issues are conflated. Lately, this blog feels like it just doesn't take itself seriously. Pretend we're all doctors or something, would you discuss medical advances and research in the same tone?

(sarcasm)
I Repeat: Don't listen to your patients. Patients never know what's really the problem. They just sit there and complain about a sore bum and headaches and stuff, and never seem to be able to run up their own bloodwork. Man patients suck.
(/sarcasm)

Don't JUST listen to your users is more apt.

As usual when universals are made and rejected, reality lies in between.

While it's generally true that users don't know what they want/need, it's also often true that some of them have very insightful ideas about how to improve things.

Also, your most vocal users can also be your most vocal supporters. Simply ignoring their complaints/suggestions may hurt your user base.

One more point, the game design domain may not be as closely related to the web design domain. The designers and users are different in significant ways. (Successful) game designers are a lim

As usual when universals are made and rejected, reality lies in between.

While it's generally true that users don't know what they want/need, it's also often true that some of them have very insightful ideas about how to improve things.

Also, your most vocal users can also be your most vocal supporters. Simply ignoring their complaints/suggestions may hurt your user base.

One more point, the game design domain may not be as closely related to the web design domain. The designers and users are different in significant ways. (Successful) game designers are a very limited subset of programmers. They have already proven they can build a popular and usable system -- opposed to all the games that fail in development. Web designers and developers are both numerous and have a lower bar to pass. The users tend to be a bit more hard core, perhaps younger, and a bit less "insightful" in their comments than general web users.

That said, your point should is well taken -- ethnographic analysis of users (both in the lab and in situ) should always be a major part of application design and revision. "Watching what they do" is a critical of the usability puzzle.

Jeez... so much for editing in a text entry box:

That said, your point should be well taken -- ethnographic analysis of users (both in the lab and in situ) should always be a major part of application design and revision. "Watching what they do" is a critical piece of the usability puzzle.

The point is to listen to you user's needs, but professionally advise their decisions

<a href="http://www.wxkndr.com/intro2.html" title="&#30789;&#27233;&#33014;&#30005;&#28909;&#26495;">&#30789;&#27233;&#33014;&#30005;&#28909;&#26495;</a>
<a href="http://tichemin.com/" title="&#21270;&#24037;&#26426;&#26800;">&#21270;&#24037;&#26426;&#26800;</a>

I think its difficult to find feedback channel on Google site. There is some, but I didn't find actual pure plain feedback form. Did I just miss it (bad user interface) or there isn't such? I think they would do better if there was the feedback form even if they didn't read the feedback, because now they got me angry because I searched and searched wasting time but didn't find.
http://www.google.com/intl/en/contact/index.html

Then again Microsoft MSDN forums take feedback and they even have a forum category for feedback, but nothing seems to happen to the sinking ship. Waiting continues.
http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=2799857&SiteID=1

Don't believe the steam-resolution data.
Many players lower the resolution before playing Half-Life 2 in order to gain better frame rates. On a notebook with a poorer graphic-card some will even lower to 800x600.
I've seen for years no one who uses 1280x960 - most people use today 1280x1024 (or 1280x800 on a notebook), as webstats show. This fact shows that the Steam-Data is totally wrong.
And don't underestimate marketing: Fulfill the wishes of the high-end, because these are the opinion-leaders, who write in blogs or magazines.

"There's no need to directly watch users (although it never hurts) when you have detailed logs showing what they actually did."

Logs only show what people have done... watching the users directly gives you an idea of how quickly they made decisions (bad/confusing UI), and you get an idea what they were trying to archive at the time, compared to what they actually did.

For example... logs which show the hit count for a websites site map, don't show you if the user went there by mistake, or if they chose that route because the navigation bar was not understood.

It's all about the gemba.

Also, extra resolutions can go way beyond being an extra menu item. You have to make sure everything looks as good at high resolution as it does at medium res - that means high quality artwork that most people won't see - and there are the performance implications. An engine may be great at something like 1200x1000, but does it scale to 1600x1200?

I just like to point out to NurseRatchett that the whole (sarcasm) (/sarcasm) thing was not needed. We got the point. Listen to me - I'm a user.

"I actually play Team Fortress 2, as do some of my friends, and ask any of us why we don't play medic and you'll get the same answer without even having to gather detailed statistics."
That may well be true, but in this instance looking at a 5% figure is much quicker in highlighting the problem than collating many responses, most of which won't be in direct communication with Valve but instead spread around many forums (which, as I understand, they do look at quite a bit). Once you can see a problem, you can ask the direct questions such as "Why aren't you playing as Medic". But if you just asked people who gets played the most, whilst I would have said Medic barely gets played I would also have rated spies much higher. Other people would similarly skew figures based on their own experiences, which class annoys them the most, which they think are most valuable etc.

I've found it works best to listen intently to your users, take notes, nod knowingly, promise to do everything the user requests, then go do the software the way you know it needs to be done and later try to convince the user that's what they asked for...

I think the key is to ask whether you have *enough information* about the phenomenon you're studying and whether that information is *reliable* or not.

Any data can be relevant (user feedback and statistics included), but if you don't collect the correct data (or enough of it), any action you take will be based on guesswork and personal experience.

Most poor HCI choices are made by people who

- don't really know what it is they want to know
- asked the wrong questions
- asked too few questions
- have chosen whom to ask inappropriately, or
- think the data they collected has more information than it really does

In the application I've been working on for the last three years, we implemented two features that turned out to provide "Big Brother" type usability observation. This is a mainline business application, not a game, so it should show how this is feasible in just about any application.

1.) An internal audit trail. Every change that the user makes to any data in the database is recorded in a database table that records the following data: the date & time, the original table that held the data, the column name of the field that was changed, the original value, the new value, the page it was changed from, and the user who made the change.

What this did for us was unintentionally reveal *which* features the users were actually using. We found that the most used feature in the application turned out to be one that was added late in the development cycle, as an afterthought at the customers' request. It got a lot of attention in the second release iteration.

It also tells us which users are actually using the system. During testing, it tells us which features actually got tested. For defect resolution, we can see how data was changed, and what data a user was working with when an error occurred.

2.) An internal event log. Any time an exception is thrown, it's recorded in this log. Any time a user logs in, it's recorded in this log. Any time a user uses the Log Off button, it's recorded in this log.

This tells us which users are actually logging into the system, and how many are logging off correctly as opposed to just letting their sessions expire. It also gives us the detailed exception information without having to scrape the Application Event Log in Windows. Because the table includes the ID of the user who was logged in at the time and the date and time it was thrown, we can find relevant information in the Audit Trail at the same time.

Jeff is absolutely right: where errors and usability problems occur, you just can't rely on users to provide accurate feedback. No one is *actively* thinking about those details when you ask them about them. Or, they want to present the best possibly face to the developer (who frequently intimidates them) when they're asked.

Hey Now Jeff,
After reading this it reinforces the importance of UAT (user acceptance testing). When there are testers that look from a users perspective rather than just a quality assurance perspective the produced application is going to be better, even if its something small such as tab order on a login in screen. Nice post.
Coding Horror Fan,
Catto

Yay, Nurse Ratchett - beautifully put. It's no big secret: Use what data you can get (advisedly); use what user feedback you can get (advisedly).

And "advisedly" applies to both. Eg maybe your feedback *does* show that they used one particular feature more than others, but, oh I dunno, maybe the other features were too complex for them to understand, so they abandoned trying to use them?

The best way to get user feedback is not just to log them, or listen to them, or even to watch them use it, but to watch them use it *having asked them to speak aloud their thoughts as they do*. You will learn ten times more about what is wrong with your product this way (and it will stagger you what's going on in normal users' heads - that sure ain't your System Model that they're working to).

As a designer, not a coder, I have an alternative headline for you:

*** Do Not Listen To Your Techies. ***

:-) because what techies (and marketers, and...etc) think is a good idea at the UI/feature level usually isn't, until you have an idea of what is really going on in normal users' heads. Turn yourself into a half-decent designer by finding out: spend some time doing this *spoken aloud* user test with some normal users (using your early version, or using competing products, or whatever relevant that you can get hold of). It will change your life - and, hopefully, the lives of your future users.

Of course, few self-respecting techies ever do this - you'll typically just say to yourself "yeah, sure, but I'm not that bad, I think I understand normal people pretty well, and we do get user feedback, so, no problem, continue as before". Mean time, normal people are having a truly horrible time with technology, and just hanging in there doing whatever they've managed to get to work, too scared to change or add anything in case that breaks their current tenuous usage.

Snappy headlines are the order of the day, so I can't go with "Do Not Listen To Anyone Who Doesn't Sit Through Some Spoken-Aloud User Tests In Order To Discover The Real World Of Users". But since 90% of the people who design and affect the UI/features of tech products are indeed techies, and who *don't* do this, let's go with it again:

*** Do Not Listen To Your Techies. ***

Another developer I worked with told me about a story from World War II where the Allies wanted to address the loss rate of planes from bombing missions, which was in excess of 50%. They went to study the planes when they returned to determine where the planes were being most damaged and worked on reinforcing those areas.

However the loss rate did not improve. The problem was that the data they had was from the planes that did make it back. Their damage was in the non critical areas to begin with. The data they needed was for the planes that were lost.

The point about data collecting is good, but make sure you have the right or relevant data is key.

I agree 100%. Your examples are gaming based but your points are especially true in my experience with business software.

At my company we have a periodic user/developer meeting to discuss improvements that can be made to our proprietary systems. Without fail about 75% of requested features are never supported by our data. And whenever we are required by the powers that be to add the new features, regardless of what the data suggests, the features are inevitably not used and eventually forgotten about.

Your article is well timed as I have been compiling data the past two days which debunks one such request.

One more comment on this. My comment above is presupposing that good, objective analysis is being used when designing and building systems to begin with and not overemphasizing any one source of info such as data or user input.

That being said, one of the best bits of advice I ever received regarding user feedback during analysis is to ask the user why five times. (The actual number of why's will obviously vary depending on the situation but the basic principal is sound.)

If a user tells you something isn't working properly or that something would be better if it work another way, be sure to dig down far enough to get to the true root of the issue. And this is best accomplished by asking open ended questions, like why. It gets through all the fluff and does not lead the user in one direction or another.

Isn't that listening to users anyway? In the examples given, developers weren't literally asking them for feedback or feature requests but they were 'listening' anyway?

This whole article basically boils down to two (fairly) well-known quotes:
"Actions speak louder than words" - unknown
"One accurate measurement is worth a thousand expert opinions." - Adm. Grace Hopper

I personally love the medic class. If your team has a medic and the other doesn't that usually makes the difference in winning vs. losing.

great post! spot on IMHO. my friends and i just launched a website and we're looking for some user feedback. we're also interested in seeing how user will really use our site. we're in a private beta period right now but if you check it out and enter you email address, we'll get you approved usually within an hour. www.createdebate.com is the address. sorry for posting a plug but, seriously, i can really relate to this blog post. thanks.

I'd mostly agree with this. Generally when I go talk to users, it is to educate myself enough to *become* a user like them. Then I can see what needs doing, what needs streamlining, reorganizing, rearranging, etc.

If you simply listen to them and do whatever they ask, you end up throwing tons of unrealted new features onto whatever their favorite screen or tab happens to be. A user doesn't really know what the possibilites (and difficulties) are for the software, so you can't expect them to design things for you. So you shouldn't let them.

Excellent post Jeff. I must admit I'm guilty as charged of believing that user feedback was king of kings. When I did watch a user use one of my applications it was only to mainly see if any bugs would crop their ugly head up in my program. I'm glad that I know better now. With actual DATA to look at AND listening to user feedback I can pick out the more overly critical users from the sane ones. Thanks a million.

One of the trickiest things about managing my personal project (Migratr) online has been learning to filter user input. I have a confirmation "Do you really want to do this?" dialog setup for a fringe case that most people hit by accident instead of intentionally, and one user claimed it was "annoying" and I should just get rid of it. That's the first time I recall ever telling one of my users "no". Not "I'll consider that for future release", just "I'm not going to do that." He wasn't a troll or impolite or anything like that- he actually had a fairly decent argument for it. Which, honestly, made it a little more difficult. It's always easy to ignore a troll.

Currently, my problem is this (and this would be an interesting follow-up post): The applications you mentioned, TF2, Halo etc, are ONLINE games, run through servers maintained by the developers- So all the data they need to analyze to improve their product already passes through a point they can control. How does someone writing a desktop application get data on how their product is being used, without depending on user feedback? It becomes an issue because even if I were to have my app send a small, anonymous packet of information to the server every time it was used, it would quickly be labelled "spyware" and people would get up in arms over it. Even if I had a checkbox, "send anonymous usage statistics, yada yada yada" in an options screen, I'm afraid it would still carry that spyware stigma.

You just pointed out the fundamental flaw with many corporate IT organizations. We rely on business users to create requirements for us to execute. They say add a button so I can do this. But if we had dug a little deeper we would have realized that the action they want the button to do, should be done automatically without the additional UI clutter.

At the end of the day most IT professionals don't do well at root cause analysis of user problems, because we aren't great communicators. So it's easier to do what they say, than to get into a meaningful discussion and solve a real issue.

Unless we get data like you suggest. We like data.

Take your stinking paws off my software you damn dirty user!!

hehe.

In an environment where you have direct contact with the user, the skill lies in figuring out what the real problem s/he is describing. The developer needs to have sufficient understanding of the domain for the user to be able to describe what pain they're suffering so that the developer can offer possible cures based on their expertise.

If a colleague tells me they need a report, I'm usually off into Five Whys to establish what they are trying to achieve. The solution is seldom what they asked for in the first place and is usually more satisfying to all of us.

Once they're well-trained, of course, asking for something as specific a report may very mean that their problem actually is that they don't have the report. Perhaps they need to deliver it to a regulatory body, for example.

Using TF2 as the example, part of the statistics analysis also means deciding what, if anything, needs fixing. In order to do that, there has to be an expectation of what distribution is acceptable.

Spy and Sniper are niche classes, so you would expect their usage to be lower than the Soldier, a solid all-purpose character. The question, then, is how far do you let it slip out of balance before you intervene? Is there even a reason to intervene, or were your original expectations too idealistic or failed to consider some other state of equilibrium?

Would the Pyro be next on the list after the Medic gets some love just because he is underused, or is he fine the way he is? Is it the players' fault that he is underused because they aren't using him properly? Maybe the maps are too open and don't take advantage of the Pyro's love of ambush.

Are the Scout and the Engineer the top two classes because they are too powerful, easier to play, more fun, or more necessary?

There's a lot more to consider than just raw percentages.

Awesome post Jeff, spot on.

Back in the dark ages (middle 90's), we rolled out a new version of our application to a group of production users who had been designated as testers. We had asked them to keep some sort of log about issues they encountered.

After spending a couple of days talking to the users and getting no useful feedback, I implemented something that was radical back then; I added a line to the network Login script that wrote to a text file every time the user logged in. Each day, I would sort through that file and sort it by user. Most users logged in twice a day; once in the morning and once after lunch. There were a couple of our testers who were rebooting a dozen times a day or so. When I asked the testers what was going on, they told me 'Same as the usual. After the first time it blows up in such-and-such a place, we reboot and things work correctly'. Apparently the application had had that particular problem going back a couple of versions.

Admittedly it was a rather crude way of figuring out what the users were doing, but it certainly helped us find out what was REALLY going on.

The title says it all.

nice post!

Mike makes a Real Key Point.

The user wants something; however, what they really want, if you ask them enough questions, and what they <I>ask for</i> aren't always the same thing. A cynic might say they're <I>rarely</i> the same thing.

Titrat: I was going to mention that*, but I believe it does not prove the data "totally wrong".

What it proves, more likely, is that the 1280x1024 result got mis-captioned, or at WORST the two categories got combined in the database.

The rest of the data for resolutions "feels" right; at very least it's plausible.

* If only because my windows gaming machine has a 1280x1024 monitor.

The one item that is missed in all this is that I am keeping existing users happy, but many times I need to make changes to attract new users. Having the 5 happiest users in the world won't make you a lot of money unless your product can grow to be useful to many more users (or you charge those 5 users a ton of money). I pay attention to both my current users and also try to address the needs of "future" users.

Reading your post made me think of what kind of data we are collecting from our users. We record the errors that happen but nothing about what actually works. We kind of assume everything works if they don't complain or the application doesn't record an error.
Instead of an error log maybe have a log that runs once or twice a month that records most used screens, buttons, clicks, keystrokes, etc.
Great post! Thanks.

Using Valve data is a joke I hope? You can't really take conclusions from that. Or does every customer you have ever worked for, has Steam installed on his workstation and plays HL a lot? If you would have ever played it (as mentioned by somebody else before), you would have known that most players lower their resolution while playing to get better framerates.

Changing stuff based upon player feedback is widely used imao. You're giving the example from Halo. But let's take a bigger and better one: WoW (played by millions of users). Blizzard listens to the users to see if they can find a possible imbalance ingame. When they suspect there is one, they start investigating if that's actually true and fix it if needed.

Conclusion: Always listen to your users! You'll get kicked in the nuts hard by not doing it. However: Don't trust your users blindly!

@JV

I think that's the whole point of the Valve screen resolution section. The data that is collected is what users are actually using, whether in-game or native desktop. Correlating that data to what users are wanting shows they do not match. Even though users say they want higher resolutions, usage shows nearly 40% of 1.3 million people are in 1280x960. Whichever the data is capturing, from in-game or desktop (meaning they cant support higher resolution anyways), why would Valve spend resources to support higher resolutions when only 1% people are going to use it.

This is a great example of not listening to the users. Going so far as to take "don't listen to your users" literally is a bit much, but the point is the user, although having great input, is not always the most appropriate or high priority action to take.

The users might want higher resolution, but are playing in low, because its faster. So if the higher resolution was faster, more people would use it. This applies better to graphics settings. I like highly detailed graphics with waving grass, but cannot use much of them because my computer is not super fast. Because of that, I end up wanting more games that are utilizing low graphics but still look good.

Second Life is another example. It is complicated platform so it is buggy, laggy, and has lots of annoying features. But they cannot do much about it because they do not know how and because it is so complicated. Still they add new features, that in my opinion are buggy and not made properly. They end up having buggy, laggy, and annoying system with buggy and annoying new features. Then people get angry, but many continue using it because there are no good choices in the market.

Great post, I 100% agree. Exactly, users do not always know what they really need, but considering users' benifits and understanding users' feedback can help us develop better products.

Ok you say "Make sure your application or website is capturing user activity in a useful, meaningful way"...
but what is this useful meaningful way? On a java web interface... what'is the way for to log users activity from remote?
I really don't have idea about that...

I can not agree more on the subject of listening too much to your users.
I've come to realize that I'm more of a reducer than an enhancer of "my" users ideas.

I've often found my role, as a consultant, to be
1. Customer: "I don't really know what I want. Tell me what I want"
2. If/when everything goes wrong: "You told me I wanted this, you were wrong. I can blame you"

excellent, you are saying to watch what your users do and build for the largest base of users. thanks, nice one.

medyum, sihir, cin, &#351;eytan, MEDYUMU, &#351;ifa, hoca, muska büyü, sara nöbeti, medyum ankara medyum, medyum, büyü, muska, nazar, cin, cinler, cinler a
http://www.medyumumut.com medyumumut@hotmail.com

Medyum | Hoca Zeynel Eroglu | Sarlatanin Gercek Yüzü | Medyumlar | Büyü | Medyum Siteleri | Medyumlar |

Medyum | Medyum Nehir| Medyum sitesi | Medyum siteleri | Medyum | Medyumlar | Büyü Bozma | http://www.medyumnehir.com

Don't listen to your users, but pay attention to how they use your software. <a href="http://www.astrolojifal.com">http://www.astrolojifal.com</a>