Business analysis and mobile applications | 2022

Why customers don’t see the value in analytics and how to deliver it to them

Often customers do not understand the value of a business analyst. It seems that these functions can be performed by other team members: developers, testers, project managers.

We do various projects: banking, e-commerce, and even government orders. And, of course, we have to explain to clients why they need a business analyst on a project. I tell you why this is the case and how to show the customer the value of an analyst.

Why the customer does not see the value in analytics as a separate member of the team

There are several reasons for this:

• There is an analytics team on the customer side. Usually these are large customers with extensive infrastructure: banks or the public sector. Inhouse analysts, as a rule, have never worked with mobile applications and do not know the specifics.
• Connecting an analyst increases the development budget.
• Past experiences with an analyst were unsuccessful. For example, because the customer didn’t see the results of the tasks.
• The customer thinks that the development team will be able to get requirements from him directly.

What projects need an analyst

Of course, not all companies need an analyst, and I have no goal to prove that we can’t do without one. At Crealeon, we realized that we needed a separate analyst when large customers came to us: mobile banking and large e-commerce.

Before that the tasks of the analyst were performed by the project manager: he collected and documented the requirements, understood the logic of work. On large projects his resource was simply no longer enough.

Let’s discuss what factors influence whether or not to define the analyst as a separate role.

The size and complexity of the project

➖ A startup with six features and a goal to roll out MVP in 4 weeks can do without an analyst.

➕ An analyst is needed for large and complex projects. For example, on a mobile bank project: a lot of logic, industry specifics and legislation. Just look at the recent Me2Me feature, which the regulator ordered to be developed as soon as possible.

It took two months to design from scratch the user experience with the feature and the interaction between the mobile app and the server. Not an easy task:)

Number of stakeholders in the project
Stakeholders, aka the stakeholders, supply the requirements. Each one has its own goals and is responsible for a specific area: sales, marketing, IT, production. Stakeholders’ requirements need to be identified, documented and taken into account in the solution design.

➖ It is possible to manage without an analyst when there are a couple of stakeholders.

➕ An analyst is needed on a large project where there may be as many as 10 stakeholders. With so many stakeholders, you need not only to identify the requirements, but also to build communications: understand how to manage their expectations, who makes decisions, what degree of influence they have on the project, and so on. This is a lot of work for which other team members do not have enough resources and skills.

Project duration

This factor depends directly on the size and complexity of the project.

➖ You can do without an analyst, as we said above, if the team develops the MVP in a few weeks.

➕ An analyst is necessary for large customers: they usually develop projects for years. During this time the project team on the contractor’s side and on the customer’s side can change, the project acquires new logic. The importance of maintaining a knowledge base and constant updating is especially needed on projects with a large number of features.

If you put a plus sign next to each of the “Analyst is needed” items, congratulations: you – surprise – need an analyst 🙂

What happens to a mobile app designed without an analyst

Consider the problems that can arise on a project without an analyst.

Unrecorded cases, missed deadlines and budgets, incorrectly working product
The problem: unrecorded cases pop up during the development stage or come back later as additions. They turn into additional tasks for development: this is a risk of failing to meet the agreed deadlines and budget, or giving users a product that does not work correctly.

For example, there is a task to make a food ordering application. On the main screen there is current information about the order: status, content, delivery time, and so on. The order is placed after payment.

But this information is not enough for the developer. It is not clear:

• How it will relate to order delivery. How does the system that distributes orders to couriers work? The order is received by the courier immediately after payment?
• Is there a refund for the order? If so, how will it be implemented?

Is it possible to track the courier’s path in the app?

The developer has to figure out the answers to the questions, spend time waiting for a response from the customer, and discuss with the designer how to account for this in prototypes. The time it takes to develop a feature increases several times.

“Crooked” logic and unaccounted for user scenarios

The task of the analyst is to see the product as a whole, to keep the system consistent, to identify the dependencies of features on each other and to aggregate the information obtained in the form of documentation. If you describe features in isolation from each other, the application will not work correctly. Irritation and negativity of the users are assured.

Let’s go back to the example of the food delivery app. The user has a promo code with a discount on the first order. He can enter it in the cart when placing the order, or in the profile. If the user enters a promo code in the profile, the discount won’t apply: the system has to defer the promo code until the order is placed.

The requirements for implementation were not clear enough. The developer implemented the logic in the following way: a promo code entered through the profile was applied immediately. The user would lose it, because there was no order. When this turned out, I had to clarify the requirements and redo the logic of the promo codes.

Why did this happen? When we described the requirements of entering a promo code for the first order, we did not take into account the case of entering a promo code from the profile. The developer thought it was necessary: what if this promo code would be delayed on the server. An analyst would have described this difference in requirements explicitly, and they didn’t have to rework the logic.

The peculiarities of iOS and Android platforms were not taken into account: there would be problems with the appearance and work of native components.
The main development platforms are two: iOS and Android. There are others, less popular. Often when working with mobile products, they are not taken into account:

Peculiarities of implementation for each platform: for example, in Android the work with cache is developed, and on iOS the work with data caching is more difficult to implement.

Native components for each platform: they significantly save development time.

A huge variety of devices with their own screen resolutions. The application should be easy to use even on the smallest screen.

Example: a picker for selecting a date. On iOS it looks like this:

