Users and other Business Analysis Myths

I had a number of questions I wanted to ask Doctor BA about various topics that business analysts had asked me on the road, but I was intrigued by his comment. 

“What do you mean? A metaphor for what?”

Doctor BA led me across the museum pavilion to the Coffee stand under a large green umbrella shaped like a palm frond. He got his coffee and we sat on a marble bench shaped like a strange hippopotamus and he explained.

The Mythological User

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

“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