Evaluation Report

  • Category:
  • Document type:
  • Level:
  • Page:
  • Words:

3Evaluation Report


Evaluation Report

User Audience, Settings, and Interaction

The mobile banking app under evaluation is that of Suncorp bank. The user audiences for this particular application include depositors and individuals engaged in repayment of mortgages and other bank loans. Besides checking balances and making regular follow-ups of their repayments, users can also check the current interest rates, the expiry date of their credit cards and their transaction history. The app is also available to users who wish to interact with the bank on making enquiries regarding the possible interest rates charged for loan and mortgage services (Suncorpbank.com.au 2016).

The application adopts a friendly user interface where the main screen displays phone-specific settings, the various account types such as the holiday account, my cool account among others. The various types of loans that the user has taken are also displayed in the interface with the current balance. There is also a separate provision for the main account. Before one accesses the main window, the user is required to log into the account using a token code and a username. A critical part of the application that the developers have integrated into the settings is the ability of the user to setup quick share where they can get their account balances without having to necessarily logging in (Suncorpbank.com.au 2016). While this is a great feature the downside is that it is vulnerable to intrusion if the login code is disclosed to third parties. Ideally, the interaction developed by this application is such that it makes it possible for the end users to get a detailed previse of their transactions besides having the capability to pay bills using the same platform.

HCI Evaluation Model

The evaluation designed to test the interaction was based on three key functionalities of the application: the display time of historical transactions, the ability to seamlessly engage end users with prompt responses upon making USSD requests, and the delay time in confirming sending and receipts of money to third parties. The first evaluation criteria offered a rather qualitative measure for evaluation while the second and third were more quantitative in nature. Accordingly, the key considerations that were made in evaluating the first aspect of the data relied heavily on a descriptive approach where the response was found to be that the application was very effective in showing the transaction history records. Moreover, the records were not only accurate but were also presented in real time, a factor that was highly indicative of an application that had been designed with the end user in mind. However, for the other two metrics, a more quantitative criteria had been engaged whereby recorded time sets were used to measure the effectiveness of the application relative to the expected standards. In this regard, the average time taken to process USSD requests averaged at 5 seconds. While this was reasonably fast, it could have been more efficient and should have ideally taken up to 3 to 4 seconds. However, based on the consistency in which each of the transactions was carried out with, it can be argued that the transactions were processed within acceptable time limits.

Additionally, the delay time when making confirmations and receipts was found to be rather long, with the averages coming to 1 minute and 20 seconds. Ideally, this is dependent on the general architecture of the banking system, although it cannot be denied that the interaction between the banking application and the servers in the bank played a fundamental role in the outcome (Chen, Gu, and Xu 2014). Compared to our expected average from our evaluation instrument, this particular area seemed to lag behind.

Testing the Instrument

The dummy evaluation used in testing the mobile application involved using a demo account to evaluate the parameters and metrics revolving around the efficiency of the application. The first step involved creating dummy transactions over a period of three months and then scrolling through the transaction history. The results showed the total 30 transactions within 9 seconds, thus, proving to be a rather seamless aspect of the application. There was zero lag time and all the transactions were displayed with the precision that they had been added with to the application.

The next metric involved making some dummy requests such as those of bank balance and loan balances. The observable aspects regarding these transactions is that all of them required for a confirmation message before sending. The longest transaction took a total of 8 second while the shortest to 3 seconds. The manner in which the interface was designed was such that it was inherently difficult for the user to make errors while making a particular enquiry. However, this only meant that more time was spent. Notably, the 8 seconds was spent when making a transaction enquiry on a loan that had been repaid over a span of five years. The longer and more complicated the loan repayment criteria was, the longer time it took for the USSD transaction to be processed. Similarly, bank balance enquiries took the shortest times of between 3 to 5 seconds.

The delay time in sending confirmations of receipt and payments of money were equally evacuated through the demo account. The most notable observation was that it took the receiver of funds longer to get notified of a successful transaction that it took to get the notification that money had been sent. In this regard, the receiver took a maximum of 3 minutes to get a message that money had been received while it only took the sender one and a half minute to get a notification that money had been sent.

Identified Issues

Some of the major issues that were detected in the interface included the evident delay time and notifications of sending and receiving of money. To rectify this, the bank can develop a more integrated system whereby the banking systems can authorize the transaction first and then make the confirmation with time (Ezumalai, Aghila, and Rajalakshmi 2010). That way, it would be possible to save enormously on time spent making confirmations with the bank. Moreover, as disclosed by the evaluation instrument, transactions that involved more data spent longer periods of time to be synchronized with the application. To reduce such lags, the application could be developed in a manner that it auto synchronizes whenever data access is enabled (Chen, Zhang, and Zhou 2005). In this way, it will be possible for all transactions to be displayed in real time and with minimum delays.


Chen, M., Zhang, D. and Zhou, L 2005, ‘Providing web services to mobile users: the architecture design of an m-service portal’, International Journal of Mobile Communications, 3(1), p.1.

Chen, X., Gu, X. and Xu, J. (2014). The Analysis of Information Architecture in Mobile Web Design. Journal of Networks, 9(10).

Ezumalai, R., Aghila, G. and Rajalakshmi, R. (2010). Design and Architecture for Efficient Load Balancing with Security Using Mobile Agents. IJET, 2(1), pp.57-60.

Suncorpbank.com.au. (2016). Mobile Banking | Ways to Bank | Suncorp Bank. [online] Available at: http://www.suncorpbank.com.au/about/ways-to-bank/mobile-banking [Accessed 13 May 2016].

Suncorpbank.com.au. (2016). Suncorp Bank’s Mobile App — Download Today | Suncorp Bank. [online] Available at: http://www.suncorpbank.com.au/campaign/suncorp-bank-native-mobile-app [Accessed 13 May 2016].