Without users (User Proxies)

Without Users (User Proxies)

Ideally, when we pretend to develop a software, we need to talk with one or more real users who are part of the customer team. But, the reality has the bad habit of punching Dilbert and us right in the nose and continuously we found our selves in one of two situations:

We have as primary contacts, people who pretend to guess how a final user wants the software behaves when only the real user actually knows it, and yet we have limited or no access at all to them.
The product is so innovating that we actually don’t have a real user in advance.

Unfortunately, very often is difficult to get the users that we need. For example, we could be developing a product with user all over the country, but we can’t bring one (or more) of them with us, to write requirements or user stories. Or maybe we could be writing software that will be used inside our company, but somebody says that we can’t talk directly with the users.

When we can’t get as many users as we’d like us to represent the different perspectives to the product, we have to resort to people or intermediary resources, also known as user proxies, who maybe are not users, but we need to include them in the project in order to represent the users and so deal with the two mentioned situations.

Warning

What I going say in rest of this post can be controversial and is subject to my personal experience but is also based on publications (that I always put at the end). This time I will focus on what characterizes each type of user proxy.

The user proxies selection can be critical to achieving the success of a project. The experience, motivations and possible agenda of a proxy must be considered. A user proxy involved in sales will have a completely different perspective from a domain expert’s. It’s important to be aware of these differences, that is why I’ll try to provide a synthesis of what characterizes some of them.

Proxies:

Final users supervisors

When we try to create internal use applications is common that middle management to be reluctant about to give full access to final users for a variety of reasons, so is very likely that you as a requirements engineer, business analyst, product owner, etc., end up dealing with supervisors and managers of the users on what you’re interested in.

We must be very careful when we dealing with those proxies, especially in public institutions that are very bureaucratic, because this they tend to fall in bad practices that try to minimize, dissimulate or hide during their process and operations.

On other occasions, the users’ supervisors intercede and want to represent the role of a user because they think they know more than the real users. But usually, the managers or supervisors have different usage pattern. You should be skilled enough to “turn around” that proxy and reach the final users as much as you can without offending the supervisor. In the section, What to do without users (or almost)? you can read what to do in those cases.

Development managers, development supervisors, development directors, development leaders and similar

This type of proxy is one the worst options unless you are writing software specifically for this type of user. Even when the intentions of this type of user sometimes are good, it’s likely this type of leader has his/her own interests and prioritize in a different way the requirements or user stories than a final user would.

This happens because this role tends to accelerate the introduction of new technologies, or in the worst case scenario, when there is too much technical debt or a disorganized operation, s/he will try to reduce her/his workload at the slightest opportunity.

Finally, the development managers usually don’t have experience as final users of the solution that is being built and they aren’t domain experts of interest. If a development supervisor es a real final user then you can consider him an appropriate domain expert, otherwise I advise you to avoid using her/him as a proxy if possible.

People involved in sales

The danger of use people involved in sales as proxies is that they usually tend to want to close a sale quickly and no matter what, which leads to a distorted vision about how a product should be built.

If the person in sales, lost the last sale due the lack of a specific characteristic, you can be sure that those people in sales instantly will include as a high priority requirement that characteristic or functionality. Another common situation is people in sales, according to the potential sale earning or commission tends to promise too much even with a small knowledge about other domains, with short-term benefit vision.

A company that places too much emphasis on lost sales or short-term profits may lose track of its vision and long-term strategies.

However, the people in sales can be a great conduct to reach final users and we should use them in that way. Ask to them introduce you to customers, join them in sales visits, in sales shows and promotion events, learn about how the products or services of your organization are exhibited and then talk to the users.

Domain experts

The domain experts are those who give us what we call experts’ domain and can be very important due to the knowledge that they have in the field of our product. Of course, some domains are more complex than others.

The domain experts can be great resources, but their usefulness is very dependent on whether they are current users or former users of the type of solution that we are creating. Knowing this we must be aware that this kind of proxies can make us create products aimed to their domain level, and if we are not careful we could end creating a too much complex software for the real users level.

