How long is 'healthy' response time - response time standards?
One of the key aspects of Performance is the response times of interactions with the system. Typically talked-worried-designed is the end user response time or the online user experience. Throughout the stages of SDLC this aspect is more debated and finally accepted-convinced what the test results demonstrate. What the business wants is 'faster' responses - in essence 'fast' implying to the satisfaction of end users. The quantification of 'fast' is typically 'too fast' during the requirements phase, so can there be any way of arriving at rational expectations, are there any response time standards ?
(i) Standards are subjective
Note that there are no 'specified standards' when it comes to response times for user facing transactions. The traditional figures of 3 secs or maximum 8 secs are 'legacy' figures, moreover advances in technology can yield-facilitate responses at the level of milli secs. What matters most in determining the standards for a given system is the 'user perception' about the service being offered by the system. Rather than looking 'outside' for response time thresholds, its important to put yourself in the place of the end user and arrive at the numbers that suit the given enterprise-application.
Business - designers - architects need to take into account the factors that affect the user perception about the service being offered. Arrive at rational figures based on the variety of transactions-responses associated with the system (during planning & requirements phase). Cascade the end to end responses across the components within the system. Evaluate - Monitor - calibrate the responses throughout the coding to testing phases. Validate the 'final' response times to be mutually satisfactory.
(ii) Response time bands
Based on the measurements of 'attention span' - following are some basic guidelines to take into consideration:
Sub second response: (less than 0.5 sec on an average): These latencies are typically not recorded as 'taking time' by end users -its like 'done immediately' from the perspective of human. Typically the case when users want to proceed quickly towards the next action - do not expect-want to wait for the outcome of the 'previous' action being performed. For example - users 'operating' fields-entities in the UI.
Response in seconds: (less than 2 sec on an average): These times make the users notice the delay - users expect that the system is 'working' on the inputs provided and has returned response fairly soon without having to unduly wait. Users do not feel that the system is sluggish, they do not lose the sense of 'smooth flow' in their journey of completing the task. For example - user operations that require providing credentials or navigation to 'next' step post current actions.
Extended Response: (more than 5 sec on an average): This is typically a limit for users to keep their attention on the current task. Anything slower than 8 secs must have some way of bringing out to the end user "percent-done" indication and a clear way-facility to halt-interrupt the operation at whatever stage it has completed. Under these response times, users should not be expected to 'remain' on the same page-task, rather they 're-orient to the previous task' when they return to the response after doing some 'other task'. Any delays longer than 10 sec result in natural break in the user's current work-flow.
(iii) Choose what suits best for you
Based on the response time bands - attention spans as above and the service being offered, choose the SLAs that work best for you. The factors for selection need to be (i) Service-business being done : Banking, Telecom, Health, Call centre etc (ii) Distance of end user - direct user interaction versus users reaching the service through via-media; multiple users consuming same service, system inner complexity - need to get responses from 'outside' systems (iii) Factors affecting attention span - age groups of service consumers, emotions-temperament of users, professions-occupations of users, possible user attrition reasons, different time phased ways of accomplishing the same task (iv) Real time criticalness of transactions under consideration (v) Current market trends and 'competitors' offering 'similar' services (vi) Balance between architecture - technology - business
Having irrational targets and failing to meet them or settling for slower targets leads to 'internal' dissatisfaction about your own system. Balancing the factors and arriving at prudent targets helps better for IT as well as business. Design the responses keeping in mind how the end user will utilize them - make right choices for suitable transactions keeping in mind that the users never accomplish 'all' the tasks in a single flow-span !