Skip to main content

Efficiency in Business Software – Part 1

Why it’s important and ways to improve.

Advancement of technologies in software development and deployment, and the emergence of the cloud have drastically lowered the barriers to entry and time to market for business software products. If you are a business software vendor, you could be facing stiff competition already. Else, you will soon be.

How can you ensure you deliver better value than the competition?

The feature set and its alignment with business processes of the target customers would naturally establish the base value of the software product. This is something you take care of, by default. But what is often overlooked is the efficiency - i.e., how efficient the product enables the said business processes to function, resulting in an increased throughput. Efficiency could make your product a winner or a loser.



Value of Efficiency

Well, it’s not rocket science! Let’s take a simple example: Imagine a ‘window’ (a graphical user interface) of a banking system, which has been designed for a banking executive to use when catering a walk-in customer.   


  • A banking system from vendor X might provide this window, which requires 20 clicks (on average) when serving a single customer. Total time spent while interacting with the window measures, say, 1.6 minutes (on average).
  • Vendor Y has a banking system. Their window for the above function requires 17 clicks (on average) and the time 0.9 minutes (on average).


Now, if the executive handles, say, 100 customers per day, the time saved by choosing Y over X is:

       (1.6 – 0.9) x 100 minutes = 70 minutes

If the bank has 50 branches, each employing, say, 4 executives on average, for the total of 200 executives, the time saved per day is 70 x 200 minutes = 14,000 minutes ≈ 9.7 days

The bank saves 9.7 man-days each workday just on that single window by using System Y. If the bank was using System X, they would lose 9.7 man-days every workday just on that window!


A banking system can have hundreds / thousands of windows…


Efficiency improvement – the challenge of discovery.

Having UX engineers onboard and having experts with years’ worth hands-on experience in the target domain will save many miles.

However, gaining insights on ‘how well the product functions’ and making it an integral part of the development process is likely to provide you a more persistent outcome. Before discussing why, let’s try to look at the underlying problem.



Figure 01: Communication of requirements
                                      Figure 01: The communication of requirements


A business software system is essentially a solution to a specific business problem. The problem is communicated in the form of requirements.

Typically, the requirements will be communicated at different levels of abstraction. For a bespoke product, for example, the management of the customer and the vendor may communicate requirements at a more conceptual - strategic level. Consultants (and/or business analysts) may sync up at a level more granular – more functional. A large scale product would require multiple such levels. In case of Agile, product owners will also participate from the vendor’s side.

Engineers, however, receive concrete requirements from the team’s product owner or the consultants (and/or business analysts). As the ones who actually develop the product, is there a way for them to know what the end-users really want? Do they have a complete-enough picture of the ground reality?

Often this is the root cause of a product being developed to deliver the requirements on paper but doesn’t necessarily enable the user base (the workforce) to achieve their full potential producing an optimal level of throughput. There’s no magic formula to take us to the paradise. But there are some simple ways that can make things far better.


Efficiency as part of Development Process.

Figure 02: Continuous improvement of efficiency
   Figure 02: Continuous improvement of efficiency


Optimizing a system for efficiency can be integrated into the development process. Performance metrics are collected and analyzed. Changes necessary to improve efficiency are identified and carried out. The changes are then implemented (deployed) in the target environment(s) and assessed for expected improvements.

In a continuous delivery setting, this will also give you the freedom to experiment new ways to improve in small steps at a certain degree of risk. You make changes and collect analytics. Keep the changes if they’ve yielded improvement. If not, or if this has resulted any negative sentiments in the user base, rollback the changes in the next incremental release. 

By integrating this cyclic approach into the development process, the efficiency of your product will keep on increasing by means of continuous improvement.



Ways to improve.

Discussed below are a few qualitative and quantitative approaches.

1. Directly Involve end-users in the development process

If possible, you can request the customer’s consultants to bring along a good user or two to the Agile sprint demos. Even if you are following a classical model such as Waterfall, there’s room to get the involvement of end-users, at least in the requirements stage.

There are 3 kinds of users around a typical business application:

  1. Regular user: uses the system through the whole day every day. She expects the right things to be at the right place - most frequently used features within the closest reach. Expects convenience and productivity.
  2. Power user: an experienced / expert user who would love a CLI (command line interface) over a fancy looking GUI (graphical user interface) if that enables her to achieve her level best. Ready to compromise convenience over productivity.
  3. Occasional user: a user who doesn’t remember how she did it last time 3 weeks ago and doesn't have time to recall or find help. Expects the system to take her through the steps of the functional flow.

Make sure you identify the correct kind(s) of users for the functional area that’s to be developed. The discussions can be done online if the parties are located in different geographies.



2. Monitor on the fly

One of the most accurate ways to gain insights is to measure the product in action, via collecting analytics programmatically.

For example, you can log the visits of the fields and windows (traversal of keyboard focus), along with how much time the user spent at each. You can collect the frequencies which might reveal where the users have visited the most. Doing this doesn’t involve much technical complexity, but the results are quite powerful.

For example, you might discover workflows that have not been identified in the specifications but used in practice. You would then refine the design so that users can do things faster and with less effort.

Logic can also be optimized for performance by measuring the time taken, starting with the most frequently used ones that are noticeably slow.


Figure 03: Analytics of clicks on a webpage depicted as a heatmap (red – higher, blue – lower).

Figure 03: Analytics of clicks on a webpage depicted as a heatmap (red – higher, blue – lower).
Image Credit



Pay attention to the data that you collect. Whatever collected should comply with the agreements with your customers and should not violate any laws / regulations of the jurisdiction(s) the data is collected, transferred and stored.



3. Interviews

Developers can talk to end-users via interviews. This can be a one-on-one or a discussion with multiple developers and multiple users. This can quickly reveal the pain points of the existing system, features that they believe the new system ‘must have’. A suggestion coming from an experienced user can be quite valuable.

You can collect as many suggestions as possible, without any commitments. They can then be filtered out, refined and integrated into the backlog.


4. Ethnography

This is a technique that has been borrowed from social anthropology. In our context, the consultants (business analysts) and/or engineers visit the customer site and passively observe how the end users use the existing system. The observations are documented and analyzed. They would be used as input to refine the existing requirements or to create new ones.

Though this looks quite naïve at first, this is pretty much the only means of discovering implied requirements. That is, the features that the users are so familiar with, that they never occur in one’s mind even to mention.

Implied features are often the ones executed very frequently, hence of high value.





We have discussed the benefits of improving efficiency of a business software product and a few ways to do so. We believe this would have helped by means of giving your product a competitive advantage.

What we have discussed so far are the techniques to make horses run faster. In the next blog post, let’s try to explore how we can invent a car!



© 2021 Creative Software. All Rights Reserved | Privacy | Terms of Use