I didn’t realize he was asking a rhetorical question, so I answered, “someone who uses a system”. He looked at me sadly and shook his head,
“I understand that is what the term is used for, but can you point me to a user. Don’t answer. You could probably point to any number of people around this museum who would be users.
That man over there is using his cell phone, some app or other.
The nice lady who fixed my coffee entered the transaction on a computer in her stand to account for the money and the inventory. She is a user.
The docent over there is checking her tablet for some reason. She is using a system.
And we, my friend, are users as well, I suppose, since our presence was recorded by an electric eye as we entered the room. The device read the information encoded on the badges we are wearing that we received when we came into the museum.
Since we are interacting with a computer system, we are users, too, no? And we would be users of the museum and all its facilities whether we have a badge or not.”
I was about to embark on a short dissertation about active and passive users, when he held up his hand signifying another rhetorical question.
The point is that we in business analysis commonly refer to the user for specific purposes, when there is no such thing as a specific user. It is an amorphous being as real as one of those mythological characters on the wall over there. How can we actually determine what a system needs on behalf of a ‘user’ when we continue to define and discuss something so vague and undefined, and, well, unreal?
“I submit that we eliminate the term ‘user’ from the business analyst vocabulary except when actually referring to an entity we don’t know about yet. We certainly know there will be ‘users’ of a web site to be built even if we don’t know who they are. But eventually, and the sooner the better, we should define the ‘user’ and make it more specific.
People who work with user interfaces define personas that make the concept of the ‘user’ specific enough to specify the user interface design. An actor in a use case is also a step in the right direction. You don’t employ the term ‘user’ to define an actor because the actor represents a role that uses the system. The name of the actor is the role, like “accounts payable voucher enterer”, or “sales administrator’ or ‘goods purchaser’.
But if we as business analysts are working to create a solution that is usable and attractive to a class of user, perhaps defining a persona might be a better approach. Make the ‘user’ real so that we can talk about the user as though they are a real person, and not a phantasm. Reduce the ambiguity and mythology and make it real. Then you can define real requirements. Give this cloud called a ‘user’ a name, a face, a history, and most of all, some emotions, and then define what is needed to solve that real person’s problems.”
Doctor BA paused to take a big gulp of coffee. “And”, he continued.
”This concept also applies to the agile folks amongst us. When discussing user stories with the business analyst and the developers, it is significantly better to describe a real ‘as a…’ then a vague one that can be misinterpreted. for example . saying, ‘as a customer I want to buy…’ is quite vague considering that any company selling anything has all types of customers which might each require a different approach. And you should never have a user story that begins, ‘as a user…’ “
Doctor BA stood up, his coffee cup empty. He walked away from the trash can however and back toward the coffee stand to get a refill and I knew he had more to say. There we stood behind a couple with two children. The children were looking at all the snacks and fruits and the various menus scattered on the front of the stand trying to make up their mind what they wanted. The man ordered bottled waters for himself and the woman and tried to urge the children to make up their minds. He suggested that they should already know what they wanted since they had asked to visit the stand. And finally he pointed out that they were holding up the line. Doctor BA and I were the line. Finally, the transaction was complete and Doctor BA got his refill and as we walked to another room of the museum he continued.
The User Knows What He Wants Myth
“A few centuries back my wife and I had a disagreement about shopping. I had said I liked shopping. She was impressed, but when she took me shopping I clearly was not enjoying myself so she challenged me about my attitude. ‘I thought you liked shopping’ she said. ‘I do,’ I replied. ‘But this is not shopping. We have been through dozens of stores and you haven’t bought a thing.’ She replied, ‘I said we are going shopping, I didn’t say we are going buying.’ My definition of shopping is to go to the store and buy what was needed and come home. For her shopping was a social event that may or may not include purchasing something."
“So it is between the solution team and the business community. We business analysts, as customer facing members of the solution team, have a need to get specific, unambiguous, clear specifications so we can as a team turn those specifications into code, into an operating system that solves the problem. The business wants to wait and see what happens before they commit to a specific. They need to see a lot of different options before they decide, if in fact they decide at all. We are looking to buy. They are looking to shop. And there is a clear gap between us. Since in the end it is they, and not we, who are going to actually use the thing, it makes sense to let them shop and wait until they make a decision. How can we do that when we have to come up with definitive, unambiguous, clear requirements for what to build? Prototyping is probably our best alternative. Keep showing them options and variations so they can comparison shop. After all, as is the call of the determined shopper as well as the business person, 'I am not sure what I want, but I will know it when I see it.'"
We were at the lobby of the museum’s mythology section and I realized that there was a whole second section we had not visited. I decided that would best be left for another time. I steered Doctor BA toward the exit.
I asked, “So you are saying we shouldn’t believe in myths?”
“Some myths are not harmful. You can believe that the moon landings were all faked or the world is flat and that will likely not cause you any problems other than some heavy arguments. Some myths are entertaining. We love the movies about the myths, and let’s face it, most of the plots nowadays, like the superheroes or Avengers, have their roots in mythology.
But a business analyst believing in myths such as these may find trouble awaiting.
The business analyst’s entire attitude or mindset may be based on the belief that the business person knows exactly what they want, for example. Then the business analyst will perceive their role as being a collector of requirements rather than an analyst whose job it is to solve problems. And this might not work too well for the business analyst and also for the organization. Many of the issues in business analysis are because the business analysts are too dependent on the business and the analysis is mything.”
I just stared at him as he walked away down the wide marble museum steps
Author: Steve Blais, PMP, PMI-PBA
Steve Blais, PMP, PMI-PBA, is an author, consultant, teacher and coach who has nearly 50 years’ experience in Information Technologies working as a programmer, project manager, business analyst, system analyst, general manager, and tester. He has also been in an executive position for several start-up companies. He develops business analysis and agile processes and trains business analysts, project managers, and executive for organizations around the world. He is the author of Business Analysis: Best Practices for Success (John Wiley, 2011) and co-author of Business Analysis for Practitioners: a Practice Guide (PMI, 2014) and a contributor to the Business Analyst Body of Knowledge, V3 (IIBA, 2015).