5 reasons developers need to research real-world user experience

At the best of times, the dynamics of the enterprise IT world can be puzzling. This was brought home to me during a visit to Israel a few years ago. I happened to be working on an automation product, part of which was developed in Tel Aviv. In between speaking to customers, I had also set aside time to meet up with the engineers — both for my own education and to share some user feedback. As we talked, it became clear to me that the engineers had no idea how our product was actually used.

Now, it’s not unreasonable to think that the geniuses who actually craft the applications we all know and love would know exactly how they are used. There are very good reasons why they should, which we’ll come to in a moment. In the world of enterprise software, however that transparency isn't always there. I told you it can be puzzling.

1. Enterprise developers don’t work alone

People have an idea of the lone ‘rockstar’ developer, building a tool to scratch a particular itch that they have. This isn't too far wrong; lone-wolf programmers do exist, just not in the enterprise world. Almost by definition, these indie developers are building with their own needs in mind, at least to begin with, and are generally themselves heavy users of their own product. When it comes to the sorts of very extensive and powerful products used by enterprises, this hardly ever holds true, and the connection between users and developers is tenuous and indirect. My colleagues in Tel Aviv rarely had the opportunity to interact with customers, and instead relied on me happening to be in town with some slack in my schedule to validate — or not — the requirements they had been handed.So how can enterprise developers overcome this gulf and discover what users actually experience?

2. Developers must look beyond their coding silos

Developers shouldn't take all of the blame. I doubt many people code up a CRM or a financial analysis package as a passion project in their spare time, so you don’t get the sort of personal investment that people put into their passion projects. In the case from my story, that particular product’s codebase was humongous and already several years old (both of which are normal and expected). It is common for enterprise products to be under development over decades, to the point that no single developer can ever be familiar with the whole thing. Because of these two factors, normally developers tend to specialize in particular features or areas of code, such as frontend, backend, GUI, or networking. All this means that the overall use case which the software is developed for is so remote from their world that most developers might never even see a finished product run. They code their own bit, run the unit tests, and hand it off to other teams for integration and user acceptance - somewhat of a coding assembly line.

Don't get me wrong, this separation is not necessarily negative as it allows for deep specialization in truly differentiating functionality. The final product’s use case may also be something (again, like a CRM) which is not relevant to typical developers, and which is not naturally conducive to power users crossing over and becoming developers in their own right.

That said, there is still value in making sure there are good lines of communication between users and developers.

3. End-users never get the chance to speak to developers

Another reason why this gap appears within enterprise IT is the same one that is at the root of many other aspects of this puzzling world: product end-users very rarely interact with vendors. Take my visit to Tel Aviv as an example. We know for a fact that my colleagues had no clue of how their product was being used and by whom. This is simply because the system administrators who used that product everyday never had a relationship with the vendor. Instead, they went through the economic buyer within their own company — the person who held the budget and crucially the purchase power. When the relationships are set up in this way, it is very difficult for developers like my engineering colleagues in Israel to engage — meaning that both sides lose out on valuable, first-hand feedback.

What’s more, the result of this disconnected procurement process has predictably low levels of user satisfaction. It is a rare case when an enterprise product chosen in this way is adopted willingly by its users. Instead, end-users would prepare themselves for the boss to return all starry-eyed from some conference full of the latest bright ideas (4GL! Cloud everything! Agile everywhere!). When it came to voluntary adoption, it was (and is) far more likely for the traffic to be in the other direction, with consumer tools being adopted in the enterprise from the ground up.

4. It’s time to nurture the feedback cycle

Luckily, things have moved on since that visit to Israel, more than a decade ago now. That top-down mechanism for selection of software tooling is changing rapidly, and there are promising signs of a feedback cycle.

C-level IT leaders still have to sign off on large strategic deals, but thanks to the 'King Maker Generation' — an era where businesses are acknowledging the importance of developers — users have a much stronger voice in the process. In fact, where previously the first contact between user and vendor might have been a slick professional sales presentation to an executive, these days that presentation is almost the *end* of the process. By the time anyone with 'sales' in their title is involved, people inside the prospective client organisation have probably been vetting the software in some capacity for months or maybe even years. They will be the ones to go to purchasing departments with a technical decision already made, asking for help in negotiating terms of a support contract with outside vendors. This model gives both sides the opportunity to create tight feedback loops with existing users. Software products built around this sort of adoption model have a much better chance of fulfilling the needs of new prospective users, who can then start sharing their own feedback and guide further developments.

5, You need to get serious about user feedback

The most important aspect to take away is that these feedback loops should not rely on me randomly stopping by for a chat with the engineering team. Instead, the developer(s) should take responsibility and ensure they’re in direct contact with users. They must build this into the product development process itself. It might sound obvious but it isn't happening enough even today.

User groups should not be used only for marketing to a captive audience. A collaborative process involving power users, developers, and product managers have the best chance of successfully designing and evolving a product that people will actually want to use. Modern application development methodologies help this process along, breaking old-style monolithic releases into more frequent point releases. This agile approach makes it far easier to incorporate feedback early on, before too much development time has been spent on an approach that is out of sync with users’ requirements.

You don’t want to be like those engineers I spoke with all those years ago — in the dark and unaware of how good (or bad) their work might be. You also don’t want to be like their customers, forced into passive acceptance of a product whose features and roadmap are decided entirely without their input. The enterprise IT world is a puzzle, and understanding how your product is being used is the best way to solve it.