If I haven't blogged much in the last year, it's because we've been busy building that civilized discourse construction kit thing I talked about.
This is a companion discussion topic for the original blog entry at: http://www.codinghorror.com/blog/2014/02/complaint-driven-development.html
There is an important thing I’ve learned from a decade and a half of writing customer-facing software (and software they pay thousands of dollars for).
That is that you shouldn’t listen to them when they say “it needs to have this button that does that”.
Because half the time that’s just “the other guy has a button that does this” or “I learned from other software that you gotta do it THAT way”.
The important thing is to figure out what “it needs this button that does that” means in terms of desired outcome.
Figure out what they’re trying to do [or to avoid] at the above-implementation level, and then implement it well, consistently, and ideally elegantly.
(I don’t know the specifics of the feedback on the case you mention, but I suspect the principle could have been applied usefully.)
(In fact, I have an analysis I can infer -
Their complaint PROBABLY, in terms of usability/outcome, was “don’t make me click OK to find out you’re going to reject my input/don’t make me WONDER if my input is acceptable”; both subtle counts-required and post-entry failure highlights have that problem.
The end solution satisfied them because it made it unavoidably clear in realtime that there was a validation issue, and told them exactly how to pass validation; no uncertainty, no multiple tries.)
If you aren’t living in the software you’re building, each day, every day, all day … things are inevitably going to end in tears for everyone involved.
I disagree. Of course ‘eating your own dogfood’ is great if you can do it. But how can someone writing, say, an airtraffic control system live in the software they are building, in any meaningful sense?
I don’t get it. From the wording of your “nuclear” option, it would seem that you set the minimum title and post length to one. That’s what everyone wanted all along, so of course they stopped complaining. Or are you saying that you kept the initial requirement? I don’t see how the new pop up dialogs would help at all in that case. Were people really that confused about minimum lengths?
Also, you needs a better comment system here. Something that supports markdown at least.
@ Jon Shier - That is incorrect, it just shows a different message when they’re empty as when they have not enough content.
Try it yourself at http://try.discourse.org/ (blue “Log In”, grey “Create Topic”)
How did you make sure you didn’t improve morale by beating the malcontents into silence? Did former complainers positively respond? Or is a new found lack of complaint the only signal?
@steve For a long time there was a steady stream of new people complaining about the length restrictions, pretty much every week. Now I can’t even remember the last time I heard that complaint.
@jon it’s almost like we should use Discourse as a commenting system here, right? http://eviltrout.com/2014/01/22/embedding-discourse.html
@andy should any air traffic control system be built without serious input from, y’know, air traffic controllers? I agree it can be hard for the developers to be the perfect audience for every bit of software, but those relationships need to be integral to the design of the software.
Why not just remove that limitation, since people seemed to hate it so much?
As someone who just bumped into that limitation 15 minutes ago and had to tack on an unnecessary word to a post title on a Discourse-powered site, I feel like that would’ve been the more obvious solution.
SachaGrief, there may be more obvious answers, but they are not always the right answers. One of the best ways to screw up software is to build exactly what users ask you to.
Let me be clear here. Listen to all complaints, but take the customer’s proposed solutions with a grain of salt. Like a doctor speaking with a patient who just looked up his condition on google; they know exactly what the symptoms are, but you are generally best suited and trained to diagnose and prescribe the best solution.
Nacho, what you’re saying is the opposite of what the post is saying.
Personally, I find this “complaint driven design” nonsense to be bullshit, and only ends up with you creating a more pedestrian application that caters to the vocal minority.
Say 1,000,000 people have no issue or complaint, but a noisy 10,000 people do. Your forums are flooded with how this is a complaint, your social media, you can’t do a poll or anything tangential without hearing about this problem.
is it a problem? no.
You know what else derives zero complaints? Mediocre products not worth discussing.
@andy Ever heard of VATSIM? For almost any product you’re building, there’s a way to live it, even if it isn’t obvious at first.
@Sigivald: I’ve heard a variation on this advice, from writers talking about how to address feedback from their beta readers. The general theme seems to be that when beta readers (or beta testers) identify a problem, there is generally always a problem there. However, their ability to identify what the problem is – “this needs a button to do X!” – is very often wrong.
And so the trick is to understand what the beta reader/tester’s problem is and listen to that part of the feedback, but discard the rest.
Why can’t I log in on Discourse with my StackExchange OpenID?
And what is this green progress bar about?
And finally, I didn’t get the point. What is the actual benefit of Discourse over the StackExchange system? So far I see only minor differences.
- It’s about discussion instead of Q&A, but if you don’t strictly follow the rules, Q&A can also become a discussion
- We have likes instead of upvotes
@Brooksmoses Very wise words: 'there is generally always a problem there. However, their ability to identify what the problem is – “this needs a button to do X!” – is very often wrong.'
Note to self: even when users are talking opposite things about problem/feature, you can’t ignore that there IS a problem.
I think complaint-driven development in itself is a good strategy, but there’s an even better one: doing serious usability testing. With that I mean actually watching and recording different people using your system. It will bring a goldmine of information, and you’ll be stunned at how users can struggle with even the most basic tasks.
Usability testing is better as it gets you closer to the source of problems. For example, many people who struggle may not file a complaint at all, thus you miss it. Also, if they do file a complaint, they may word it differently than what they really want.
That said, you’re totally right in being humble about the brilliant things you thought you had designed pre-launch. I too have been wrong many times in designing systems.
The fact that your team was so persistent in staying with your design philosophy was quite eye-opening for me. I think after the 3rd try at creating UX and “failing” I would have said “forget it; give 'em what their crying for!” In fact, I might not have even tried 3 times. To me, the solution you arrived at must have been difficult to determine because the predecessors look so much like the solution functionally. Thanks for posting that specific example.
I really like this approach, it lets you eek out the issues at their cause and not the symptoms. Its definitely the more valuable approach long term, but be careful, it can backfire.
The trouble is that if you don’t handle it well, you can end up making your users perceive you as ‘arrogant’ like how 37signals has inadvertently done with their marketing, even though they obviously do listen to their users.
All it takes is some competitor to drudge up the umpteen ‘complaints’ about the character limit and spin it to sound like you (codding horror) doesn’t listen… Imagine 3 years from now how the next big platform decides the best marketing tactic is to pick a fight, and tries to argue about you being arrogant… “They haven’t even removed the character limit, and that’s been a complaint since the beginning!”
Thankfully the way you present yourself doesn’t lend itself to being misrepresented as being dickish. I really appreciate the way you come off as firm but empathetic.