diff --git a/app/images/processing/complete-id-cv-check/check-details.png b/app/images/processing/complete-id-cv-check/check-details.png
new file mode 100644
index 0000000..7a652d8
Binary files /dev/null and b/app/images/processing/complete-id-cv-check/check-details.png differ
diff --git a/app/images/processing/complete-id-cv-check/edit-details.png b/app/images/processing/complete-id-cv-check/edit-details.png
new file mode 100644
index 0000000..e6e2d20
Binary files /dev/null and b/app/images/processing/complete-id-cv-check/edit-details.png differ
diff --git a/app/images/processing/complete-id-cv-check/invite-sent.png b/app/images/processing/complete-id-cv-check/invite-sent.png
new file mode 100644
index 0000000..1fafc8e
Binary files /dev/null and b/app/images/processing/complete-id-cv-check/invite-sent.png differ
diff --git a/app/images/processing/complete-id-cv-check/no-sro.png b/app/images/processing/complete-id-cv-check/no-sro.png
new file mode 100644
index 0000000..aae352d
Binary files /dev/null and b/app/images/processing/complete-id-cv-check/no-sro.png differ
diff --git a/app/posts/processing/2024-11-25-find-a-organisation.md b/app/posts/processing/2024-11-25-find-a-organisation.md
index 5efeb6e..e2ede4c 100644
--- a/app/posts/processing/2024-11-25-find-a-organisation.md
+++ b/app/posts/processing/2024-11-25-find-a-organisation.md
@@ -131,8 +131,7 @@ We evolved to remove multiple things to search by and only test workplace id as
#### Outcomes to consider for further design development:
-* Email search may give multiple results in the future as multiple organisations could have the same SRO. If this something to use now if a risk to change in the future to being a indirect search with results, and would have to alter how we handle?
-* Having seperate fields for each find a org input is less of a issue for tech as no partial matches, but means it is harder to give specific errors.
+* If Email search is considered again in the future, it may give multiple results in the future as multiple organisations could have the same SRO. Something to bear in mind that it may potentially change from being a direct search.
## How we tested our ideas and what we found
- We tested the org view with CCS agents and processors week commencing 5th January 2025.
@@ -144,6 +143,6 @@ We evolved to remove multiple things to search by and only test workplace id as
## What we will do next
- Holding a post playback actions session with the wider delivery team to decide what actions to progress with.
-
+- Next updates will be done in version 7 of the prototype.
diff --git a/app/posts/processing/2024-11-26-complete-id-cv-check.md b/app/posts/processing/2024-11-26-complete-id-cv-check.md
index d323578..40c5f00 100644
--- a/app/posts/processing/2024-11-26-complete-id-cv-check.md
+++ b/app/posts/processing/2024-11-26-complete-id-cv-check.md
@@ -1,5 +1,5 @@
---
-title: Complete a ID/CV check WIP
+title: Complete a ID/CV check
description: Once a organisation has been found, BSA staff need to be able to verify who they are speaking to before they are they able to process a query
author:
name: Hannah Williams (Interaction designer)
@@ -58,16 +58,15 @@ Held a second ideation session with wider delivery team on 26th November to expl
Below the requirements have been broken down into the information that needs to be accessible to complete ID/CV checks.
-ID/CV check requirements:
-* Check a claim reference number
-* Check organisation name
-* Check first line of address
-* Check postcode of org
+#### Iterated ID/CV check requirements:
+* Caller's full name - check against SRO/submitters for org
+* Email address
+* Workplace ID - if they caller doesn't have the correct ID, they would have to call back
+* Organisation's address and postcode
+* Claim Reference - if the query is in relation to a claim
If don’t possess one of these pieces then need to go through to the secondary check, where one of these need’s to be confirmed (this list is not exhaustive and potentially other alternatives):
-* Check submitter’s full name
-* Check submitter’s email address
* Check learner’s full name
* Check name of training course
@@ -76,8 +75,9 @@ Other information that needs to be accessible based off ticket:
* To check a claim reference does that mean need to see a list of all the claims/have a find claim function?
* Bank details are part of ticket requirement
+#### Designing with flexibility built into the concept - organisation view
-In design need to consider how to display the information in a way that can be built up iteratively over time with new functionality being added. It needed to be usable on its own, but with a way to bring in other features that won’t affect usability. e.g. processing a claim issues we currently have of throwing everything in and is cognitively overwhelming.
+In the design we needed to consider how to display the information in a way that can be built up iteratively over time with new functionality being added. It needed to be usable on its own, but with a way to bring in other features that won’t affect usability. e.g. processing a claim issues we currently have of throwing everything in and is cognitively overwhelming.
>**We believe that** having the information needed for ID/CV can be broken down into the header and different tabs within the org view
>**Will be a useful feature for** BSA staff
@@ -107,16 +107,21 @@ In design need to consider how to display the information in a way that can be b
-This work was being done alongside process a claim reworking. Thought of to bring the two journeys to end up in the same place made sense as the claims sit under the whole organisation.
+This work was being done alongside the process a claim journey rework. Having the two journeys end up in the same overarching organisation view made sense as the claims sit under the whole organisation in the mental model. But they are different intentions of tasks so the routes into the service on the signposting page would stay seperate.
>**We believe that** keeping the journey's seperate in the signposting page as to what they want to do
>**Will be a useful feature for** BSA staff
>**As it will** suit the different intentions they are coming with of process a claim, find a org, register a org, but still the journey's are cohesive as end up in same centralised org view with all the functionality available to them.
-The process a claim journey still needs access to wider org view to help processors. Something to be tested as to the understanding of these two options.
+The process a claim journey still needs access to wider org view to help processors. Something to be tested as to the understanding of these two options. Depending on the route into the service of process a claim and find a org, we decided it would be helpful to land the user into specific places, also using the options like a quick link into where want to go in the service to complete their task.
+
+>**We believe that** depending on what they search by lands them in a different place in the org view
+>**Will be a useful feature for** bsa staff
+>**As it will** follow their intentions e.g searching by claim ref will land them on that claim.
+
-#### Perform ID/CV checks
+### Perform ID/CV checks
>**We believe that** having organisation information in a header that’s always there
>**Will be a useful feature for** BSA staff
@@ -176,22 +181,17 @@ Idea 1
Idea 2
>**We believe that** displaying all the claims
>**Will be a useful feature for** BSA staff
->**As it will** give more scope in case they fail that check and have to proceed onto looking for a learner in which case still have access to claims. Needs to have table sorting?
-
->**We believe that** depending on what they search by lands them in a different place in the org view
->**Will be a useful feature for** bsa staff
->**As it will** follow their intentions e.g searching by claim ref will land them on that claim.
-
+>**As it will** give more scope in case they fail that check and have to proceed onto looking for a learner in which case still have access to claims. Does it need to have table sorting to be able to find a specific claim?
Decision:
It was decided for the scope of this ticket the find a claim search without the claims table might be able to answer the user need to complete ID/CV and this is what we will take into testing to validate.
+
#### Users tab
-
>**We believe that** putting users tab first
>**Will be a useful feature for** BSA staff
>**As** since only workplace id can be searched, it makes sense to land there, orientate themselves with who speaking to and then progress with the query.
@@ -204,13 +204,54 @@ It was decided for the scope of this ticket the find a claim search without the
>**Will be a useful feature for** BSA staff
>**As** they will understand if the user has successfully registered or is still awaiting acceptance of the invitation.
+
+#### States of invited and not registered SRO
+
+We needed a design for the scenario of what if a organisation was searched that had a SRO that had been invited but not yet registered.
+- We decided they would still get into the organisation view with content added to say the SRO needs to accept the invite in a warning banner within the org header.
+- We would then utilise the users tab and the status' of users, with the SRO being labeled invited. We decided this would also be a good place to bring in the functionality of changing the SRO invited, taking it from the register a org journey.
+- Thought of hiding the claims tab as there would never be any content in here, but that would mean only one tab, and we would have to make a design to have a single tab view which is more tech work also. So kept claims in.
+
+
+
+
+
+ No SRO view
+
+
+
+
+
+ "resend invite"
+
+
+
+
+
+
+
+
+ Editing the inviting SRO's details, same views as in the register a org journey
+
+
+
+
+
+ Confirming details before sending a new invite
+
+
+
+
## How we tested our ideas and what we found
- We tested the org view with CCS agents and processors week commencing 5th January 2025.
- The main themes from the playback:
- - They were able to conduct ID/CV with the organisation view.
+ - They were able to conduct ID/CV within the organisation view.
- There was a need to see all claims for a organisation, the assumption that search for a claim would meet the user need was disproven
- They wanted to maintain a view of the selected claim as they navigated in and out of tabs
- Current processes may not work for ASC - lack of IVR and not capturing Workplace ID early enough in the journey
+ - There was confusion on the differences between the routes into the service
+ - Confusion on whether they were in the service at a claim level or at the organisation level. Some content review will be needed to see if can help the user better orientate themselves.
## What we will do next
-- Holding a post playback actions session with the wider delivery team to decide what actions to progress with.
\ No newline at end of file
+- Holding a post playback actions session with the wider delivery team to decide what actions to progress with.
+- Next updates will be done in version 7 of the prototype.
\ No newline at end of file
diff --git a/app/posts/processing/2025-01-16-org-notes.md b/app/posts/processing/2025-01-16-org-notes.md
index a87bbf7..f93429b 100644
--- a/app/posts/processing/2025-01-16-org-notes.md
+++ b/app/posts/processing/2025-01-16-org-notes.md
@@ -48,7 +48,7 @@ An early Hypothesis
-The flexibility and scalability we have built into the view when designing the organisation view to be able to be iterated and built up meant it was a easy decision to add the organisation notes to a new tab.The notes design is one we had already experimented with when adding notes to a claim. We believed that this design
+The flexibility and scalability we have built into the view when designing the organisation view to be able to be iterated and built up meant it was a easy decision to add the organisation notes to a new tab.The notes design is one we had already experimented with when adding notes to a claim, and we believed fit the task.
>**We believe that** the information including the note, author, job role, date and time
>**Will be a useful feature for** BSA to staff to see
@@ -64,7 +64,8 @@ The flexibility and scalability we have built into the view when designing the o
- We tested the org view with CCS agents and processors week commencing 5th January 2025.
- The main themes from the playback:
- The uncertainties around the notes - is this for the claim or the organisation? Will the organisation see this note? Are these notes from the organisation?
- - Can't access the necessary information on the seperate add note view when writing note to fill in with specific info about a claim or the organisation
+ - Can't access the necessary information on the seperate add note view when writing note to fill in with specific info about a claim or the organisation, so they would potentially still make their own notes offline, or open in a new browser.
## What we will do next
-- Holding a post playback actions session with the wider delivery team to decide what actions to progress with.
+- We held a post playback actions session with the wider delivery team to decide what actions to progress with.
+- We conducted further testing with some processors in a workshop and it was decided the notes in their current design, without further iteration, would not be any better than the processes they already have now. They have been pushed down the roadmap priorities until further time can be spent to iterate the designs.
diff --git a/app/posts/processing/2025-02-05-org-search-iteration.md b/app/posts/processing/2025-02-05-org-search-iteration.md
new file mode 100644
index 0000000..3ee2ab1
--- /dev/null
+++ b/app/posts/processing/2025-02-05-org-search-iteration.md
@@ -0,0 +1,118 @@
+---
+title: Expanding search terms to find a organisation WIP
+description: Work to iterate the routes into the organisation view and the search terms used to cover all the scenarios.
+author:
+ name: Hannah Williams (Interaction designer)
+ url: 'mailto:hi.hannah.williams@nhsbsa.nhs.uk'
+date: 2025-02-05
+tags:
+ - private-beta
+ - processing-version-7
+ - processing-find-an-org
+aside:
+ title: Processing Prototypes
+ content: |
+ [View processing v7 prototype](https://adult-social-care-7fe9bafd955a.herokuapp.com/processing/prototypes/design/v7/)
+ Password: bsaasc123
+
+ Claim reference's to test:
+
+ 100
+ Submitted: Z1Z-F1J6-3XF7-A
+ Approved: Z8S-F1J6-4GH7-A
+ Rejected: K93-SK68-3S2K-A
+
+ 60
+ Submitted: WR5-R2P4-DSL4-B
+ Approved: R4Y-NL7G-D967-B
+ Rejected: NLE-BMDT-68ZI-B
+
+ 40
+ Submitted: R7J-NC3G-D967-C
+ Approved: R4Y-NL7G-D967-C
+ Rejected: Y6M-5DYB-TRCL-A
+---
+
+## Why we did this work
+We tested the first iteration of the find and view a organisation journey with processors and css agents in w/c 5th February and there were a number of areas highlighted as needing further development. Post playback and actions meeting, these were the updates agreed upon to make:
+
+- Routes in to the service were confusing to the user about the differences between, unclear which to use.
+- Search terms
+ - It was found their were a number of scenarios that searching for a organisation with workplace ID wouldn't cover. For example...
+ - Verbal communication of a workplace ID over the phone led to mistakes in typing it in.
+
+## What our ideas were
+
+#### Search terms
+Speaking to research, the options for search terms were cross examined against the scenarios they would cover for processors and ccs agents. These scenarios include: mail referrals etc. TO ADD
+
+When deciding how to expand what the staff could search with, we wanted to balance covering the missing scenarios with not changing too much as we were only going to be able to sense check the changes with staff during a informal 2 hour workshop rather than do another complete usability test, and also had to be minimal in tech effort to make the changes.
+
+>**We believe that** email, claim ref and id
+>**Will be a useful feature for** staff to search with
+>**As it will** them to cover the scenarios of.... TO ADD
+
+There was a concern about the ID/CV process and the risk that if we opened up the search terms it wouldn't be enforcing workplace ID to be required first. Product had a discussion with ops and they agreed to take on the risks surrounding ID/CV process.
+
+#### Routes in
+
+Working with content, it was considered combining the two routes in into one. We believe that this would require too much content on the search page to explain all the functionality available in the org view and would be conflating the two intentions of the users.
+
+>**We believe that** keeping the two routes seperate
+>**Will be a useful feature for** BSA staff
+>**As it will** keep intentions seperate of going directly to a specific claim, and doing something more general with the organisation information.
+
+Content included changing the "Process a claim" wording to "Find a claim", and within the org view, content was reviewed to make it clearer the user is within org level view through both routes.
+
+>**We believe that** keeping the ability to search with claim id within the find a claim route and adding ability to find a org with email and workplace id
+>**Will be a useful feature for** BSA staff
+>**As it will** not mean that you can search claim id in two places, which will help with the user's confusion about the differences between the options.
+
+>**We believe that** keeping both routes allowing you to access all the same functionality e.g. process a claim
+>**Will be a useful feature for** processors
+>**As it would** be confusing to take away functionality because they’ve come in through a particular route and they would have to go out and in again to access. Still in both routes they have access to all the org information.
+
+
+#### Search input design
+* The need to have seperate input fields for each find a organisation type of search term was a tech consideration as if they are all entered in the same box it's harder to give specific error messages as would involving assuming what the value is of that's been entered. From tech perspective, it was decided this is less of a issue in this search case as there will be no partial matches, just returning a direct result search, and from a content perspective because there are max two search terms and email is a well known format, we can have a error that still gives helpful information.
+
+>**We believe that** having the terms entered in one input field
+>**Will be a useful feature for** staff
+>**As it will** keep the search page simple
+
+
+#### Email
+To expand the search to allow to search by email, there are multiple status' that could be associated with these users'.
+
+>**We believe that** searching by active, invited, inactive SRO’s and displaying all these users in the Contact's SRO's section
+>**Will be a useful feature for** staff
+>**As it will** as want to be able to see if should carry on speaking to the person on the phone and understand full context.
+
+>**We believe that** searching by active, invited submitters and only displaying these users and not the inactive one's in the Contact's submitter's section
+>**Will be a useful feature for** staff
+>**As it will** be less important to see deleted submitter's.
+
+We won't capture the dates that each submitter is active, which also means then we can't display these user's in order of most recent. Decided to show in order of active/invited and then inactive, then within each status order them alphabetically which be helpful to provide some order.
+
+
+#### Job roles
+Two job roles in service of processor and CCS agent.
+For a CCS agent they won't be able to Process a claim or register a organisation. These are then options that are hidden on the signposting page. Since they will then only have one option we will istead naviagte them on login to the find a organisation search page. Processing of a claim functionality within the not yet processed claim view will also be hidden.
+
+>**We believe that** only being able to search by email, workplace id
+>**Will be a useful feature for** ccs agents
+>**As it will** them to cover the scenarios of... TO ADD
+
+#### Content updates
+
+- Tab now called Claims
+- Tab now called Contacts
+- Tab now called Organisation notes
+- Add in reference to process a claim, thats enough to still make clear thats something they can do through these routes
+
+## How we tested our ideas and what we found
+
+- Sense checked the updates with BSA staff in a workshop, rather than a full usability test. They agreed the routes in were clearer, and the added ability to search with email will help.
+
+## What we will do next
+- Gone into development.
\ No newline at end of file
diff --git a/app/posts/processing/2025-02-10-claims-iteration.md b/app/posts/processing/2025-02-10-claims-iteration.md
new file mode 100644
index 0000000..c9aa6ee
--- /dev/null
+++ b/app/posts/processing/2025-02-10-claims-iteration.md
@@ -0,0 +1,85 @@
+---
+title: Claims table and claim interaction WIP
+description: The need to have all the claims accessible came from research
+author:
+ name: Hannah Williams (Interaction designer)
+ url: 'mailto:hi.hannah.williams@nhsbsa.nhs.uk'
+date: 2025-02-10
+tags:
+ - private-beta
+ - processing-version-7
+ - processing-view-org
+aside:
+ title: Processing Prototypes
+ content: |
+ [View processing v7 prototype](https://adult-social-care-7fe9bafd955a.herokuapp.com/processing/prototypes/design/v7/)
+ Password: bsaasc123
+
+ Claim reference's to test:
+
+ 100
+ Submitted: Z1Z-F1J6-3XF7-A
+ Approved: Z8S-F1J6-4GH7-A
+ Rejected: K93-SK68-3S2K-A
+
+ 60
+ Submitted: WR5-R2P4-DSL4-B
+ Approved: R4Y-NL7G-D967-B
+ Rejected: NLE-BMDT-68ZI-B
+
+ 40
+ Submitted: R7J-NC3G-D967-C
+ Approved: R4Y-NL7G-D967-C
+ Rejected: Y6M-5DYB-TRCL-A
+---
+
+## Why we did this work
+We first tested the org view with processors and css agents in February and we disproved the hypothesis that having the find a claim search to find a specific claim would solve the user need. The actual user expectation was they would want to see all the claims so they could understand what was happening with the organisation as a whole.
+
+## What our ideas were
+
+### Add in claims table
+
+UR Insight:
+- processors would be less likely to be looking at not yet processed claims in the table - as they'd be more likely to always search for a claim to process them based on the ID provided by OM...
+- the examples we have for browsing the table would relate more to processed claims - either via date for QAs to assess the most recent ones or via course title (but I think that could be an unexpected column to be ordered by).
+
+>**We believe that** having all the status's of claims in one table
+>**Will be a useful feature for** BSA staff
+>**As it will** allow them to compare between all claims in one view
+
+>**We believe that** ordering the claims by not yet processed, rejected then approved
+>**Will be a useful feature for** BSA staff
+>**As it will** allow the not yet processed claims to not get buried under many processed claims, even though they might not be the claims the user is most likely looking for.
+
+### Change submitted date column to processed date
+
+Second round of research said to change submitted dates column to processed dates as this would be more helpful to scan to find a specific claim, happy to have a line where no date present.
+Sorting has been pushed down the roadmap to implement on the tables but the claims table is able to be paginated as that's something tech have now implemented in the service.
+
+>**We believe that** ordering each status claims by then submitted date for the claims not yet processed, and most recent rejected/approved
+>**Will be a useful feature for** BSA staff
+>**As it will** show the more recent claims on the first page of paginated table, which will be more likely to be the claims wanted to be seen.
+
+### Claim tab interation
+
+In the UR the user's stated they would expect the last opened claim to stay opened when clicking between tabs.
+
+>**We believe that** keeping the opened claim open when clicking between tabs
+>**Will be a useful feature for** BSA staff
+>**As it will** mean they don't have to keep researching for it when orientating themselves with other information in the org view.
+
+>**We believe that** if the processor has begun processing the claim, that maintaining the information they have typed in e.g. rejection reasons
+>**Will be a useful feature for** BSA staff
+>**As it will** they can click between tabs to find other information they need to help in the claim processing.
+
+It was agreed with tech that if the user clicked into another claim then this is when the session would clear.
+
+
+#### Job roles - CCS Agents
+With the introduction of job roles into the service, the functionality to process a claim is hidden for CCS agents. For ease of giving tech more work, we have just hidden the processing radio buttons on the screen, this means for the CCS agents the information of a claim is all squished to the left side. Agreed that if tech have time they will make it two thirds width.
+
+## What we will do next
+
+To bear in mind for future iterations:
+- We know from research that the claims table will be most used by trying to scan between how claims for similar training was processed so not yet processed claims at the top might not be most useful. Because we don't have column sort yet this is something we've had to accept in the design for now, but something that can be revisted in the future.
\ No newline at end of file
+ 
+ 
+ 
+