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.
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.
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…
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.
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.
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.
Discussed below are a few qualitative and quantitative approaches.
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:
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.
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.
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.
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.
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!