How We Estimate Analytics and Design Services

Clients often turn to Azoft with ideas for interesting projects. However, they are not always sure whether it is possible to effectively bring their ideas to life, whether these ideas are well thought out, and most importantly, what budget will be spent on implementation.

Naturally, customers are worried about the future of projects. The market is full of applications that won’t be remembered by users and will not even be successful. In 2019, users downloaded 204 billion apps to devices. Hardly any of the installed apps are as popular as the top ones that are known to millions of users: Instagram, WhatsApp, Facebook, TikTok. Hundreds of projects disappear from the app stores, even though millions were spent on them.

To understand whether it will be possible to implement a new application and how much it will cost to develop it, you need to evaluate it. This applies to analytics, design, development and other work that will be performed when creating a product. Estimating the cost and time spent allows the client to choose the right contractor based on the price-to-service ratio.

An analyst helps businesses and developers more clearly define software requirements. The analyst gets involved in the estimation phase and defines the project’s boundaries based on its business goals.

In this article you will learn how we, at Azoft, estimate analytics and product design, what types of estimation we use, and what their accuracy depends on.

Types of estimation

To estimate analytics and design service, a client request must meet some requirements. It is important to understand that, without the initial data on the project, you cannot get an accurate estimate from the development team. Even a rough estimate requires some input information.

The accuracy and quality of the estimate depend on the background information and the preliminary work done. Each component of the project is estimated by a specialist who will deal with this aspect of the development process. The employee responsible for the project chooses who will make the estimation. Such an approach ensures a high-quality estimation of any service and brings developers into the project earlier.

We use two main types of analytics and design estimation and two approaches to do this work.

Depending on the initial data and the client’s wishes, we form estimates of varying degrees of detail and accuracy – from a rough estimate to a detailed and accurate one. Next, we will explain how to get any of these options.

Estimation of analytics

The analytics approach can involve pre-project analysis or creation of documentation during iterative development. The choice of approach is reflected in the depth of the assessment. An accurate assessment is given for pre-project analysis. The assessment for documentation in the process of Agile development can only be approximate. The same can be said for the rest of the work.

To get a rough estimate for the pre-project analysis, it is enough to have the clearly formulated business goals of the project. To get an “accurate” estimate for the pre-project analysis you will need:

• an understanding by the client of business goals, as well as formulated requirements for functionality and features of the future product
• a vision of the project boundaries and certainty in the priorities of feature development.

If the client understands the general direction of work on the product only at the level of an idea, and there are no high-level requirements for software, our estimation for the pre-project analysis will be rough. Its purpose will not be to detail the requirements, but to define them. The boundaries of the project will be made clear only in the process of developing the documentation.

To estimate the analytics performed with the Agile approach, you need a Vision document, confirmed by the client. You also need to understand the size of the project team, its approximate boundaries, the order of distribution of tasks for analytics and the estimated volume of documentation.

The volume and content of the planned documentation determine the analyst’s workload and the number of hours he will spend during each iteration (sprint). Depending on the requirements for a specific project, analytics can be carried out outside of the sprints.

Normally, we estimate analytics based on screens or modules. Each of the approaches allows you to get the amount of hours that will be spent on work.

Estimation based on screens involves listing the likely screens that you might need to develop your application. When estimating, we take into account screens for all roles that will be developed at Azoft.

Screens are divided into:

1 Simple

They consist of one or two fillable fields and don’t imply some alternative scenarios. Simple authorization is an example of this.

2 Average

Includes three to four fillable fields. These screens are characterized by: variability of data, compliance with requirements for validation, animation and support for alternative scenarios. A registration screen with multiple roles is an example of this.

3 Complex

More than four fields and a wide variety of input data are assumed. Many alternative scenarios are supported. For example, a chat window for a user, a list of products for an administrator.

If the screen seems more complex (for example, a dashboard with variability), it is “split” into several screens during evaluation, or it is evaluated as a module.

Estimation based on modules

By module we mean a functional block of an application that allows a role to perform a specific task. An analyst can evaluate a module for several roles at once. It is important to write this down in the comment accompanying the assessment. For example, the “chat” module includes work on the development of the interface for both the user and the administrator.

