Complaint-Driven Development
codinghorror.com
codinghorror.com
Often, the design goals might exist on an alternate axis.
Random people offering random opinions amounts to random noise. However, the random noise will not appear neutral; it will appear as information.
If we consider many different things designed for particular audience members such as jet cockpits, medical tools, racing automobiles, we will see traits that exist that may seem nonsensical or otherwise when we divorce them from their designed contexts.
Bill Buxton covers this in Sketching User Interfaces when he describes Inuit coastal maps: "The Inuit have used. [...] Tactile maps of the coastline, carved out of wood. They can be carried inside your mittens, so your hands stay warm. They have infinite battery life, and can be read, even in the six months of the year that it is dark. And, if they are accidentally dropped into the water, they float. What you and I might see as a stick, for the Inuit can be an elegant design solution that is appropriate for their particular environment."[1]
Focusing on complaints of the above design in all likelihood would, given the mad rabble of audiences online, result in discarding a solid bit of design.
[1] Bill Buxton, Sketching User Experiences, pg 37
Since that change, I haven't heard word one about our terrible, onerous, awful default body and title character limit policies. Not one. Single. Complaint.
So, they didn't do what the customers said they wanted, but they did work on the issue until people quit complaining.
“If I had asked people what they wanted, they would have said faster horses.”
― Henry Ford
Plus, IIRC, for the Edsel, they did ask customers what they wanted. And it has gone down in history as one of the worst cars ever.
Or how it's presented. It's pretty common for a feature to be the subject of complaints because no one actually realizes why you put it in.
The issue I raise is a cautionary tale that when we try to use some abstract evaluation well removed from the context, the "data" can end up being non-information. Worse is when design evaluation comes with hidden cognitive bias or underlying ideology.
That is, even a valid concern / complaint of a given design my have no merit given the design context. If we take for example a vehicle, one might complain that it has a lack of cargo space or a child seat restraint. Valid complaint given a very discrete set of design contexts. To follow along the original example in the post, these otherwise valid complaints of a design are moot if the vehicle in question is an F1 automobile designed to be raced in unique circumstances with unique needs.
[1] There is also the possibility that some of the design contexts include more abstract needs such as cultural, religious, historical, aesthetic, or even the darker notions of power dynamics. To diminish the potential influence of these facets would be an ignorance in our design evaluation.
I'd encourage anyone interested in design context to read Marco Van Hout's article on the rather broken UIGarden.net site. Here's a link via the Wayback Machine: http://web.archive.org/web/20130719161851/http://uigarden.ne...
It really does not matter what methodology, or tools you will use, if at the end it does not pass the user acceptance test
So why consider it a failure if you have users telling you what they want and how off you are? Better to embrace it and make a better product
>That's how you suss out the rare 10% of community feedback that is amazing and transformative.
So don't obsess over every bit of user feedback, but figure out what matters, and what multiple people are complaining about, not just one loud person.
(There is also the issue of observing what people do versus what they say they do. At least early on I find the problems are severe and obvious enough that this subtlety isn't a big deal yet.)
I've had the unfortunate experience of building a product for someone else where the process was driven by a combination of Complain-Driven Development and Upper-Management Wish-lists. This alone might have been fine but at the same time anything positive like the real analytics about how successful the product was or any non-complaint communication coming from the users was hidden from me for fear, I suppose, that I might try to use that information get my company more money.
This became incredibly depressing. Everyday you show up to work putting in more and more hours into something that comes back with more and more complaints. It was hell and I did everything I could to end Complaint-Driven Development to no avail because thats how the customer liked to work. Eventually I finally just gave up and left to find something more rewarding and less soul crushing.
So, yes, there can be big problems with this, depending in part on the problem space you are addressing, I think.
My current gig is very customer-driven and we hire a number of PMs to handle and incorporate the feedback. Our customers love us because the alternative is a particularly stodgy, poorly performing and relatively unchanging product. With end-users, yes. The flood of complaints and the complaints about the fixes for the complaints and on and on can be soulcrushing.
Finding a niche who loves you and your product is hopefully possible.
This article is about early stage products that are very new. If you're looking at a mature product that has been on the market for 10+ years, it's likely (I hope!) that most of the major obvious pain / complaint points have already been addressed. I don't think CDD would be as useful in that scenario -- you want a different model.
"The fool doth think he is wise, but the wise man knows himself to be a fool."- William Shakespeare, As You Like It
This is simple but practical advice I think far too many people ignore. You've inspired me with this article. Glad to see you've been successful from it!
We tried to add tags to support emails (via helpscout), but it's also hard to remember to tag things, and it's easy to use different tags for similar complaints.
I wonder about the best strategy to quantify complaints / suggestions and 'bucket' them correctly, so you can really choose the top ones.
If your current tagging system isn't helping you, flip the axis on which you're tagging to see if new patterns emerge. (area of complain on your product, versus types of tasks users are trying to achieve, for example.)
Throughout development, we've been using it to get feedback from the community: on their own ideas, their thoughts on design aspects we've shared, and questions they'd like us to answer.
User Voice lets people suggest and vote on ideas. We can label them with customizable tags like "Seen," "Considering," "Not Planned," as a very time-efficient means of communicating to many at once, without the expectation of personal replies.
The system isn't perfect, and we're not using it perfectly, but it's been helpful for getting and organizing feedback.
I don't think it has really helped Dell as to many of the things they simply said they aren't doing it (e.g. standardise power supplies in laptops) but the concept seems decent if they weren't very open to the feedback received.
I'll give the Docker install a spin. I'll give feedback on the Gentoo install and the Docker install when I am able to give both my full attention.
Your blog posts are frequently thought-provoking and inspirational and mercilessly bullshit-free. I'm so glad you've moved to Ruby on Rails and welcome you with open arms into the open-source world, you may not fully appreciate how much goodwill that move generated for you :)
https://meta.discourse.org/t/beginners-guide-to-deploy-disco...
I can't think of a many such titles though. Maybe "UX" for a general discussion about user experience?
Edit: oups, I had read "English speaking" rather than "non-English" ; with ideograms, it is actually quite obvious, thanks for the remark!
In Chinese and Korean, a single unicode codepoint encodes a full syllable, so two codepoints can be a word or even a short sentence.
So, depending on your writing skills, it can be a lot. You could use the begining of a poem or a sentence, which would be understood by the readers. For instance if you say “温古" it refers to a Confucius quote meaning "warming the past to learn the new".
But more interestingly, I think the restrictive and top-bottom rules edicted in Discourse and Stack Overflow may be some kind of mistake, or ultimately lead to dead ends. It goes against the natural grain of all things internet. It is AOLish, if you allow the neologism.
The leading successes of internet, i.e. Wikipedia, Google search, have had their massive growth and exitement when they were in extensively all-accepting mode. Reddit and 4chan are also in this kind of mode.
It seems probable to me that the next break-through will be again lifting artificial limitations there is on e.g. Stack Overflow.
For example, I have friends that released a rather ho-hum mobile app. They quickly garnered something like a 1.5 star rating, scathing reviews, and almost no conversions. The business cycle on this was a year, and they are still trying to claw back reputation and win users. It's a debacle. (the problems weren't their fault, but that is irrelevant to this point).
Then you have companies with secrecy, like Apple. I think this advice would be terrible for them (I have never worked there, and am open to correction). They can't dog food it widely due to the internal silos, and they certainly cannot test it with the public.
Then there are electronic systems - iterations on SW is easy, iterations on HW expensive and hard, even with simulations, mock ups, and what have you. I worked on an augmented reality hardware thingy several years ago; we went from foam cutouts to a couple of very expensive prototypes, and that was it.
It is awesome when we can completely sidestep a problem, and this process lets you sometimes sidestep the serious difficulty of UI design. I worry when it gets bandied about as a truism, or The One True Way (not saying Jeff is doing that, I'm remarking on the wider industry). Yes, Agile lets you sidestep the problem of scheduling and estimation - sometimes. Try that when you are making a new airliner, building a cloverleaf interchange, making a car entertainment system, and so on.
edit: the converse problem is equally as large. Someone below mentioned the 'planning mania' of companies. I don't mean to downplay that problem, just to point out the need to evaluate each situation on it's particular needs as opposed to a 'best practices' (oh, how I hate that term) unthinking approach.
I fear that this myth is capitalized on by Apple under the hypercapitalist Auteur theory.[1]
The value of magic tricks is that they create awe and surprise, when in reality they can often be a by-product of misdirection and street-level sleights.[2]
This is not to suggest that Apple is going out onto street corners and asking random individuals for their opinions, but rather that part of the corporate myth making is likely obscuring process.
[1] http://www.youtube.com/watch?v=p9dmcRbuTMY
[2] I believe there is a court testimony document discussing Apple's market research team via Phil Schiller. Contrast this with Mr. Schiller's other comments about avoiding market research.
(I'd also argue mobile apps have a severe updating problem, that web apps do not.)
BTW, discourse infinite scroll could behave better when the user input is the down arrow on the scroll bar.
That's the underlying disconnection.
I am now working on my 3rd message-transformation/integration middleware product for a large corp. In each case, the issue tracker has been stock full of problems from people who took the product, read all the manuals about what they were supposed to do, then did it their way anyway. Because, well if they can, they will.
I think the basic problem is not challenging your personal assumptions about how you want your beloved system to be used.
I constantly get asked to add another "excel parser" to my in house Django app. These days I refuse (it is way too error prone) and build it directly into the web interface. Then they realize, that even with all the nice auto-complete and cut and paste features that excel comes with, clicking a few checkboxes and a submit button in a web interface is more efficient (and less error prone) than cutting and pasting the data into Exel in the first place.
So it's useful to make your MVC as good as possible so that your users aren't forced to complain about the results of fundamental design shortcomings. That can result in more and more complex fixes, none of which should be necessary.
It's great, users fells empowered, and you get the priority list for free with reddit upvote system.
As for discourse were planning to deploy it this year at our intranet, and we've got 130.000 employees.
Contact me if you need help. I'm a good UXpert.
You can approximate some of this feedback by observing user interaction with prototypes, but if you pay attention, you'll learn more when they start using it in production.
The point of this process is to start that complaint processes as early as possible so you're not delaying the inevitable or spinning your wheels on something users don't want anyway.
Complainers have to be cultivated. Complainers can be your most valuable asset.
And the people complaining should be treated like your best friends: they cared enough to complain. Nobody else cared.
I've found that people don't respond unless they know that you really, really, really care. That's why most of my support emails include lines like "We're here to support you in any way we can so if you run into any problems whatsoever please let us know," or "We'll do everything we can to help you achieve X, so please don't hesitate to contact us if we can help in any way."
I've found that anything less strongly worded than that comes across as formality rather than a sincere offer.
On the other hand I give instant feedback and keep a relationship to any complainers that are my happiest customers now.
To be honest, I should do it even more because I find very annoying when I write about something I've already written (well, it makes sense: if it was a good idea to write about that back then, that's why it's a good idea to write about it now).
This is a strange perspective. Any reader of the blog obviously considers the author's information or opinion on the topic useful enough to be reading the article. Isn't it likely that the reader would consider the author's writing on related topics useful?
Would you rather have an out-of-context list at the end: "If you liked this, you may also like posts X, Y, and Z"?
Yes, this can be abused in link-bait-seo-overoptimized ways, but that doesn't invalidate the utility of the practice.
Often, the author's views on related topics are both - perhaps they're less valuable if you've already read the archive, but ... really, sane site internal links are almost always some of the most useful ones there for long standing blogs.
[1] http://www.bortzmeyer.org/ (fr)
(I could not think of an English-speaking website with a similar differentiation right away)
Edit: just look at Wikipedia https://en.wikipedia.org/wiki/Hacker_news
Supposed to according to whom? That seems to be far from a universal custom. And if it's important, the browser can do it.
But really, the status bar hover thing in every browser since IE5 is more than enough for me to work out where a link is going to go. (Guess it's not so useful on mobile.)
On Dolphin long press gives you the link at the top (usually truncated though) then a list of options like "open in new tab" "open in background" "save link" etc. It just seems important to me to see where a link is going to go for whatever reason.