On Android, it is:

The client had no special requirements for the appearance of the date-picker. But the designer wanted to make a creative and beautiful design: he drew a custom component with a day of the week selection animation. The developers took it to work: they spent several times more time than it would have taken to plug in the native picker.

Had there been an analyst on the project, he would have noticed this point in time, suggested using the native component and saved development hours without affecting the user experience.

There are other specific cases: to work through them, it’s not enough to be just a mobile app user. You need to have experience working with the “inner workings” and understand the peculiarities of an application.

Take, for example, authentication in an app with biometrics. Depending on the platform and vendor, the device may have:

• Touch ID;
• Face ID or facial recognition;
• Fingerprint.

In the description of cases, implementation and testing, it should be taken into account that some Android devices have both types of biometrics: fingerprint authentication and facial recognition. If this case is not described, the user will get incorrectly working biometrics or bugs in the design: for example, the text in the alert for biometric settings will not fit on the screen.

Unaccounted for screen states, which again leads to incorrect application operation, extended development time and budgets

Often designers consider screen states that occur in response to a user action: for example, the user has turned off the Internet on the device.
What states can be:

• screen loading and refreshing,
• errors,
• validation states,

when no data is received for the screen (for example, if there are no stock banners on the main screen, you need to display a stub or error state), animations.

If you don’t think through the states at the design stage:

• The user might get an endless app load, which is not a good thing.
• Developers will spend extra time waiting for the designer to finalize the missing states.

An analyst will point out the missing screens and states during the preliminary design review: the developer at the start of the feature can avoid wasting time on the review.

Here’s an example.

Customer: a Japanese bank with branches all over the world.

Objective: to develop a mobile application on iOS and Android platforms. Backend development and support is on the side of the bank’s IT department.

The situation: the bank’s IT department has its own analysts: they write backend statements, but they have no experience with mobile apps.
The task was to develop one of the main features of the bank application – the main screen. It consists of many elements: a list of accounts, fund balances, news and updates, and the ability to open new products.

Analysts from the bank wrote the terms of reference. At the development stage, the team ran into problems:

They didn’t consider in the design and didn’t describe the behavior of the elements on the screen: swipes, screen refresh capabilities, drop-down lists, animations. The bank analysts simply did not know that such behavior should be described, because they did not work with mobile products.

Screen initialization was not organized optimally. The client sent about 10 requests to generate the screen. The processing speed of a single request on the server was relatively slow, so the user had to wait 7-8 seconds for the screen to load. As the development progressed, it became clear that sending 10 requests when the screen was refreshed was unnecessary work. To get the basic information, only three are enough. The rest can be triggered by a specific user action in the application.

It is not clear where to take what information from: there is no mapping of models from responses to design requests.

As a result, the development budget and time frame increased. Instead of coding, the developers clarified the requirements.

How to show the customer the value of an analyst

In our experience, you can’t just tell a customer how well an analyst has come in handy on other projects. We realized that the most effective way is to offer the customer an experiment: introduce an analyst into the team and evaluate the results.

This could be preceded by a presentation of the new work process. Draw the process as is and the process to be. Highlight where the problems are now. Show how connecting an analyst can fix those problems.

Statistics and numbers are our everything. Every experiment should have metrics by which you can draw conclusions about its success. In the case of the analyst you can formulate such criteria:

• Average time to design a feature (without collecting business requirements – this remains the responsibility of the customer).
• Average time to review the ToR from the developer.
• The number of changes to the ToR after the developer’s review.
• An estimate on the feature’s development.
• Actual time of the feature’s development.

When communicating with the customer, back up any suggestions or arguments with facts, figures, and research results. Make a table and calculate the same costs in money, using the average developer’s rate per hour.

Sum up the results of the experiment together with the customer. Look at the statistics, collect feedback from the team, compare the old figures with the new ones. On the basis of the figures it is easier to draw conclusions about the effectiveness of the analyst’s work.
And remember that globally you and the customer are pursuing the same goal – to develop a quality product within the stipulated time and budget.

An analyst is needed for large and complex projects

An analyst is not a cure-all, but he is necessary for long-term and large projects with a lot of logic, features and stakeholders. And also – on mobile application development projects 🙂
Why?

• In large companies, several departments (and many stakeholders) are responsible for product development: the IT department, marketing, sales, and so on. Each has its own goals and objectives in the product, each is an expert in his field. The analyst collects, processes and formalizes the goals, tasks, and wishes of the participants in order to build a unified picture of the product.
• Both the development team and the stakeholders may change in a project. It is important to have an up-to-date knowledge base: an analyst is responsible for its creation and maintenance. The knowledge base helps reduce onboarding time and quickly find answers to questions about the product.
• Development participants see the product from different perspectives: the designer – from the perspective of UX/UI and components, the developer – from the perspective of modules, classes, architecture. Each has a fragmented vision. But a well-functioning product is a whole product, so it must be viewed as a whole picture. It is the analyst who looks at the product in general and from all sides (a so called “helicopter view”), forms a comprehensive view of the result and decomposes it: what must be designed by the designer, what must be developed by the developer.

To show the customer the value of the analyst’s work, an experiment is the best way to do it. This will clearly show that the cost of the analyst’s work fully recoups the budget savings that it brings.