The assessment by modules is usually done in a matter of days. The analyst estimates how long it will take to clarify, agree upon, and formalize the requirements in the set of artifacts selected by the stakeholders.

Estimation of design

We provide a rough estimate for design services if your project already has a high-level description of tasks and features, and its boundaries are defined. You also need to understand which platforms the product will be presented on (web/mobile), the approximate number of system screens and their purpose.

For a more accurate assessment based on the pre-project analysis, you will need more information on the project, specifically:

• our cases, confirmed by the client, or TK, which describes the functionality according to Babok notations
• the development priorities of features, platforms and screen resolutions for the team and the client
• the team’s understanding of which parts of the system are needed to develop a full-fledged design, and for which – schematic layouts (wireframes) are necessary
• an idea of ​​whether our prototypes and their descriptions, confirmed by the client, or prototypes developed by a UX specialist on the client’s side (within the framework of Material design requirements or iOS guidelines) will be used in the work.

To design a project during software development (that is, within an Agile approach), the team will need a Vision document confirmed by the client. We clarify the estimated scope of tasks based on the main factors: target platforms, screen resolutions, adaptability, the need to design for alternative scenarios. Taking into account the understanding of the client’s business requirements, we determine the composition of the project team and plan around the workload.

The Agile approach usually makes a rough estimate of large, high-level blocks. The size of the check that the team receives at the scheduled time (for example, once a month) depends on the hours worked, and the designer’s hours depend on the amount of work that needs to be done during the specified period.

Assessing project tasks begins with diving into its context and answering the questions of what the team will do and why. To evaluate concrete artifacts rather than abstract works in a vacuum, we must correctly identify the stakeholders on the project. Sales and the specialist responsible for project evaluation are involved in their determination. The client’s expectations are matched against the team’s expectations.

On the client side, stakeholders are usually owners, managers, shareholders, or a product manager or other employee responsible for a product within the client company. From an IT company: developers, project managers and QA specialists among others.

Project stakeholders help clarify the list, structure, composition and quality of the required artifacts. To make the conversation substantive and to make it easier to understand what artifacts are in question, we use templates and semantic blocks, such as Role-cases and Description of prototypes.

We evaluate the quality of the submitted documents and compare them with the task. It is important to understand if the received documentation is sufficient to prepare an estimate of the required accuracy. If the documents do not allow for an assessment, the team seeks to further clarify the business requirements and prepare the missing artifacts. We pass on to the client the questions that our stakeholders have.

If the provided documentation is sufficient for the team (or all artifacts have been prepared), we determine the stakeholder requirements for the artifacts that are awaiting evaluation for development. Now you can start the assessment itself.

Conclusion

Now, we have shared our approach to work on analytics and design evaluation. It assumes that the team is in constant dialogue with the client in order to better understand his vision of the project. Our experts are focused on an individual approach to products and maximum immersion in the business context.

When evaluating work, we clarify which details of the project are the most important and which are secondary. As a result, the client gets a clear idea of ​​how to implement the application, how much money will be needed for the design, analytics and, in the future, development. This allows you, the client, to carefully consider the project development strategy.

A detailed project estimate can be obtained when the requirements for it give a complete or almost complete picture of the functionality. For example, when interface layouts have been developed for the product, or there is a textual description of roles and use cases.

Often a description of the facts is not enough to prepare an estimate of a given level of detail. Does the app need integration with a payment service? Are you planning an implementation for tablets? Answering these questions in a timely manner increases the quality and depth of the assessment and guides our work.

Analytics is not always part of the software development process. It happens that customers independently perform a business analysis of a product or apply with a list of requirements. Based on our experience, when clients order analytics services and its assessment from a developer company, it is easier to achieve a unified vision of the project and make a correct assessment of work and budget.

If you want to order an appraisal of analytics and app design and are interested in working with Azoft, please contact info@azoft.com. We will provide you with a professional assessment of the work, help you understand the prospects of the project, as well as the possibility of its implementation and its transformation into a popular product.