Marketing groups

People or groups focused on marketing tend to focus more on the market or in niches themselves, rather than on individual users, so the result is that they concentrate more on quantities of functionalities than on the quality of them.

But do not dismiss our marketing friends, in many cases, they can provide us with valuable high-level information that can help us to establish relative priorities, but we shouldn’t expect a detailed vision for our requirements or user stories.

Former users

A former user can be a great proxy if their experience is recent. However, as with other proxies, we must be careful and consider that the objectives and incentives of our proxy are aligned with those of the current final user.

Customers

Customers are the ones who make the purchasing decision; they aren’t necessarily final users of the product. It’s important to consider the wishes of your customers because they, not your users, are the ones who sign the check to buy the solution unless of course, the final users and the clients are the same people.

The features of a product like this should be enough so that the end users do not shout too loudly; but they must also be those that attract the customer who makes the purchasing decision.

Trainers and technical support

Trainers and technical support personnel may seem like logical options to use as user proxies. They spend their days talking to real users, so they must surely know what the users themselves want, right? Well, unfortunately, if you use a trainer as your user proxy, you will end up with a system, that is, easy to train.

Similarly, if you use someone from technical support, you will end up with a system that is very compatible and easy for supporting. For example, someone from technical support can assign a low priority to advanced features that he anticipates will increase support work.

While ease of training and compatibility are good objectives, it’s most likely that they aren’t what a true final user would prioritize.

System analysts and business analysts

Many business analysts and systems analysts make good user proxies because they have a foot in the world of technology and the other one in the processes and operation domain. An analyst who can balance this background and who strives to talk to real users is often an excellent proxy user.

A problem that some analysts present is that they prefer to think about a detected problem instead of research about it to solve it. Another problem that I’ve encountered occasionally is they tend to spend too much time on project’s upfront tasks.

What to do without users (or almost)?

When access to users is limited

When the team needs it to work with a proxy, it’s important to be very quick and establish with the sponsors, the proxy and management with sufficient authority, the fact that it’s necessary to establish a small “advanced post” group formed by real users, in order to evaluate any initiative, theory or assumption, and achieve validated knowledge as soon as possible.

Be efficient and transparent by scheduling constant meetings of maximum established duration and at a constant pace to facilitate meetings and minimize external obstacles, making it clear from the beginning that the objective is to identify, write and prioritize user stories or requirements.

If there are really no users available

When a user is not really available and must use a user proxy, a valuable technique is using more than one user proxy. This helps to reduce the likelihood of building a system that only satisfies one person’s needs. When you use more than one user proxy, make sure use different types of proxy. For example, combine a domain expert with someone from marketing instead of using two domain experts.

If you are developing software that competes with other commercial products, you can use the competitive products as a source of some user stories or requirements. What features of the products of the competition are mentioned in the reviews? What features are discussed in the online newsgroups? Are the features discussed because they are too complex to use or because they are very useful?

Another technique that you can use when you’re working with a user proxy instead of real users, is releasing the product as soon as possible. Even whether you call it preliminary version, beta, early, etc., try to put it in the hand of the users as soon as possible and identify inconsistencies between the user proxy thoughts and the actual real users, so you also get validated knowledge. Even better, once the software is in the hand of one or more of the first users, you now have a communications path to these real users and can use that to talk with them about upcoming features.

Can you do it your self?

When you can’t find or access to a real user, don’t fall into the trap of thinking you know the users’ mind and you don’t need or you can ignore a user proxy. Even if each type of user proxy has some kind of inconvenience that makes her/him less desirable than a real user, most developers have even more deficiencies to pretend to be a real user.

In general, developers don’t have marketing knowledge that allows them to understand the features’ relative value, they don’t have the same amount of contact with the customer as the salespeople, they are not domain experts, etc.

Do you know another type of user? Do you have a different opinion about the proxies presented here?

*Sorry about my English, I’m not natural speaker :p. Don’t be grumpy and help me to improve 😀