added table of contents to all relevant claims.

app/posts/processing/2024-10-18-rejection-notes copy.md → app/posts/archive/__2024-10-18-rejection-notes copy.md

@@ -1,3 +1,5 @@
+[Archived]
+
 ---
 title: Improving rejection notes
 description: Helping processors provide useful information to submitters when a claim is rejected.

app/posts/claims/2024-03-05-starting-beta.md

@@ -14,6 +14,13 @@ aside:
     Password: bsaasc123
 ---
 
+Contents
+--- [Recording design decisions in alpha](#recording-design-decisions-in-alpha)
+--- [Challenges with the Confluence approach](#challenges-with-the-confluence-approach)
+--- [Transition to the x-govuk design history tool](#transition-to-the-x-govuk-design-history-tool)
+--- [Alignment with NHS BSA UCD logs](#alignment-with-nhs-bsa-ucd-logs)
+--- [Next steps](#next-steps)
+
 ## Recording design decisions in alpha
 During alpha, we recorded design decisions in Confluence using a simple table format. This method helped us:
 - Keep information organized.

app/posts/claims/2024-03-14-cost-per-learner-submitter.md

@@ -15,6 +15,12 @@ aside:
     Password: ascbsa123
 ---
 
+Contents
+--- [Why we did this work](#why-we-did-this-work)
+--- [What our ideas were](#what-our-ideas-were)
+--- [How we tested our ideas and what we found](#how-we-tested-our-ideas-and-what-we-found)
+--- [What we will do next](#what-we-will-do-next)
+
 ## Why we did this work
 
 For care skills claims there is a maximum reimbursement amount for every training course or qualification. This is set by DHSC as part of the [scheme guidance](https://www.gov.uk/government/publications/adult-social-care-learning-and-development-support-scheme/eligible-training-courses-and-qualifications).

app/posts/claims/2024-03-23-scaling-back-mvp.md → app/posts/claims/2024-03-23-scaling-back-mvp-claims.md

@@ -1,5 +1,5 @@
 ---
-title: Scaling back MVP
+title: Scaling back MVP (Claims)
 description: With a tight delivery deadline fast approaching and an increasing amount of technical unknowns the decision was made by the product owner to scale back the MVP at the start of Beta.
 author:
   name: Mark Portnell (Interaction designer)
@@ -21,6 +21,20 @@ aside:
     Password: ascbsa123
 ---
 
+Contents
+--- [Introduction](#introduction)
+--- [Using Azure B2C for authentication and account creation](#using-azure-b2c-for-authentication-and-account-creation)
+--- [Remove eligible training list from service for MVP](#remove-eligible-training-list-from-service-for-mvp)
+--- [Remove paid status from MVP](#remove-paid-status-from-mvp)
+--- [Remove searching/filtering for MVP](#remove-searching/filtering-for-mvp)
+--- [Remove pagination for MVP](#remove-pagination-for-mvp)
+--- [Remove multiple learners per claim for MVP](#remove-multiple-learners-per-claim-for-mvp)
+--- [Remove ability to view uploaded evidence for MVP](#remove-ability-to-view-uploaded-evidence-for-mvp)
+--- [Remove training details for MVP](#remove-training-details-for-mvp)
+--- [Remove claim history information for MVP](#remove-claim-history-information-for-mvp)
+
+## Introduction
+
 With an aggressive delivery deadline fast approaching and an increasing amount of technical unknowns the decision was made by the product owner to scale back the MVP at the start of Beta. Across a couple of workshops attended by the entire product team a series of key decisions were made to cut out or scale back certain features for MVP. These product decisions were all logged in our project decision log held in Jira along with any associated risks and mitigations. 
 
 We finished Alpha with v7 of the prototype, this version was not tested with users before these decisions were made and therefore changes were made in v8 of the prototype for future testing. As these decisions also impact design and explain how we moved from v7 to v8 and some of the changes are made.

app/posts/claims/2024-03-26-manage-claims.md

@@ -16,6 +16,12 @@ aside:
     Password: bsaasc123
 ---
 
+Contents
+--- [Why we did this work](#why-we-did-this-work)
+--- [What our ideas were](#what-our-ideas-were)
+--- [How we tested our ideas and what we found](#how-we-tested-our-ideas-and-what-we-found)
+--- [What we will do next](#what-we-will-do-next)
+
 ## Why we did this work
 
 At the end of alpha, the design for managing claims consisted of a single page with a tabs component. Each tab represented a specific state a claim could be in (e.g., approved or submitted). Within each tab was a table displaying claims in that corresponding state.

app/posts/claims/2024-03-27-removing-cpd.md

@@ -14,6 +14,11 @@ aside:
     [View claims v8 prototype](https://adult-social-care-7fe9bafd955a.herokuapp.com/claims/prototypes/design/v8/) 
     Password: bsaasc123
 ---
+Contents
+--- [Why we did this work](#why-we-did-this-work)
+--- [What our ideas were](#what-our-ideas-were)
+--- [How we tested our ideas and what we found](#how-we-tested-our-ideas-and-what-we-found)
+--- [What we will do next](#what-we-will-do-next)
 
 ## Why we did this work
 

app/posts/claims/2024-03-28-claims-tables.md

@@ -16,6 +16,12 @@ aside:
     Password: bsaasc123
 ---
 
+Contents
+--- [Why we did this work](#why-we-did-this-work)
+--- [What our ideas were](#what-our-ideas-were)
+--- [How we tested our ideas and what we found](#how-we-tested-our-ideas-and-what-we-found)
+--- [What we will do next](#what-we-will-do-next)
+
 ## Why we did this work
 
 We knew that in the near future we would need designs to accommodate 60/40 claims. As part of our exploration of 60/40 claims, we considered the possibility of having three different types of claims in the service for care skills funding: 100%, 60%, and 40% claims. We were also exploring a design hypothesis for how users might manage revalidation funding claims.

app/posts/claims/2024-04-06-account-creation-mvp.md

@@ -16,6 +16,12 @@ aside:
     Password: bsaasc123
 ---
 
+Contents
+--- [Why we did this work](#why-we-did-this-work)
+--- [What our ideas were](#what-our-ideas-were)
+--- [How we tested our ideas and what we found](#how-we-tested-our-ideas-and-what-we-found)
+--- [What we will do next](#what-we-will-do-next)
+
 ## Why we did this work
 
 To use the service, organisations must first be onboarded, and users within those organisations will need accounts. Onboarding ensures that the organisations are legitimate, and the user authentication process helps reduce fraud and maintain a secure service.

app/posts/claims/2024-04-08-time-sensitive.md

@@ -16,6 +16,12 @@ aside:
     Password: bsaasc123
 ---
 
+Contents
+--- [Why we did this work](#why-we-did-this-work)
+--- [What our ideas were](#what-our-ideas-were)
+--- [How we tested our ideas and what we found](#how-we-tested-our-ideas-and-what-we-found)
+--- [What we will do next](#what-we-will-do-next)
+
 ## Why we did this work
 
 Two time-sensitive policy requirements were introduced:

app/posts/claims/2024-04-15-claim-duplication.md

@@ -16,6 +16,12 @@ aside:
     Password: bsaasc123
 ---
 
+Contents
+--- [Why we did this work](#why-we-did-this-work)
+--- [What our ideas were](#what-our-ideas-were)
+--- [How we tested our ideas and what we found](#how-we-tested-our-ideas-and-what-we-found)
+--- [What we will do next](#what-we-will-do-next)
+
 ## Why we did this work
 
 The scheme rules state that a claim will only be paid out once per training and learner combination. This means that organisations can't claim reimbursement for training that a learner takes more than once. We need to enforce this rule within our service.

app/posts/claims/2024-04-15-learner-duplication.md

@@ -16,6 +16,12 @@ aside:
     Password: bsaasc123
 ---
 
+Contents
+--- [Why we did this work](#why-we-did-this-work)
+--- [What our ideas were](#what-our-ideas-were)
+--- [How we tested our ideas and what we found](#how-we-tested-our-ideas-and-what-we-found)
+--- [What we will do next](#what-we-will-do-next)
+
 ## Why we did this work
 Learners in our service are unique entities identified by their National Insurance (NI) number. Whenever a learner is added to the service for use in a claim, that learner is saved and can be used in future claims. As a result, if a user adds a new learner with an NI number that matches a learner already in the system, we need a mechanism to address this and prevent duplicate learners from being added.
 

app/posts/claims/2024-04-16-multiple-evidence-payment.md

@@ -16,6 +16,12 @@ aside:
     Password: bsaasc123
 ---
 
+Contents
+--- [Why we did this work](#why-we-did-this-work)
+--- [What our ideas were](#what-our-ideas-were)
+--- [How we tested our ideas and what we found](#how-we-tested-our-ideas-and-what-we-found)
+--- [What we will do next](#what-we-will-do-next)
+
 ## Why we did this work
 
 During routine reading of project material, our content designer had a realization:

app/posts/claims/2024-04-21-claim-submission-error.md

@@ -16,6 +16,12 @@ aside:
     Password: bsaasc123
 ---
 
+Contents
+--- [Why we did this work](#why-we-did-this-work)
+--- [What our ideas were](#what-our-ideas-were)
+--- [How we tested our ideas and what we found](#how-we-tested-our-ideas-and-what-we-found)
+--- [What we will do next](#what-we-will-do-next)
+
 ## Why we did this work
 The claim scaffold screen features a somewhat unique use of the summary list component. This screen allows users to add the relevant information to each section in a flexible way, at times suitable for the user. Our design decision log from alpha covers the rationale behind using summary lists in this way, rather than other patterns like the task list.
 

app/posts/claims/2024-04-25-select-training.md

@@ -16,6 +16,12 @@ aside:
     Password: bsaasc123
 ---
 
+Contents
+--- [Why we did this work](#why-we-did-this-work)
+--- [What our ideas were](#what-our-ideas-were)
+--- [How we tested our ideas and what we found](#how-we-tested-our-ideas-and-what-we-found)
+--- [What we will do next](#what-we-will-do-next)
+
 ## Why we did this work
 
 We had been given an agreed eligible training list for the care skills funding pot for the start of private beta. To date, we had made some assumptions and created a general structure for what we felt this data would contain and then designed around that. Now we had this new training list, and we needed to adapt how the training list is displayed in the select training screen to accommodate the new data structure.

app/posts/claims/2024-05-21-claims-tables-iteration.md

@@ -16,6 +16,12 @@ aside:
     Password: bsaasc123
 ---
 
+Contents
+--- [Why we did this work](#why-we-did-this-work)
+--- [What our ideas were](#what-our-ideas-were)
+--- [How we tested our ideas and what we found](#how-we-tested-our-ideas-and-what-we-found)
+--- [What we will do next](#what-we-will-do-next)
+
 ## Why we did this work
 
 Before implementing the new funding model, we conducted preliminary groundwork to prepare for its introduction. With the new model, different types of claims were introduced, initially categorized as:

app/posts/claims/2024-05-30-60-40-design.md

@@ -15,6 +15,12 @@ aside:
     Password: bsaasc123
 ---
 
+Contents
+--- [Why we did this work](#why-we-did-this-work)
+--- [What our ideas were](#what-our-ideas-were)
+--- [How we tested our ideas and what we found](#how-we-tested-our-ideas-and-what-we-found)
+--- [What we will do next](#what-we-will-do-next)
+
 ## Why we did this work
 
 Our service previously focused on a 100% funding model, where claims were submitted after course completion. However, we needed to adapt the design to support a new 60/40 funding model. This model requires users to submit evidence of payment for 60% of the reimbursement amount after the course begins and then submit evidence of completion for the remaining 40%. 

app/posts/claims/2024-06-11-supporting-onboarding.md

@@ -12,6 +12,12 @@ tags:
   - content
 ---
 
+Contents
+--- [Why we did this work](#why-we-did-this-work)
+--- [What our ideas were](#what-our-ideas-were)
+--- [How we tested our ideas and what we found](#how-we-tested-our-ideas-and-what-we-found)
+--- [What we will do next](#what-we-will-do-next)
+
 ## Why we did this work
 
 DHSC and NHSBSA were keen to quickly onboard adult social care (ASC) organisations to the live service during private beta. This is important to see how the service is performing in the real world, understand how well the scheme is understood and utilise the fund effectively by getting as much money as possible to claimants.

app/posts/claims/2024-06-20-cpd-claims.md

@@ -15,6 +15,12 @@ aside:
     Password: ascbsa123
 ---
 
+Contents
+--- [Why we did this work](#why-we-did-this-work)
+--- [What our ideas were](#what-our-ideas-were)
+--- [How we tested our ideas and what we found](#how-we-tested-our-ideas-and-what-we-found)
+--- [What we will do next](#what-we-will-do-next)
+
 So far the prototype only allows for TU claims to be submitted, as dictated by roadmap and priorities we now want to bring in CPD claims. The expectation is that there are going to be less of these type of claims, so the direction was to balance user needs with coming up with a design flow that has the least amount of changes needed to the TU journey, with minimal technical effort, to allow for less work and quicker delivery.
 
 ## Why we did this work

app/posts/claims/2024-06-27-org-admin-phase-1.md

@@ -15,6 +15,12 @@ aside:
     Password: bsaasc123
 ---
 
+Contents
+--- [Why we did this work](#why-we-did-this-work)
+--- [What our ideas were](#what-our-ideas-were)
+--- [How we tested our ideas and what we found](#how-we-tested-our-ideas-and-what-we-found)
+--- [What we will do next](#what-we-will-do-next)
+
 ## Why we did this work
 
 For the start of private beta, a key constraint of the service was that it would only allow one user per organisation, this user was the signatory. Due to the delivery deadline and uncertainty around the legal aspect of the grant determination letter, our onboarding process for the start of private beta would need to have this signatory be the representative from the organisation who signs up and subsequently would be the only permitted user of the service from that organisation for day 1 of private beta. 

app/posts/claims/2024-07-17-cpd-claim-iteration.md

@@ -15,6 +15,12 @@ aside:
     Password: ascbsa123
 ---
 
+Contents
+--- [Why we did this work](#why-we-did-this-work)
+--- [What our ideas were](#what-our-ideas-were)
+--- [How we tested our ideas and what we found](#how-we-tested-our-ideas-and-what-we-found)
+--- [What we will do next](#what-we-will-do-next)
+
 There were three key aspects of the CPD journey identified as not working and needing further iteration. The activity type, evidence of completion collection, and CPD eligibility. Worked through options of design and held workshop to discuss and crit with business.
 
 ## Why we did this work

app/posts/claims/2024-07-25-60-40-iteration.md

@@ -15,6 +15,12 @@ aside:
     Password: bsaasc123
 ---
 
+Contents
+--- [Why we did this work](#why-we-did-this-work)
+--- [What our ideas were](#what-our-ideas-were)
+--- [How we tested our ideas and what we found](#how-we-tested-our-ideas-and-what-we-found)
+--- [What we will do next](#what-we-will-do-next)
+
 ## Why we did this work
 At the end of May 2024 and the start of June 2024, we introduced a 60/40 funding model for eligible training (as described in the post "Designing for a different funding model - 60/40"). During this work, we had two conflicting mental models about how users might approach the 60/40 claim:
 

app/posts/claims/2024-08-12-signatory-to-sro.md

@@ -17,6 +17,12 @@ aside:
     Password: bsaasc123
 ---
 
+Contents
+--- [Why we did this work](#why-we-did-this-work)
+--- [What our ideas were](#what-our-ideas-were)
+--- [How we tested our ideas and what we found](#how-we-tested-our-ideas-and-what-we-found)
+--- [What we will do next](#what-we-will-do-next)
+
 ## Why we did this work
 
 During alpha, we had established the need for each organisation to sign the grant determination letter (GDL) before they could use the service.

app/posts/claims/2024-08-20-delete-a-claim.md

@@ -15,6 +15,12 @@ aside:
     Password: bsaasc123
 ---
 
+Contents
+--- [Why we did this work](#why-we-did-this-work)
+--- [What our ideas were](#what-our-ideas-were)
+--- [How we tested our ideas and what we found](#how-we-tested-our-ideas-and-what-we-found)
+--- [What we will do next](#what-we-will-do-next)
+
 ## Why we did this work
 
 There are a few scenarios that could lead to a claim being created that can't or won't be progressed:

app/posts/claims/2024-08-20-delete-a-submitter.md

@@ -15,6 +15,12 @@ aside:
     Password: bsaasc123
 ---
 
+Contents
+--- [Why we did this work](#why-we-did-this-work)
+--- [What our ideas were](#what-our-ideas-were)
+--- [How we tested our ideas and what we found](#how-we-tested-our-ideas-and-what-we-found)
+--- [What we will do next](#what-we-will-do-next)
+
 ## Why we did this work
 Senior Responsible Officers (SROs), previously called Signatories, can invite up to 9 additional submitters to use the service on behalf of the organisation. We identified a few scenarios where a submitter invited by an SRO might no longer need access to the service:
 

app/posts/claims/2024-08-20-view-uploaded-evidence.md

@@ -14,6 +14,11 @@ aside:
     Password: bsaasc123
 ---
 
+Contents
+--- [Why we did this work](#why-we-did-this-work)
+--- [What our ideas were](#what-our-ideas-were)
+--- [How we tested our ideas and what we found](#how-we-tested-our-ideas-and-what-we-found)
+
 ## Why we did this work
 
 Once a submitter uploads a file as a piece of evidence, there is currently no way to view that file in the service. We identified a few scenarios that may mean an individual would benefit from viewing the evidence they uploaded:

app/posts/claims/2024-09-18-removing-care-skills.md

@@ -17,6 +17,12 @@ aside:
     Password: bsaasc123
 ---
 
+Contents
+--- [Why we did this work](#why-we-did-this-work)
+--- [What our ideas were](#what-our-ideas-were)
+--- [How we tested our ideas and what we found](#how-we-tested-our-ideas-and-what-we-found)
+--- [What we will do next](#what-we-will-do-next)
+
 ## Why we did this work
 
 The original funding scheme - the Training Fund Reimbursement Scheme (TFRS) - consisted of 2 types of funding:

app/posts/claims/2024-10-20-find-a-claim.md

@@ -15,6 +15,12 @@ aside:
     Password: bsaasc123
 ---
 
+Contents
+--- [Why we did this work](#why-we-did-this-work)
+--- [What our ideas were](#what-our-ideas-were)
+--- [How we tested our ideas and what we found](#how-we-tested-our-ideas-and-what-we-found)
+--- [What we will do next](#what-we-will-do-next)
+
 ## Why we did this work
 During alpha a few options were tried to allow users to search and filter for claims in their dashboard, this was removed from the prototype to help descope the complexity of the MVP. The need for users to be able to find a claim easily is still present.
 

app/posts/claims/2024-11-11-three-character-minimum-search.md

@@ -15,6 +15,11 @@ aside:
     Password: bsaasc123
 ---
 
+Contents
+--- [Why we did this work](#why-we-did-this-work)
+--- [What our ideas were](#what-our-ideas-were)
+--- [How we tested our ideas and what we found](#how-we-tested-our-ideas-and-what-we-found)
+
 ## Why we did this work
 
 The introduction of a three-character minimum search limit emerged during advanced search design discussions. Initially, users could search with a single character, which had potential to produced lengthy result lists requiring pagination and table sorting features to be a higher priority to help the user work through results. These features are more technically complex and time-consuming to implement though so this prompted a consideration of the trade-offs between usability and roadmap priorities. It was decided that users likely have sufficient information to input at least three characters, making this a minimal inconvenience to users, while dramatically reducing number of results. Pagination and sorting were deprioritized and added to the backlog for post-MVP implementation across the service.

app/posts/claims/2024-11-20-aligning-user-expectations.md

@@ -13,6 +13,12 @@ tags:
   - WDF
 ---
 
+Contents
+--- [Why we did this work](#why-we-did-this-work)
+--- [What our ideas were](#what-our-ideas-were)
+--- [How we tested our ideas and what we found](#how-we-tested-our-ideas-and-what-we-found)
+--- [What we will do next](#what-we-will-do-next)
+
 ## Why we did this work
 
 We suspected for a while that some new users of the service had unrealistic expectations of what they could get reimbursement for and how the claims process worked. We thought this was particularly likely for people who'd used the Workforce Development Fund (WDF) previously. This is the legacy reimbursement scheme that LDSS is replacing.

app/posts/claims/2024-12-13-claim-table-pagination.md

@@ -14,6 +14,12 @@ aside:
     Password: bsaasc123
 ---
 
+Contents
+--- [Why we did this work](#why-we-did-this-work)
+--- [What our ideas were](#what-our-ideas-were)
+--- [How we tested our ideas and what we found](#how-we-tested-our-ideas-and-what-we-found)
+--- [What we will do next](#what-we-will-do-next)
+
 ## Why we did this work
 
 As part of work done to scale back the MVP in March to try and meet an aggressive delivery schedule, we removed pagination from the proposed designs. Please see the design history post [Scaling back MVP](../scaling-back-mvp) for more details on the aspects removed from the MVP as part of that work.