No matter what your expertise is, which super advanced programming skills you have, or which software development methodology you use, you will develop better software once you come face to face with the users.
Clearly, if you are a developer working on a mass-market application like Facebook or Spotify, you interact with end users all the time, but a lot of us develop enterprise applications that are used by specialists in narrow fields, so we rarely get a chance to meet them and learn about their experience working with the products we develop. It is not often that we get to hear about their frustrations, their needs, the functionalities they don’t really use, or the features they love.
Who are the users?
Most of the time, when I say ‘users’, I refer to end users. Yet it is important to note that there are other roles that also come into contact and interact with the application or solution during the life cycle of the product, like project leaders, functional analysts, or managers ensuring compliance with processes and standards, among others.
The telephone game
As I have stated before, there are so many people between the end users and the developers that the needs of the user could be seriously distorted by the time they reach the developer. If you happen to be a lucky developer, a functional analyst (or someone in a similar role) will talk with the end users and that same analyst will write the user stories. This scenario does not entirely eliminate distortion, but it can help dramatically decrease inaccuracy.
However, more often than not, there are several intermediaries and middlemen: analysts will speak with project managers that, in turn, spoke with the leaders of the end users, and these leaders will have relayed what they thought the end users needed, like a corporate version of the telephone game.
I was once part of a team developing an HFC network monitoring tool. The manager that had spoken with our analysts asked them to design the tool so that it would make 30 days of historical data available for searching, when, in fact, NOC operators (the actual end users) were only interested in specific events within a 4 hour period before current events. While it is technically true that 30 days of data necessarily includes the last 4 hours of current events, we could have built a much more efficient solution if we had had the unfiltered input of real end users.
The same developers build applications for different users
Another variable that should be taken into account is that, in general, the same team of developers will design and build applications for a wide range of end users. For instance, at Intraway, we mainly develop software for MSOs, and different applications are used at different levels within the client’s corporate structure. Each area has its own specific set of requirements, protocols and standards, and each area has members with a wide spectrum of skills and competencies. In this scenario, it is easy for developers to fail to notice the peculiarities or the precise scope of each operation.
“It’s not really my responsibility”
Fellow developers may argue that it is not really our responsibility, they might say that when approaching development tasks we should limit ourselves to only taking into account what is specified in the technical documentation provided by analysts and managers.
I believe that having an exchange with end users should be an integral part of our job. In the early stages of projects, we should work closely together with end users and analysts to see the big picture, and also to build informed consent, since features that don’t work according to what users actually need turn into change requests. This way, we can use our knowledge and expertise to suggest state-of-the-art solutions to user problems; we can leverage our knowledge to propose viable answers to their exact needs, and thus contribute to creating truly awesome products.
Okay, you convinced me, what can I do?
Many companies will not actively send developers to clients’ offices to meet the end users, mainly for reasons relating to cost and organizational issues. However, I believe meeting the end users is a completely valid proposal, particularly when it comes to medium or large-size projects.
If this is not possible, you still have the option of communicating with those areas in the organization that do have direct contact with the end user (support, professional services). Even analysts will do if you approach development requirements from a different angle, really trying to understand the needs of users instead of just discussing user stories in isolation.
