Users Have Problems, Developers Have Solutions

In the world of software, it is the job of software developers to solve the problems of users. Users present a problem, and the developers solve it. Whenever these roles are reversed, trouble ensues.

If you ever want to see a bloated, useless, complex piece of software, find one where the developers implemented every solution that any user ever suggested. It’s true that the users are the people who know what the problem is, and that sometimes, they have novel ideals for solutions. But the people making the final decision on how a problem is to be solved should always be the developers of the system, not its users.

This problem can be particularly bad when you’re writing software for a small number of users internally at an organization. The users who you are writing for often have inordinate power over you, by virtue of being executives or being close to executives. They can, quite literally, tell you what to do. However, if they want a solution that is actually good for them, they should try to refrain from this practice. If you trust a team enough to have them write software for you, then you should also trust them enough to make decisions about that software. If you don’t trust them, why are they working at your organization? A group of people who distrust each other is usually a highly inefficient group–perhaps not even really a “group” at all, but merely a collection of individuals all trying to defend themselves from each other. That’s no way to run an organization or to have anybody in it lead a happy life.

If a user wants to influence a developer’s decision, the best thing they can do is offer data. Developers need information in order to make good decisions for their users, and that information often comes from the users themselves. If you as a user think that a piece of software is going the wrong direction, provide information about the problem that you would like solved, and explain why the current software doesn’t solve it. Get information about how many other people have this problem. The best is if you can show numbers, but sometimes even anecdotes can be helpful when a developer is trying to make a decision. Developers should judge data appropriately (hard data about lots of users is obviously better than an anecdote from a single user) but they usually appreciate all the information given to them when it’s offered as data and not as a demand for a specific solution.

Developers, on the other hand, often have the opposite problem. If you want to see a piece of software that users hate, find one where the developers simply imagined that the users had a problem, and then started developing a solution for that problem. Problems come from users, not from developers. Sometimes the developers of a piece of software are also users of it, and they can see obvious problems that they themselves are experiencing. That’s fine, but they should offer that up as data, from the viewpoint of a user, and make sure that it’s something that other people are also actually experiencing. Developers should treat their own opinions as somewhat more valuable than the average user’s (because they see lots of user feedback and they work with their program day in and day out) but still as an opinion that came from a user.

When you solve the developers’ problems instead of the users’ problems, you’re putting lots of effort into something that isn’t going to help people in the best possible way. It may be enjoyable to assert one’s opinion, be the smartest person in the room, and cause the team to solve your problem, but it feels terrible to release software that ends up not helping people. Also, I usually find that solving the developers’ problems leads to a lot more complexity than solving the users’ problems. So it would actually have been easier to find out from the user what was wrong and fix that than to imagine a problem and grind away at it.

Now, I’m not saying that no developer has ever come up with a valid problem, and that no user has ever come up with a valid solution. Sometimes these things do happen. But the judgment about these things should lie on the appropriate sides of the equation. Only users (and preferably, a large number of them, or data about a large number of them) can truly tell you what problem they are experiencing, and only somebody on the development side (preferably, an individual who is tasked with making this decision after understanding the problem and possibly getting feedback from his peers) can correctly decide which solution should be implemented.

-Max