Is app redesign inevitable?

In this article, I have summarized the typical cases where redesign is a sign of the evolution of an application or an entire industry, and when it is caused by errors in the initial design and development, and also highlighted those cases where redesign can be avoided.

My name is Elena Erohova and I am an analyst.

In my practice, redesigns have been almost as common as designing from scratch.

I have had to redesign many times both finished, working applications and applications that were stuck in the development process and had not even started working yet.

Redesign – means changing the device and functions of the application in order to obtain new results of its work, changing the project, and then the implementation of the software product.

Here I mean that a “project” is an image of the result of applied programming and a sequence of stages for achieving this result, recorded in a document.

When redesigning, it is necessary to create a new image of the result and a new plan for achieving it.

Redesign is almost always difficult, expensive and unpleasant.

Maybe it's possible to design an application from the start so that you don't have to redesign it later?

Reasons for redesign

It is impossible to completely avoid redesigning applications because, in some cases, redesigning is a sign of the evolution of the application or industry, rather than of errors made during its design and development.

Why do people redesign apps?

1. Redesign may be a consequence of the development of the application itself.

Example: You launched a small internal corporate social network that was used by 1,000 people and it handled the load well.

The development was so successful that you started using the same network to interact with 10,000 of your customers. And the application could not cope with the load, which means it needs to be redesigned.

This is an example of a redesign due to application evolution causing increased loads, rather than a development or design error.

2. Redesign may be a consequence of the development of the entire IT industry.

Example: You've been successfully managing your marketing and sales records for 10 years in your custom-designed, user-friendly CRM system, but every week you've been waiting 6 hours for a consolidated report to be generated on hundreds of thousands of sales transactions.

Everything was great. Daily work in the system is convenient, but the formation of a large summary report had to be set for the night and, if it was necessary to re-form this report, wait many hours.

Over the 10 years that you have been using your CRM, not only has your business grown, but your volume of transactions has grown. During this time, new technologies have emerged that can increase the speed of data processing several times over. For example, generate a report in 10 minutes, not 6-8 hours. And to do this, you need to transfer the application logic to new technologies, which means redesigning it.

3. Redesign can also be associated with the development of the environment in which successful applications are used.

Example 1: In the country, legislators introduced a new tax.

For example, when VAT was introduced, all accounting, warehouse, and financial programs were significantly revised.

Example 2: new devices or equipment have appeared on the market that can be connected to the application.

Until recently, all invoices in warehouses were entered into databases manually, and then it became possible to connect barcode scanners to warehouse programs. Now, in any warehouse, at any point of issue of orders from the marketplace, the movement of invoices in accounting programs is associated with reading barcodes.

In order to connect a barcode scanner to warehouse accounting programs, developers of warehouse and accounting programs have recently been massively redesigning and improving them.

Example 3: New technological sales channels have emerged through marketplaces and stores within social networks.

Just 20 years ago, everyone traded through offline stores, then online stores entered the picture, and now they trade through social networks and marketplaces. Trade accounting applications were once linked, integrated with social networks and marketplaces. That is, redesigned to adapt to new sales channels.

4. Redesign can also be associated with the experience of successful use of the application, when the experience revealed the need to add new functions.

Example: The online store is doing well with sales, there is a need to increase the average check and increase the number of repeat sales.

The owners of the online store ordered the development of a recommendation system.

They want to recommend additional products to new customers during their first purchase based on their statistics of simultaneous purchases of different products in one check (recommendations for increasing the average check).

And for existing customers who have already made purchases in the online store, the customers of the recommendation system want to make recommendations based on the history of repeat purchases (recommendations for increasing repeat purchases).

The implementation of recommendation systems entails the redesign of an online store that is already operating correctly and successfully.

Let's sum it up:

redesign due to evolution rather than errors occurs in cases where:

1) the success of the application and the growth of the load on it;

2) development or change of the environment in which the application is used and the emergence of new environmental requirements;

3) development of the entire IT industry or a specific technology stack, the emergence of new technological capabilities;

4) and in cases where, as a result of successful use of the application, new functions were required that users had not previously thought about.

All of these cases of redesign are normal, optimistic, and cannot be avoided.

Redesign due to errors

It's a completely different matter when an application has to be redesigned due to design or development errors.

There are several frequent, literally textbook cases, when a developed application has to be redesigned as a result of errors in the initial design.

1. Designing reports based on the residual principle

It is very common for an application to be developed with a lot of attention paid to the input data and the data processing processes in the application.

