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.
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
Stay tunedâŚ
@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.
@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.