update for org view things

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.
 
 

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
   </div>
 </div>
 
-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,17 +181,15 @@ 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
 
 ![Screenshot of the users tab showing SRO and users details ](users-tab.png "Screenshot of the users tab showing SRO and users details")
@@ -207,10 +210,13 @@ It was decided for the scope of this ticket the find a claim search without the
 ## 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.
+- 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.

app/posts/processing/2025-01-16-org-notes.md

@@ -48,7 +48,7 @@ An early Hypothesis
 
 ![Screenshot of the new organisation notes tab ](notes-tab.png "Screenshot of the new organisation notes tab")
 
-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.

app/posts/processing/2025-02-05-org-view-iteration.md

@@ -0,0 +1,60 @@
+---
+title: Expanding search terms to find a organisation
+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:[email protected]'
+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 first tested the org view with processors and css agents in February and 
+
+It was found
+- missing scenarios as workplace ID wasn't always to hand
+- verbal communication of these values led to mistakes 
+- routes in were confusing, something posed to content
+
+## What our ideas were
+
+Speaking to research, we cross examined search terms for the scenarios they would cover for processors and ccs agents. 
+
+* The need to have seperate input fields for each find a organisation type of search term was a consideration as if in the same box its harder to give specific error messages as would involving assuming what the value is of that's been entered. From tech, 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 we can 
+
+>**We believe that** 
+>**Will be a useful feature for** 
+>**As it will** 
+
+![Screenshot of the new organisation notes tab ](notes-tab.png "Screenshot of the new organisation notes tab")
+
+
+## How we tested our ideas and what we found
+
+
+## What we will do next