And the results of the application's work, outgoing documents, dashboards and reports are planned on a residual basis, at the very end of development.

However, during the development process, functions and data structures that should provide some important report, graph, dashboard, output document or other result of the application are missed.

2. Not taking into account status stakeholders who do not work directly in the application

Also often not taken into account is the “recipient of the application's output who does not have his own business process in this application.”

This is a situation where an application can provide an important result to some higher-level person who does not even have a login and password in this application, but is a status recipient of reports from the application.

For example, the board of directors of a holding company does not have access to the ERP system of a subordinate enterprise, but the board of directors must regularly receive summary reports from the ERP system.

Second example: no government employee has access to or works with the software of any ministry, but the government must regularly receive reports from the application used by that ministry.

When an application is developed as automation of business processes of a holding or ministry, the board of directors of the holding or the government, which does not have its own business processes in this application, are overlooked by the designers.

At the same time, in the case of a holding company, for example, the most important result from the implementation of the ERP system is received by the board of directors, and it is also the one that authorizes the allocation of a budget for the development of the application.

In these examples, both the board of directors and the government are important, high-status stakeholders. On the other hand, from the point of view of the application's functions, neither the board of directors nor the government act in the application, have access to it, do not call any functions of the application, and therefore they are not actors.

These design errors make sense if we think we are automating processes. With such a focus, we are simply missing out on important recipients of the application's output that do not have their own business processes.

But what if we accept the point of view that we are automating not processes, but something else?

We automate the delivery of results. With this focus, we will not miss the results of status stakeholders who are not actors.

3. Designing a role model based on the residual principle.

The third common design error is when an application is developed from the perspective of a super-user, a user with maximum access rights who can do absolutely everything.

And already at the very end of development, a role model is stretched onto the application, roughly like an owl on a globe. That is, unsuccessfully. It turns out that it is impossible to organize the necessary delimitation of access to functions or data without redesigning.

And in all three cases I have cited, the application does not live up to expectations and does not provide users and customers with the values ​​they expected.

And the application is subject to redesign.

What is the criterion for the need for redesign?

By what criteria does the application owner decide that the application needs to be redesigned (due to bugs or due to the need for development)?

An application needs to be redesigned when it does not produce the correct result within the constraints of the environment.

For example, it does not provide the required report (no result) or it takes a very long time to generate the report (there is a result, but the restrictions are not taken into account).

Or it gives an incorrectly generated report.

That is, if we designed the application correctly from the start, then it

1) gives all the necessary results,

2) these results are correct and

3) these results take into account the requirements of the environment.

If the application project is an image of the future result plus a sequence of steps to achieve it, then the image of the future application is a description of the sum of the results of the application’s work.

A project, or more precisely a pre-sale project, of an application is a description of the sum of the results of the application’s work under the constraints of the environment.

On the way from an idea to a finished application, it is necessary to first formulate the boundaries of the application (what the application does and what it definitely does not do).

This is a pre-sale project in which the customer and the developer agree on the vision of the future product.

And then the pre-sale project must be transformed into a technical project, a technical assignment.

Let's return to the issue of redesign.

The redesigned application in a redesign project has 3 types of deliverables:

1. Existing results that are generated correctly and need to be saved.

2. Existing results that are generated incorrectly and need to be corrected.

3. And missing results that need to be added.

What is the criterion of a well-designed application?

So, in order to design an application from the very beginning so as not to redesign it, we need to correctly describe the image of the future application as the sum of its correct results under the conditions of the environment constraints in which this application will work. And take into account the interests of both those stakeholders who are actors in the application and those who do not work in the application themselves, but are important recipients of the application's results.

This is a real criterion for acceptance of the correct operation of the application in the eyes of the customer/user.

Conclusions:

1. Only those cases of redesign that are caused by errors in the initial design can be avoided. Redesigns due to successful development of an application or an entire industry are inevitable.

2. The most common mistakes in initial design are related to either not taking into account some important stakeholders, or not taking into account some significant results that the application should provide.

3. To avoid redesign due to errors in the initial design, it is necessary to adjust the design methods in terms of the completeness of identifying stakeholders and the results of the application at the earliest stages of the initial design.

4. It is important not only to make lists of stakeholders and results, but to compare their hierarchies in order to get a correct idea of ​​the priorities in the application and not to miss anything really important, a priority for the operation of the application.

I plan to dedicate my next publications to stakeholder hierarchies and application performance results, as well as prioritization.

Don't switch over!