Many 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.
One 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
I’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.
For 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.
great 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?
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.
Our 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!
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
I 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.
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.
nice 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).
"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.
I’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”.
The 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.
For 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).
I’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.
“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.
