programming and human factors
by Jeff Atwood
In this interview with Werner Vogels, the CTO of Amazon, he outlines how Amazon's developers stay in touch with their users:
Remember that most of our developers are in the loop with customers, so they have a rather good understanding about what our customers like, what they do not like, and what is still missing.We have a lot of feedback coming out of customer service. Many Amazonians have to spend some time with customer service every two years, actually listening to customer service calls, answering customer service e-mails, really understanding the impact of the kinds of things they do as technologists. This is extremely useful, because they begin to understand that our user base is not necessarily the techno-literate engineer. Rather, you may get a call from a grandma in front of a computer in a library who says she wants to buy something for her grandson who is at college and who has a Wishlist on Amazon.
Customer service statistics are also an early indicator if we are doing something wrong, or what the real pain points are for our customers. Sometimes in meetings we use a "voice of the customer," which is a realistic story from a customer about some specific part of the Amazon experience. This helps managers and engineers to connect with the fact that we build many of these technologies for real people.
It's easy to fall into a pattern of ivory tower software development. All too often, software developers are merely tourists in their own codebase. Sure, they write the code, but they don't use it on a regular basis like their customers do. They will visit from time to time, but they lack the perspective and understanding of users who -- either by choice or by corporate mandate-- live in that software as a part of their daily routine. As a result, problems and concerns are hard to communicate. They arrive as dimly heard messages from a faraway land.
When was the last time you even met a customer, much less tried to talk to them about a problem they're having with your website or software?
It's incredibly important for developers to be in the trenches with the customers-- the people who have to live with their code. Without a basic understanding of your users and customers, it's impossible to build considerate software. And nothing builds perspective like being on the front lines of support. I'm not proposing that all programmers pull double duty as support. It'd be impossible to get any work done. But a brief rotation through support would do wonders for the resulting quality and usability of your software, exactly as described by Mr. Vogels.
Dogfooding can be difficult. But manning the support desk, if only for a short while, isn't. Software developers should share the customer's pain. I know it's not glamorous. But until you've demonstrated a willingness to help the customers using the software you've built-- and more importantly, learn why they need help-- you haven't truly finished building that software.
It's not just the developers that need to be in tune with the customer, it's often a problem that management has their own ideas about how things should work that is not based on customer feedback or customer experience studies. In my experience, questionable decisions or goals by management contribute just as much as developers for process flow, site design, content, or presentation problems that customers may experience.
Axel on December 6, 2007 1:07 AMHey Now Jeff,
UAT User Acceptance Testing is a great thing.
Coding Horror Fan,
Catto
I find that working with customers, or keeping customers in mind, helps develop concrete features with reasonable limits and permutations.
For instance you are developing a File Utility software product that a) Compresses files, b) Defrags Files, and c) Encrypts Files in a given directory.
A super-star Engineer sitting in their Ivory Tower would design this software product such that it can process directories with millions of files, and must be able to compress, defrag, and encrypt files in a single pass. This increases the complexity of the code since for each block of data trying to be processed you have to handle all the features. At the same time, this engineer using he wicked technical ability makes it such that you can still access your files while all the processing occurs in the background.
However the customer doesn't really have directories with a million files, may a 1000 or 10000 at most. He doesn't have need to compress and use his files at the same time. And he never defrags, compresses, and encrypts his files at the same time, only does one of the features at a time.
Had this super engineer listened to the customer he could have design a simple and effective tool, instead he created a complex piece of shit that has to be maintained too in the coming years.
Absolutely true! I'm a technical lead for NetResults Tracker, a web-based collaboration tool, and I spend at least 10% of my day browsing customer emails our support responses and see how really customers use our application to fulfil their need. This has helped us a lot in building a better product focusing on the customer.
Every engineer who gets into our team initially goes thru' at least a year in handling support emails for 10-20% of their day-time. Well, I feel it is worth it, as you say.
I agree that engineers should share the customers pain by doing support. Visiting onsite and seeing it live in action is a must too. I worked for a medical record company once, and nothing was cooler than going to the ER and seeing the dialog boxes I wrote up on the screens of all the doctor's workstations.
However, nothing sucks the life out of developers and frustrates them more than supporting the crappy legacy VB/FoxPro/Clipper/Clarion versions of software they know nothing about. In those all-too-common situations, the developer just ends up loosing respect for the company, because they see how aggravated the customer is, and there's nothing the developer can do to help.
In those situations, I think it'd be better to keep the bright, shiny .NET/Java developers away from your company's steaming pile of COBOL....
:)
Sam Schutte on December 6, 2007 1:32 AMI don’t think that the real problem is the ivory tower principle as much as the fact that a lot of times, you never even get to meet your user. The bigger problem is that your user is not always your customer. And then, on top of that, you usually have to get your info or take direction from people who don’t know what they are talking about and don’t understand the development process, and they inject their opinions in the discussion as if they are fact.
An developer who doesn’t want to make the user’s life better is not worth a grain of salt. The problem is that most time, even when we do want to make the user’s life better, we don’t get the chance.
In most companies, they have specific policies in place so that you, an unwashed developer, can NEVER meet the user of your software, and can NEVER interact with them. In fact, they are downright hostile if you do insist on knowing them... or inadvertently talk to a customer in a training class.
Happily, I left that place. Not all companies are like where you work, Jeff. Such is the tragedy.
ns on December 6, 2007 2:13 AMIf you can it's fascinating and instructive to watch other people just get on with their day to day work. People do the same things so very differently, and if you're not careful you will design something that only suits one way of working to the detriment of others.
[ICR] on December 6, 2007 3:14 AMThat's similar to one of the things I love about my job. Yes, I'm tech support, but we are no less important than our programmers. Where I am, we are the public face of our company (and a strong selling point). And we also have full access to the programmers, if need be, they can even be brought into the discussion. Just today I had to grab one of the programmers who wrote a few custom apps so we could solve one of our customer's problems. There's always open communication between the two departments, and the customers know and appreciate it.
Rocketboy on December 6, 2007 3:21 AMI was waiting for someone to link the Microsoft "Share Pain" button video, which makes this theoretical concept very real:
http://www.youtube.com/watch?v=ry7u6JF_B1c
Tsk! you guys and gals disappoint. :)
Jeff Atwood on December 6, 2007 3:36 AMI agree, Jeff!!
I had an opportunity(I agreed rather reluctantly) to work in the Customer Support division of our company. And I clearly see the difference in my understanding of "software as a tool" concept in the period before and after my tenure.
It surely is an eyeopener...
"When was the last time you even met a customer, much less tried to talk to them about a problem they're having with your website or software?"
I work on-site for our customers. I couldn't avoid the users even if I wanted to. :) Then again, I work for a consultancy firm, so our culture is a lot different than in a packaged software or typical Web development shop. Our business is based on personal interaction; if we didn't talk to our customers, and understand where they're coming from vis-a-vis their comfort level with technology, we wouldn't continue to get contracts.
By contrast, when I worked at Microsoft, we didn't have a "natural" interaction with the customer; we were on Campus, and they were scattered around the globe. MS's Developer Division (the division that produces Visual Studio, and where I worked) addressed this by having developers sit in with Dev Support reps. We also had regular monthly bug meetings with Dev Support tech leads to find out what were the 10 largest developer issues we needed to address in the next version of the product. On top of that, DevDiv groups went out of their way to meet with customers, set up Tech Labs to preview Alpha and Beta builds, and solicit feedback from the dev community through the Community Preview program.
There are any number of ways developers can stay in contact with customers, regardless of industry.
Jay Allen on December 6, 2007 10:57 AMLook at yesterdays post. Many at Microsoft are no doubt just as annoyed by focus stealing as the rest of us. They do share the pain. They just chose to ignore it. Talking to customers is great but if you ignore you own problems what are the chances you'll take theirs seriously.
Jacob on December 6, 2007 11:10 AMThis is a good case for open source software development making for better developers. If you choose to join in on a project you actually use (good examples for me would be Subtext or RSS Bandit), then you get a chance to share the pain. Some quick benefits I can see gained from living on both sides of the fence are:
* Enhanced visibility to potential problems arising from code/feature changes.
* Great insight into bug priority.
Site visits are also good. Then you can see how the software is used without having to solve the immediate problem.
Tim on December 6, 2007 11:24 AMI agree that in-house programs have an easier time of this (the customer knows where your desk is :).
For the last project, our first step was to sit down the users and ask "how do you want this to work?". Not in the technical sense, but in the user sense - I need to do steps A, B, C, D...
We then built the UI to work the way the users expected it to work. The revisions were largely (a) the build team suggesting more efficient processes (that would then be codified into the system), and (b) the users showing places where it was inconvienent to use (which were then streamlined).
It worked remarkably well.
Allen on December 6, 2007 11:40 AMThat is why I maintain that all software developers should be required to maintain a strong presence in your site's online support forums, newsgroups, or whatever. They _need_ to be there, end of story.
Computer Guru on December 6, 2007 11:40 AMExcellent point, and every developer would benefit from few weeks of intensive customer contact, either through support, on-site relocation or training services. Where I work, there is no such arrangement, but I will argue that I nevertheless have achieved pretty much the same by working as a software consultant for 5 years, until 4 months ago. Pre-that I was software developer, and am one now too. A better one, I think, thanks to consultancy and close relationships with my end users.
danijels on December 6, 2007 11:45 AMMany times my customers are in the building, and the tools I'm working on are meant to enable them to have an easier time doing their job. Unfortunately, they don't see this, as all too often their managers will ask me about tools to help them do their job, in front of the people they are supervising, and the end-user will get the idea that my job is to design software that will replace them, or make it easier to find someone else to do their job (for less money).
Usually at this point I get stonewalled by the end-users and the software either fails (because the software doesn't really help them and they don't want to use it), or doesn't do as good of a job as it could, because the users won't help improve it.
Thankfully, I usually am the help desk for my own software. When there's a problem, as long as someone actually wants it fixed, I hear about it. If there's a real problem with the software or a real need for user (or administrator) education, it can feel like a curse, but in the end I can fix the problems and educate the users (or change the software to reduce the need for education).
It would be nice if we had so many users that we needed a larger support staff, as it would keep me writing and improving software. Until then, though, I just have to try to keep the paths of communication open, as more often than not there's a manager somewhere trying to close the connection or sweep it under the rug.
Vizeroth on December 6, 2007 11:46 AMOne of the things our new development manager instituted was the concept of a "duty engineer", someone who is responsible for resolving and chasing down customer issues for that month as their primary focus, instead of software development.
People develop a miraculous empathy for the customer when they see the piece of software the customer uses taking 7 minutes to log in, and another 7-10 minutes to run a report.
Suddenly the "can't happen, my code rocks" attitude goes out the window and the problem gets fixed very fast :)
Can't recommend it enough. Dogfooding is a must.
nexusprime on December 6, 2007 11:48 AMI'm am working at a Help Desk until I can find a job as a developer and I can say it has really given me a great view into the mindset of an everyday user.
bryan arendt on December 6, 2007 11:52 AMFor small or slow-starting projects I publish a public, help email address that's forwarded to my mailbox:
"For help using this web site, please contact our staff by email: help@[domain]"
It means that I'm aware of nearly every reported user issue and can respond knowledgeably and become aware of usability issues I should redesign or reprogram.
This obviously doesn't work well for every project.
Zack on December 6, 2007 11:59 AMgreat blog, i have been reading all kind of interesting posts and points of view, i really like of all the opinions give a diferent insight of the subject at hand.
this particulary post gave me something to contribute, well more like to open a quick debate, i for example, have been in the 2 sides of the coin, i like to code diferent solutions, i have been moving through severals languajes and all, and i have too like to use many apps around the open source community and the paid/microsoftish/apple community, thus giving me some insight as an end user
i really understand how good it is to talk with the end user and know what he likes or dislikes about the software he is using, they really give you some hints of what they expect from their apps, tools and everything they use everyday.
but this rise another question, how much do we need to hear from them, how manny sugestions we have to take, or not? you cant simply make every single end user happy so how do we cope/manage this problem?
well thats all, great blog!
Rozz on December 6, 2007 12:03 PMOne of the nice things about working on "enterprise" software in a small company is that we are very closely coupled to our "customers," who are our co-workers in the company.
No need for useability labs here.
Howard on December 6, 2007 12:15 PMOur customers just want simple, easy to use and read reports. Our software is basically 2 pieces: A high level ad hoc query tool whereby the users choose items from a filter, pick how they want it aggregated, and then hit generate. The software then builds an SQL statement and returns results. This is what the user wants. We have since added all sorts of GIS pieces so they can see weather, soil type, topology, etc... on top of the data layers. They love this.
The other software is a low-level reporting to find detail information.
They never request more that this, but my bosses are constantly wanting to build complex statistical modeling tools for the users. The latest project has me trying to build spider-diagrams of the relationships in our data... no one has asked for this nor does our data model support this...
How do you deal with bosses that want you to build tools that no one will use? you posted about the 80/20 programmers recently, well that applies to users as well. I am pushing to build tools for the 80% since that meets most user requirements. I can spend a month putting out a feature that 80% of my users will use everyday, or i can spend 4 months building some spatial-statistics modeler that maybe 2 people outside of our office will use...
But since the mandate comes form on high, I have to do it. But when customers complain to him that the software doesn't meet their needs he is blind to the reasons why... he gets in the way!!!!
sorry for that, just got out of a meeting where we decided to scrap a project I've been working on for 8 months because they don't like the interface... the interface! OMFG!
WA
Wayne on December 6, 2007 12:16 PMGreat post!
A good comeback from your previous posts.
Most SW companies I work for shelter the developers from customers and let the business people interact with customer service. A lot gets lost in translation.
On the otherhand, you do need a bit of overhead to have developers sit in Customer Service and listen to feedback. Most companies wouldn't stand for that. Guess we can all learn a little something from the more successful stories out there.
That being said, I hope my business users don't read this post. I'm perfectly happy sitting in my cube :-)
CptBongue on December 6, 2007 12:28 PMI meet my customers every day, because they know where I sit at work. I change cubes, and they still find me!!
The thing I love most about my customers is that they hate new technology because they think we are implementing new things to take their jobs away. All of them want to go back to the mainframe days, and they tell me that everyday.
anonymous on December 6, 2007 12:39 PMI have been saying this for over 4 years to my different managers. Now I have a all-star developer's blog to refer to!
I have been working in product companies, and this is just such a problem to break through. I wonder why?!
One of the last software houses I worked for offshored all development work from the I'm offices to India. They certainly have a different opinion of "developers" sharing the pain of the customers. I hate to side with the software factory, where our hard earned skills are assimilated into factory produced assembly lines, but their philosophy was
Let developers develop
let analysts analyse
let support technicians support
let pm's be unaccountable (ok that point I made up)
There certainly is an argument to say that developers are not always best suited to talk to the customers. A couple I used to work with spent a day "talking" in binary. These were great developers, and they wrote some pretty nifty algorithms in c++, but if you put them infront of a member of the opposite sex they would say "..greetings female." or something equally as dorky...
Not all developers are created equal. Some developers (such as yourself jeff) are created ++, but some are commercially --
Great post. Having been both a consultant and an "in-house code-monkey" I can agree that there is great value in developers getting to know the consumer.
But, when we combine this idea with the "80/20" idea, I think that we often find a fair amount of the "20's" are not "Consumerable". There are some people you just feed caffine, slim-jims and chips to and wait for the product to "pop out".
But in general, I think it is a good idea....
Daniel
From my humble experience, working with customers is the most critical thing for creating a good product.
If you want to create something that's relevant to your customer, you need to talk to him. You need to show him the product (whatever it may be) as early as possible, to get feedback.
I've seen enough projects that weren't on target, where the focus wasn't on the important thing, because they didn't talk to their customer.
Also, being on the receiving end while outsourcing teaches you a lot about that.
lorg on December 7, 2007 1:32 AMnice post, if Intel's embedded graphics chipset driver programmers practiced this they would have at least updated the game compatibility list of intel 945GM (the chipset i use)on their website and also provided a better driver update to solve gaming problems with the chipset i'm sure they all have Nvidia GPU's in their laptop's and just don't care about what they code to support (Intel GPU's).
gogole on December 7, 2007 2:06 AMHoward said,
"One of the nice things about working on 'enterprise' software in a small company is that we are very closely coupled to our 'customers,' who are our co-workers in the company.
"No need for useability labs here."
I must respectfully disagree. If anything, the need for usability testing here is *just* as important as it is everywhere else.
Usability testing determines, as its name implies, how *usable* the software is, and whether or not users can, in fact, use it to get their jobs done with a minimal amount of hassle. If you've been tasked to write a piece of software to automate a task, chances are, you've been asked to do so because that task is already difficult, complex, tedious and/or time-consuming. If your software targeting internal customers doesn't solve the problem without being difficult to use, complex, tedious and/or time-consuming, why would they use it over the existing process? And why did they waste money developing it in the first place?
Usability testing encompasses a broad range of issues that must be taken into account. If a Web site is being developed, does the page fit into the browser for your lowest common denominator of users? (I still design for an 800x600 screen, because we have lots of senior citizens in our employ, and they have a hard time reading small text.) Is the color scheme of your application too difficult to read? Is the page or window laid out well? Can the options be found easily? Does the program execute quickly? Does it do what was intended? Does it do it quickly enough to justify its use over manual processes? Does it interrupt the user's flow unexpectedly? Does it make invalid assumptions about what the user wants to do? Does it SUPRISE them and make them make the wrong choices? If the users can get the data into the system, can they get the data back out?
In an enterprise environment, it's just as important to do the usability testing. They KNOW WHERE YOU WORK. They know who your boss is. They know the kind of work you're capable of. And they know to expect better of you than some piece of crud you just slapped together in a hurry because you consider them to be second-rate users who deserve less than the front line customers.
Mike Hofer on December 7, 2007 3:41 AMI've been coding for a little over 6 years now. When I first started, I wrote code for myself, or other techies, so I didn't care too much about usability, etc, other than it worked to get the job done.
Then a few years ago, something happened, and I started getting non-techies for users, and then I changed jobs. I started developing apps for business users, and worked closely with them to get what they wanted. I'm now in a new job, and I'm building apps for the business users. The code isn't hard, it's the understanding the users and what they need/want (it's another industry).
Don't get me wrong, I love it, and think I'm a much better developer (note I didn't say coder...my coding skills aren't where they were, but I do write better applications). I don't think I could work anywhere that I didn't have interaction with my users, as I'd constantly be wondering "what do my users want, how do they use this, etc".
mjmcinto on December 7, 2007 6:09 AMThe last time? Two days ago. I love it. I love meeting with customers -- gives me perspective on how they use my software, and allows me to explain / listen to issues without being detached from the people who have concerns.
N on December 7, 2007 6:31 AMFor nearly 3 years I worked as the lead / only developer for a large-scale application that serviced over 100 different realty offices. Oh, I was also the lead / only tech support (build the support system from the ground up, so at least I got what I needed... half the time).
At the position I'm at now, I very seldom do customer service, and then it's usually when I'm dealing with a CSR that's informing me of an issue that's been encountered.
Would I like the first position back? Oh no! Did it impact how I write my code and design my applications? Oh yes!
It was definitely a "see through other's eyes" opener, so when people blast code-monkeys on UI issues, I tend to have the forethought to meet them prior to / during the design phase, and I'm thankful for that.
I'm not perfect but I don't mind having the experience to know what are general uses and issues. There's some issues that are universal (setting cookies when the user has the wrong date-time), to knowing how browsers differ (and why IE is the curse of Microsoft against web developers).
Josh on December 7, 2007 8:50 AMI'd also suggest all levels of management from mid level to CEO spend some time in customer support. The decision to do things the quick way rather than the right way is often out of the developers hands.
Alex on December 7, 2007 9:52 AM"The decision to do things the quick way rather than the right way is often out of the developers hands."
I've dealt directly with customers. Often doing things the quick way is the customer's conscious choice, even when they technically understand the issues involved. They'll willingly borrow technical debt now for something that works, however rickety, and then wait for a cleaner implementation "down the road".
Remember, customers don't care one whit how something is implemented, as long as it does what is advertised.
I think Amazonians spend all their time in the jungle and don't shop on Amazon because that site has become a major browser resource pig. The Amazon web site will frequently choke Internet Explorer and prevents me from going to other sites while their page loads. The Safari browser is better for visiting Amazon and eBay.
Robert S. Robbins on December 7, 2007 11:58 AMI wouldn't say Amazon is a particularly good example of user friendly design any more - it has been a confusing mess of options and internal strategies for at least the last 4-5 years.
Go choose a product andt try looking for a specific piecce of information you have to digg through the sea of alternating product, marketing, advertising and cross-selling with the HTML being 388K alone (with graphics etc. it's 1.2MB !)
There are much better examples at user-centric development out there.
[)amien
Damien Guard BSc on December 7, 2007 12:01 PMI worked as a developer at Amazon for almost 3 years (Aug 02 - Mar 05) and I didn't do any of that stuff. If I remember correctly, Werner is referring to a program for a relatively small group of upper managers.
On the other hand, my team received copies of every customer feedback dealing with the features we owned, and we were encouraged to observe usability studies where acutal customers would use our new features.
In general, I consider Amazon to be a very customer-focused company, both as a once-employee and as a customer.
Yes! Yes! Yes!
One of the most salutary situations I've seen was when the developers were forced to actually speak to customer support (my team) after a new release didn't hold up under real-life load. I think they benefited a lot.
I've also heard developers talk about users being "inconsiderate" -- but for your typical user it is not immediately clear that when they regularly dump 10 file at once on an automated data import server, they may be creating problems if they dump 3000 at once.
I was in the situation that a member of maintenance engineering was loaned to me for a while because our team was critically short-staffed. I trained him in a number of easy processes, and ended up training half their team because they were just fascinated how hard it was to, say, set up a new account -- very easy on paper, but a lot of fiddly steps and decisions to be made to get it exactly as the new client needs it.
Chris Waigl on December 8, 2007 4:28 AMI'm seeing a lot of this kind of talk these days, and it misses something fundamental that several other comments have already touched on: Not everyone has the same skillsets.
That means that software engineers, etc will not necessarily have good people skills. It may be more dangerous to send a developer to talk to a customer then to send a sales rep to code an application. At least some other developers can overwrite poorly written code or just isolate the sales rep. Someone who is not a sales rep and is not really willing to play the salesman or the company line guy probably shouldn't be put into a position that he (a) didn't apply for and (b) might make comments to a customer that will cause problems.
I'm talking from a lot of personal experience here. I tend to be the classic, stereotypical computer geek in terms of social skills. The workaround I've always found for your situation is to cultivate someone within the team with the people skills and make it their job (and give them the power) to go to the customer and make work the process from both sides. This is where good project managers come into play. It looks great on paper to eliminate the middle men, but the truth of the matter is that all people are not interchangable and each have their strengths and weaknesses. Those properties must be worked with, not simply ignored.
Well yes, there're 2 ways: you either listen to the feedback or change, or you try to create the product and don't listen to feedback - you keep telling to yourself: "Hey, the market is ready, but people just don't understand how great my product is, yet". Kind of thing IBM did in 80's. Both aproaches work, but in a long-term perspective only the first one - IBM had to change, cause they were loosing the market share.
Alex on December 9, 2007 2:18 AMCustomer contact can be great, but it has pitfalls too, depending on the organization:
Nowadays, most users have a pretty good idea of what the computer is. But decades ago we would find they users so totally clueless they expected to 'ask the computer a question' and get an answer. We still run into that from time to time.
The actual people who know the data and input and output the data to the pre-existing recordkeeping or inventory system sometimes know perfectly well that as soon as the computer system begins to work, they will be fired. That's the whole point of the computerization. Naturally, they give strange answers to simple questions. It also can demoralize the software engineers. Or grow them up.
Computerizing an organization can change the workflow; So learning the existing workflow is used only in order to destroy it.
Just wanted to say, great point, well worth doing. For roughly 12 years I was running a small ISP, first as the founder/president, and later as the systems department manager and systems architect. From the beginning, we made it a principle that everyone in the company had to cross-train in both sales and tech support. This made it much easier to keep the company focused on the customers' needs; in turn, that helped keep us alive through the big dot-com bust. Now I'm back in software development and looking for ways to bring this philosophy to bear with my new employer.
Clifton on December 10, 2007 12:18 PM"This is a good case for open source software development making for better developers."
This is true to some extent, but only when focusing on products where the exclusive user is another developer or similar tech minded person. When it comes to general consumer products (with one exception I will get to) this completely falls apart because the developers do not think like general consumers, nor is there any sort of business structure behind the development process that ensures that customers perspective is considered even when the developers fail to do so.
Developers are willing to be far more forgiving and spend much more time on a task if the technology catches their interest, whereas a consumer wants it to be approachable, easy, and quick. For example, something like the Time Zone selector in Ubuntu (the user friendly distro... only by virtue that the others are much worse) would never make it into a commercial OS because someone in the business structure would have pointed out the design is horribly stupid. How is it more user approachable to select a city that happens to be in the same time zone that I live in (especially when none of the cities in my state, or in the neighboring states closest to where I live, are listed), from a list of thousands of cities, than to simply select "Central Time Zone, GMT -06:00"?
The developers in the OSS simply do not think like average users, nor do they make any effort to connect to or understand average users, and it shows throughout the products. For fellow developers, the usability is passable (but really, when it comes down to it, I think most of us can admit that it is much easier to enter a value in a GUI based dialog than edit some conf file. Also, storing passwords in plain text in a conf file is retarded) but it just isn't there for the average joe. They could benefit from the sentiment of this post more than just about anyone.
The one exception is firefox (at least that comes to mind), but I think it is worth pointing out that the project started because the UI design of Mozilla proper was so horrible that even fellow OSS developers hated it with a burning passion.
As for Amazon, I have sent feedback to them a good number of times, have recieved thought out repsonse promptly each time, and three times I have recieved follow up emails from developers or a program manager asking for more details and suggestions. I am really impressed with them. My one gripe is that I have to go through the customer support line to leave feedback. I think EVERY company should have a fairly visible way to leave feedback and suggestions. The Live team at MS may have a long way to go, but I certainly appreciate that it is MUCH easier for me to give them feedback (because all of the live affiliated sites have some feedback option) than it is with Google.
El Chupageek on December 14, 2007 10:20 AMThe utility of developers manning the support desk only works if developers are empowered to (and given time to) fix bugs. I've spent many a support rotation week doing nothing but putting out fires; I see the same bugs month after month. I don't have time to fix them when I'm on support duty, and when I'm off, I have priority tasks assigned.
Anonymous on December 14, 2007 11:01 AMI have to disagree very strongly with this idea. I didn't go through university to sit and hear some redneck who can't figure out what right click means waste 2 hours on the phone.
Now if there is a general issue with some of the software I am working on, then you can log a bug into the system and I will be happy to help.
As for meeting the customer to find out what he or she wants, that should have been done way before the support parts start.
Tommy on January 31, 2009 12:22 PMHey, cut me some slack.
I've only been in software development for two years.
Oh wait, that should be long enough to know better.
Don't cut me some slack.
Jon Abaca on February 6, 2010 10:14 PMI'm surprised that noone has commented on Agile methods as a way of closing the Customer/Developer (C/D) gap.Customer interaction is crucial to the success of any Agile project. By allowing the customer to take part in the development of a product, enabling them to sit down with the developers (on-site) and provide input and feedback, developers are never out of touch with customers and their needs.
The future of software lifecycles/process models will inevitably steer towards plan-driven/Agile hybrid processes, tied together with risk management techniques.
For those interested in finding out how the C/D gap can be closed and the C/D interface improved, check out "Balancing agility and discipline" by Barry Boehm and Richard Turner. It's a really great resource - not very technical though; it focuses more on the managerial aspect of software development e.g. processes.
ramon on February 6, 2010 10:14 PM"Without a basic understanding of your users and customers..."
Don't confuse customers and users - there are many software systems that perfectly satisfy their customers needs...basically because they're not necessarily going to be using it!
And yes, I'm looking at you, SAP - you're one of the worst offenders. Perfectly satisfy what CEOs and CTOs and CIOs want, but inflict immeasurable pain and horror to the minions who actually have to 'use' the software...
Even a once a week interaction (time-sheets) is too much...
Stuart Dootson on February 6, 2010 10:14 PMProgrammers don't need to visit the end users as much as the people who create the specifications of the software. It can't be so that you have a bunch of guys who individually try to create as good software as they can. Instead you need people who study general system and software usability in order to help the common designers. The programmers just implement what has been designed.
Don on February 6, 2010 10:14 PMI just had a not-so-software related experience of "customer pain" and I thought it appropriate that I share.
------
I am extremely frustrated with the level of customer service I am receiving. Recently my credit card expired, and I realized that my auto-payment wasn't occurring. I figured I better fix this before my service is shutdown or something, due to my inattention.
Since I get statements electronically I went to the online site to attempt to get in to fix things. But, yet again, I seem to have forgotten my password, so naturally I attempt to use the "forgot my password" option to reset things. That, unfortunately, told me that my reminder had "expired".
After looking in previous emails for a clue, then call into the 800 number to request that the password be reset. I then proceeded to be bounced around 4 to different people I got an answer that I need do it via the online chat support system. I should also mention that for each of them I had to give my address, my phone number, the last four of my SSN and my birth weight (ok, so not really the last one).
So I head over to http://www.comcast.com and click on the link. That guy then basically told me I had to setup another account. He couldn't reset the password. Nor could he expire/remove/delete any of the existing online accounts I've setup. Now, I have 3 email addresses I typically use, 1 work, 1 personal and one from college. I've used all of them to create new accounts, so it won't let me use any of them. I see no point to setting up yet another email address purely for the purpose of receiving bills from comcast, so I leave frustrated. At this point I'm seriously considering canceling my service after I talk to the wife.
In the end I called back to the 800 number to attempt to use that system to pay my bill. It presenting me with 2 options, pay using an automated system or talk to someone to pay. I selected the automated, but was directed to a customer support individual. Tell that individual my address, phone number, the last four of my SSN and my cats favorite chew toy (again kidding slightly), and what I was attempting to do. She offers to forward me to the automated system which I accept and I ned up back with the 800 number, again. I then select the same options and ended up with yet another customer support individual. Yet again I give my address, etc., but I also tell him about what's going on. He offers to take care of the payment and switches my account to hard copy statements. I'm happier, sort of, but then he asks me why I don't have digital voice service. Rather than explain that I'm not even remotely interested in additional services due to all of the time I've just wasted with the various customer service options I just say that I'll consider it in the future perhaps.
Ok, so now I'm complete. Then I get thinking that I ought share my experience. Now I should mention that I am a professional software developer, and that I develop database driven with based applications written typically in Java talking to backend Oracle databases. I've been doing this for more than 10 years, so I have a little experience with how applications should be put together. I'm also thinking that a blog I follow (coding horror) recently had a post about "sharing the customer's pain", and this experience would make a great example of what frustrates users beyond just the realm of software development. So I got back to my web browser, which normally is open to my email, and I see that I've gotten yet another electronic notification of my Comcast statement being available electronically. Sigh.
So in short, I'd like to hear from you what you're planning to do to lessen this, and the rest of the, customer's pain.
Mike Jackson on February 6, 2010 10:14 PMThe comments to this entry are closed.
Subscribe in a reader
Subscribe via email
|
|
Traffic Stats |