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.
I 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
I 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.
I’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.
Customer 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.
“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.
The 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.
I 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.
Hey, 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.
I’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.
“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…
Programmers 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.
I just had a not-so-software related experience of “customer pain” and I thought it appropriate that I share.