Future for business analysts
A Business Analyst today is a kind of compromise in the field of software development. That is, not everybody realises that an Interaction Designer (IxD) is a crucial component when it comes to the software development yet everyone wants to create software. Business analyst is also the person who fulfills the majority of tasks at the earliest stages of the process, when the interaction between a customer and a software development company takes place. At the same time, business analyst is the very person who can eventually become an Interaction Designer and potentially significantly increase the quality of software products.
The Status Quo
Modern world of business is the world of software. You can have a look at The World’s Most Valuable Brands (by Forbes), and you will understand that software solutions play as important role as raw materials or manpower. Moreover, sometimes software is the dominant force in the world of business.
In 1999 Bill Gates wrote a book “Business @ the speed of thought”. In the book he describes a “digital nervous system”. Gates thought software would allow organizations to react on market state changes instantaneously. He also thought that without this competitive advantage organizations would not survive in the era of digital technologies. Today we can say with confidence that he was right. The organizations that understand the importance of software are already using some software products in one way or another. Sometimes buying a ready-to-go solution is enough but at other times customized software for a specific business project is needed, and at that point software development companies come into play.
The times when a single person could create a software product are already in the past. There are two major reasons for that:
- It is very hard to develop a product capable of competing with the existing solutions
- It is nearly impossible to be knowledgeable in all areas comprising the success of a digital product
To solve these issues engineers are collaborating and creating development teams. There are many highly specialized roles within these teams. For example Quality Assurance Engineer(QA), Search Engine Optimization Specialist (SEO), Digital Designer, Front-End Specialist, Marketing Specialist, Project Manager (PM), Software Engineers (focusing on technology stacks like Microsoft .NET, Java or Python). This role separation is very flexible and it is possible for a single person to have more than one role in a project. For example, backend software engineer can handle html-based issues or a QA engineer can be engaged in Software development.
There is also another specialist called Business Analyst (BA). This person is a kind of a “Public Relations Specialist” responsible for customer requests analysis and generating functional requirements important for the software development process.
The problem: BA as intermediator
A customer comes to a contractor with a problem or an idea. The main objective of any commercial organization is to make profit, moreover, it is also the goal of the customer. That enables us to talk about “business goals”, or “business requirements”. Customer is ready to invest money in the product development and wants to know what they will receive at the end.
The customer knows exactly what the product should look like. And it is true as for anyone directly involved in the software development process an interface of a software product is the simplest thing to understand. That is why the customer focuses on the user interface elements when trying to explain what needs to be done.
However, UI and UX both are important and require special training, investigation, and analysis. The quality of user interaction design can play an important role in creating a successful product. When the requirements are dictating what software should look like or how it should behave the customer is mixing the “business goals” with their personal vision on how the users will interact with the software.
And here the Business Analyst comes into play. A Business Analyst:
- Pays close attention to the customer.
- Makes notes and documents what the customer wants in great detail.
- Makes detailed analysis.
- Generates product requirements.
- Generates Wireframes and gets them approved by the customer.
Business analysts make great effort to make the project successful whilst keeping the customer happy. Working on different projects, business analysts acquire an empirical experience in UI/UX design and can identify which user interface solution would be more successful relative to the others. And BAs certainly use their experience at every stage of the project.
In many cases the customer would not listen to the BA’s opinion. I have once worked on a project when a BA suggested the customer: “Let’s design this in another way otherwise people will have difficulties using this.” To which the customer replied: “If they have difficulties then let them not use my product!”.
I think such situations are possible because from a customer’s point of view a business analyst is a mere intermediator between them and the software developers. And even when the BA has a good piece of advice to give, the customer disregards it seeing it as just an opinion of a random person off the streets.
BA’s expertise is subjective
If you think about it, you may come to the conclusion that the knowledge a BA has of each particular project is very limited. The customer is the most important and virtually the only source of information. BAs can use their experience from dealing with similar projects but this is absolutely not enough to prove their point of view on how a product should work and what it should look like. And the most important reason for that is that each product is unique and the users are unique. A BA does not have any proof because they know about the users no more than the customer. They know nothing.
The Result
As a result, the business analyst and the customer agree on what the product should be like. Most commonly they only make an assumption because neither party has any real information about the real users. The project requirements are becoming very flexible because nobody is 100% sure of anything. The requirements are changing all the time, functionality is delayed, parts of the project are getting excluded, the development team’s motivation decreases, the amount of legacy code increases and new functionality implementation becomes painful and expensive.
In most cases customer gets the software, the contractor - the money. The users are disappointed and annoyed with what they are left to use though. In cases when the product is some internal software, the customer hires special trainers who demonstrate to the users how to use the software. If the product is commercial then, most likely, the users will not use it and switch to an alternative.
Solution: Interaction Designers (IxD)
As I pointed out earlier, product success requires some understanding of the target audience. Customers can think that they know everything about the potential users but without specific research their opinion is invalid. This applies to the business analysts as well. In order to solve this problem we need another expert: An Interaction Designer.
Here are their main responsibilities:
- Investigate business requirements and potential ways of achieving them (communication with stakeholders and subject matter experts)
- Conduct user research (analyze quantitative data about users coming from marketing researches, conduct qualitative user researches using interviews, field observations, ethnographic interviews, focus-groups, user-diaries and other methods; analyze research results and generate user models).
- Generate prototypes (wireframes that are focused on user goals; during this process IxD is communicating a lot with development team to ensure that the design idea can be technically implemented; does usability testing with real users, heuristic evaluations with usability experts; analyzes results and improves prototypes).
At this stage interaction designer has enough data to advertise design solution to meet the business requirements taking into account real users’ needs and goals. Neither the business analyst nor the customers themselves can do that
- Support the process of “pixel painting” for user interface and development (usability testing and evaluations at every iteration; making changes in user interaction process if required).
Business Analysts are the Interaction Designers of tomorrow
Business analysts have the closest role to that of a IxD amid all software development specialists. They already know how to interview stakeholders and subject matter experts; how to build prototypes, and get functional requirements verified by the development team. They need to know how to conduct user research and identify their needs and goals. In order to do that business analysts are required to learn qualitative user research techniques, prototype testing approaches both with and without the user involvement, basics of graphical and product design.
Skills set like this is not just a perspective. It can be a definitive factor when it comes to creating a much more successful software product than currently available.
About graphic designers
Graphic designers (aka web designers or just designers) accumulate many usability aspects during their work on a number of various projects. However, their knowledge has empirical but not theoretical basis. They just do not have enough words to prove “why this red button should be in the bottom right corner”. Besides, communication skills allow business analysts to demonstrate empathy while “an artistic soul” will not allow a graphic designer to do the same.
What can the others do?
It is very hard to convince someone who is paying money that interaction design matters. It is not something you can explain by making a drawing on a paper napkin in a bar over a beer. And it is even a bigger challenge to prove that your team can help with the user interface design as well as persuade them that and it will be better than anything the customer themselves can create. If the customer wants to design the software interface themselves, what can you do? You can do the following:
Ask more questions
Every time getting a new feature request ask yourself and everybody around you:
- How are these features going to benefit the business?
- Why does the user want this feature?
You should always know the answer to these questions. This allows everybody to separate ‘useful functionality’ and ‘useless features’
Create user stories
User stories is a powerful technique used to simulate user interaction with the software. It will show you:
- Who the target user is;
- What the user needs to do;
- How the software product will assist the user in achieving their goals;
Here is an example:
As an internet catalog user
I do not want to waste my time searching for the new Harry Potter book
So I want to use global search to find the new Harry Potter book
Given I am on the home page
When I type in 'Harry Potter' in the global search area
I click 'Search'
Then I should be on the search result page
And I should see 'Harry Potter' result item
User stories is a popular technique used to describe functional requirements. Most of the time they don’t have any user research behind them and all what you see in the first three lines is just guessing. However, they help you to try to understand why somebody can possibly be in need of using the feature and how it should be.
In conclusion I am providing two links to the books that you can read to better understand my idea: