HT-2020-000448 - [2024] EWHC 1185 (TCC)

However, just -- we need to understand that this is a product. Product has its features, right? So, a product, at one hand, there was a very strong emphasis from DBS that we should not customise the project beyond a certain level. So we were trying to keep a balance between the features, out-of-the-box features of the product and the DBS functional requirements that were there.

Item 1: Unusable screens. Sometimes the user would be presented with screens which were not in fact usable. Mr Britton accepted this in principle. Both experts agreed this to be ‘low’ impact.

Items 2 and 3: Not relied upon by DBS, given that the IT experts agreed that this was standard functionality that they would not expect to be customised.

Item.4: Inconsistent back navigation. The back button was necessary to step back on step for some tasks, but for other tasks would return an error message. Mr Britton accepted this in principle. Both experts agreed this to be ‘low’ impact.

Item 5: No personalisation: Users are not able to personalise the way in which information is presented to them so that, for example, they could always see the newest Barring Cases first. Instead, a re-sort would need to be performed each time. Mr Britton agreed, but, in his opinion, Siebel does not offer that kind of functionality. I accept, however, Dr Hunt’s evidence that this functionality was standard, but was not available because of TCS’s customisation of the setting icon. Mr Britton considered that it could potentially be improved but was not “necessarily” an issue but would depend upon whether it was a problem for users in real life. Dr Hunt regarded this as a ‘medium’ impact on the basis that it required additional steps to be taken. DBS submitted there was no real dispute that this could amount to a useability issue: Mr Britton’s reticence relates only to whether it did. DBS is correct that this would depend upon the evidence of the users. The only evidence about whether this was a ‘real’ issue is the inclusion within a spreadsheet of Barring suggested updates of (atline 18) ‘Home Screen sorting’, asking whether ‘My cases/My Activities/Service Requests be sorted by New at the top’. This was ‘Low’ priority. If an issue at all, it is likely, in my view, that this was ‘low’ impact.

Item 6: Too many irrelevant data fields displayed. Dr Hunt considered that, on the “Case Screen”, the user is presented with a large number of irrelevant fields which clutter the screen and force the user to scroll down to see what activity has occurred or is required. Mr Britton considered the issue unclear as he doesn’t know whether there are irrelevant fields or not. DBS submit that barring users are concerned with whether an individual should be considered for barring / entered on to the barred lists, and that the Court can safely conclude that this does not involve the following fields which relate to basic or enhanced checks: update service; purpose of check; references to “applicant”; application type. Dr Hunt’s opinion was, however, essentially based on informal feedback during demonstrations of the system. There is no witness evidence addressing this particular issue, and whilst the inclusion of an option which is irrelevant to a particular user, it is difficult to see how the impact is anything other than, if anything, low.

Item 7. Address field truncated: On the case list screen, the applicant’s address field is truncated to 8 characters and can only be viewed in full using a pop-up. That this is so is not in dispute. Mr Britton made the point that he thought this was OOTB functionality, and that whilst it might be ‘marginally, maybe’ better to see the whole field, it was unclear whether a user was ever likely to need to see the whole address in order to process an application. Mr Britton accepted that whether customisation was appropriate depended upon ‘to what extent this is a real issue’ (Day 19/5). There is no factual evidence that this particular issue was a ‘real issue’ to anyone in particular within DBS: it is not a complaint specifically documented by DBS as a problem at any time. Dr Hunt agreed with Mr Britton that it was ‘low’ impact.

Item 8. Too many irrelevant data fields displayed: This issue is similar to Item 6 but relates to the ;Barring Case Screen;. That screen has multiple irrelevant fields which TCS was specifically informed were for test purposes only including MinScoreAdult, MinScoreAdultID, MinScoreChild, and MinScoreChildID. Mr Britton confirmed in cross-examination that in his opinion this would be an error (Day19/8). Dr Hunt categorises this as ‘medium’ impact, Although no DBS factual witness gives evidence specific to this issue, the Barring suggested updates spreadsheet identifies at row 50 ‘There are too many tabs, many of which never need to be access by teams’. The impact is said to be ‘Accessing required info is difficult and time consuming. System impact of accessing incorrect tabs’. I accept that this would be ‘medium’ impact.

Item 9: Once a barring user scrolls down to view the referral form it is not possible to see details such as the person’s name. That this is so was not in dispute. Mr Britton’s view is that it is unclear if or why it is necessary when completing the information entry it is necessary to continue to see the name at all times. It is not obvious why this should be the case and there is no evidence from any DBS witness explaining why this is a problem. To the extent it is an issue, Dr Hunt regards the impact as low, and I agree.

Item 10. No delete on list data entry. A row can be added quickly by clicking on the “+” icon, but can only be deleted through a keyboard shortcut or the settings icon. Dr Britton accepted a delete button would probably be an improvement but described the impact as ‘negligible’; Dr Hunt accepted that it was ‘low’.

Item11: List data entry fields too small. Both experts agree this was high impact and a significant problem for users. In contrast to other issues, this is one that a DBS witness specifically addressed. Ms Martin, whose evidence was not challenged and which I accept, said:

“18.

In the R1 Barring system we input information into text boxes in the system. There are text boxes for, by way of example, background information and PNC summaries. Often those text boxes are not big enough to contain all of the information which we need to input. For example, the background information section has three separate text boxes for background information in case one is insufficient.

19.

In addition the text boxes are very small perhaps an inch and a half in height and so, even in cases where the boxes are large enough to contain the information you need to input, after inputting more than a few lines of text the preceding text is no longer visible within the box and it is necessary to scroll within the box to check what you have previously drafted. This is particularly an issue within the evidence evaluation tab. The evidence evaluation text boxes are even smaller than those in the background information tab, because the screen appears in a table form and so the boxes are much narrower in length.

20.

In carrying out an assessment it is often necessary to move between tabs to review information to draft our summaries. We might need to go back and amend what we have inputted within text boxes as a result of further reviews and in that case we have to scroll within the box to check and amend what we have previously drafted.

21.

As a result I draft information for data input in a separate Microsoft Word document and then cut and paste that over to the text box. It is simply not possible to efficiently and accurately use the text boxes solely due to the amount of information I need to input and the manner in which it is presented within the system. So far as I am aware, all other Caseworkers also use the same workaround. This workaround would have been unnecessary if, for example, the text boxes had a button which “popped” the box into a bigger screen for data input or review.”

Item 12: List management not appropriate for checklist. The barring information gathering checklists contain reminders, for example to gather relevant previous work history, or disciplinary correspondence. The IG Checklist shows two lists, one with 4 and one with 7 items, although there are in fact 14 items on the second list and there is no indication of this unless the user clicks at the bottom of the screen at which point items 8-14 appear. Dr Britton says, and Dr Hunt did not disagree, that this is part of the OOTB functionality. Dr Hunt considers that this confusion means that it does not provide the checklist functionality, and that the impact is ‘medium’. I accept, however, the evidence of Mr Britton that, given that the users will have quickly learned how many items are on the checklist from their repeated use of the screens, the impact is low. In this regard, I note that there is no evidence from any DBS witness that this issue has, in fact, caused any issues at any time. In the Barring suggested update document referred to above, the only comment relating to ‘IG Checklist’ (row 21) stated, ‘Excess information in this screen. Not very user friendly. Could it be expanded into one long list? Could it be prepopulated with N/A as this is the majority of responses made’. The impact stated ‘*Lots of clicking’ ‘*Takes a long time to complete’. The thrust of the complaint (a) does not relate to not showing all 14 items in the second list, rather that the content of the list contained things that required checking which were in fact ‘N/A’. There is no suggestion, however, that including the content (presumably provided by DBS and/or existing DBS process) was a breach.

Item 13: Poorly designed popup forms. Both experts agree that the one of the two issues relating to forms, where there are irrelevant entries on drop-down boxes, is of medium impact (because users encounter the issue in more than one drop-down box) and the other is low. No DBS factual witness gives evidence specific to this issue, or whether or how the inclusion of unnecessary/irrelevant choices within the drop down box adds to the time it takes to carry out their work.

Item 14: Invalid drop down values. Both experts agree this issue was a defect of ‘medium’ impact individually, but again there is no evidence of whether or how this has caused any problems in reality.

Item 15: Drop down values change. The experts could not replicate this, but Mr Britton describes it as a common issue. They agree the impact as low.

Items 16 and 17: Not relied upon by DBS.

Item 18: Error messages are not helpful in that they do not explain the error, which does not assist the user to remedy the problem. The experts agree that this is a ‘low impact’ issue.