org view

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,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
 
 ![Screenshot of the users tab showing SRO and users details ](users-tab.png "Screenshot of the users tab showing SRO and users details")
 
-
 >**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.
+
+<div style="display: flex; flex-wrap: wrap; gap: 1rem;">
+  <div style="flex: 1; max-width: 48%;">
+  <figure>
+    <img src="no-sro.png" alt="text" style="width: 100%; height: auto;">
+    <figcaption>No SRO view</figcaption>
+  </figure>
+  </div>
+  <div style="flex: 1; max-width: 48%;">
+  <figure>
+    <img src="invite-sent.png" alt="text" style="width: 100%; height: auto;">
+    <figcaption>"resend invite"</figcaption>
+  </figure>
+  </div>
+</div>
+
+<div style="display: flex; flex-wrap: wrap; gap: 1rem;">
+  <div style="flex: 1; max-width: 48%;">
+  <figure>
+    <img src="edit-details.png" alt="text" style="width: 100%; height: auto;">
+    <figcaption>Editing the inviting SRO's details, same views as in the register a org journey</figcaption>
+  </figure>
+  </div>
+  <div style="flex: 1; max-width: 48%;">
+  <figure>
+    <img src="check-details.png" alt="text" style="width: 100%; height: auto;">
+    <figcaption>Confirming details before sending a new invite</figcaption>
+  </figure>
+  </div>
+</div>
+
 ## 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-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:[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 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.