4 ms·
When do you ignore your users?
Quoted in Getting Real is a passage by Jef Raskin about avoiding "feature blight" (http://jef.raskincenter.org/unpublished/widgets_of_the_week.html#anchor1152335 http://jef.raskincenter.org/unpublished/widgets_of_the_week....). The passage suggests too many features is a bad thing and that the best way to avoid that pitfall is a very real and constricting deadline. My question is that once you've launched and you're able to afford a more liberal deadline, how do you keep feature blight from creeping in?
37 Signals was noted here recently for refusing to implement suggestions until there's a critical mass of users looking for them, but is that the "best" way to combat this issue?
- altay 19y agoI forget who said this (Paul Buchheit, maybe?), but it made a lot of sense to me: don't listen to your users, watch your users. Figure out what they're trying to accomplish -- via usability testing and analytics -- and use that to inform product development. Feature blight is a separate issue. It's good to try out lots of stuff, but you can't just vomit out feature after feature -- you have to iterate. After you release a feature, watch how people use it. If they're not using it, tweak it or axe it. Features need to earn a permanent place in your app.
- mpc 19y agoSince most startups build server applications, this is a lot easier than it was in the days of shrink-wrap.
- brlewis 19y agoIt was Jakob Nielsen, but Paul Buchheit says things that apply the same principle. http://www.useit.com/alertbox/20010805.html http://www.useit.com/alertbox/20010805.html