{"id":74,"date":"2026-06-16T01:46:39","date_gmt":"2026-06-16T01:46:39","guid":{"rendered":"https:\/\/rikonrahman.com\/demo\/nhs-service-finder\/"},"modified":"2026-07-06T01:58:54","modified_gmt":"2026-07-06T01:58:54","slug":"nhs-service-finder","status":"publish","type":"page","link":"https:\/\/rikonrahman.com\/r1\/nhs-service-finder\/","title":{"rendered":"NHS Service Finder"},"content":{"rendered":"\t\t
\n\t\t\t\t
\n\t\t
\n\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t

<\/polyline> <\/svg> All case studies<\/span> <\/a> <\/p>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t

\n\t\t\t\t\t\t\t\t\t

Healthcare \/ Public Sector<\/p>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t

\n\t\t\t\t\t

Designing secure access and accessible service journeys for NHS Service Finder<\/h1>\t\t\t\t<\/div>\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t

I led UX for a national Service Finder modernisation, helping move 100,000+ health and care professionals<\/strong> from legacy email\/password login toward Care Identity Authentication (CIS2)<\/strong>, while improving accessibility across critical service journeys. This was not only a login migration \u2014 it was a service modernisation across identity, user readiness, account states, accessibility barriers, and local component debt. <\/p>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t

\n\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t\"\"\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t
Role<\/dt>
Senior UX & Interaction Designer<\/dd> <\/div>
Timeline<\/dt>
June 2025 \u2013 April 2026<\/dd> <\/div>
Product<\/dt>
NHS Service Finder<\/dd> <\/div>
Scale<\/dt>
100,000+ health and care professionals<\/dd> <\/div> <\/dl>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t
\n\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t

Impact at a glance<\/p>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t

\n\t\t\t\t\t\t\t\t\t

  • 100k+<\/p>

    Health and care professionals supported across NHS services<\/p> <\/li>

  • 94%<\/p>

    Completed the migration without contacting support in the first week<\/p> <\/li>

  • 2.4d \u2192 now<\/p>

    Onboarding reduced to near real time using trusted organisation and role data<\/p> <\/li>

  • 36<\/p>

    Key pages audited across web and mobile \u2014 25 pages had accessibility issues<\/p> <\/li>

  • 35%<\/p>

    Faster task completion for users with accessibility needs in internal testing<\/p> <\/li>

  • NHS DS<\/p>

    Design System alignment used as a sustainable accessibility strategy, not a visual refresh<\/p> <\/li> <\/ul>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t

    \n\t\t
    \n\t\t\t\t
    \n\t\t\t\t\t\t\t\t\t

    Product context<\/p>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t

    \n\t\t\t\t\t

    What is NHS Service Finder?<\/em><\/h2>\t\t\t\t<\/div>\n\t\t\t\t
    \n\t\t\t\t\t\t\t\t\t

    The product<\/p>

    NHS Service Finder is used by health and care professionals to find accurate, up-to-date information about available services in a specific location. Users may be looking for urgent treatment centres, pharmacies, mental health support, referral routes, eligibility criteria, opening times, or contact details. <\/p>

    These users often work under pressure. They need to find the right service quickly, trust the information, and recover easily when something goes wrong. This is not a general public-facing search tool \u2014 it supports professional workflows where accuracy, speed, trust, and accessibility matter. <\/p> <\/div> <\/div>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t

    \n\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t\"\"\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t
    \n\t\t\t\t\t\t\t\t\t

    Service Finder supports time-sensitive decisions by helping health and care professionals find relevant services, referral routes, eligibility details, and availability information. <\/p>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t

    \n\t\t
    \n\t\t\t\t
    \n\t\t\t\t\t\t\t\t\t

    The challenge<\/p>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t

    \n\t\t\t\t\t

    Five connected service journey problems<\/em><\/h2>\t\t\t\t<\/div>\n\t\t\t\t
    \n\t\t\t\t\t\t\t\t\t

    1. 01<\/p>

      Legacy login<\/p> <\/li>

    2. <\/path><\/svg> <\/li>

    3. 02<\/p>

      Account states<\/p> <\/li>

    4. <\/path><\/svg> <\/li>

    5. 03<\/p>

      CIS2 handoff<\/p> <\/li>

    6. <\/path><\/svg> <\/li>

    7. 04<\/p>

      Accessibility gaps<\/p> <\/li>

    8. <\/path><\/svg> <\/li>

    9. 05<\/p>

      Component debt<\/p> <\/li> <\/ol>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t

      \n\t\t\t\t\t\t\t\t\t

      • 01<\/p>

        Legacy login created a behaviour-change challenge<\/h3>

        Users relied on familiar email\/password login. Moving to Care Identity improved security, but required users to change an established behaviour under time pressure. Users had mixed digital confidence and many needed repeated guidance and reassurance. <\/p> <\/li>

      • 02<\/p>

        Users entered from multiple account contexts<\/h3>

        New users, existing users, Cognito users, and mismatched accounts each needed different routes, logic, and recovery paths. Each context required a distinct journey and a clear path when something went wrong. <\/p> <\/li>

      • 03<\/p>

        Care Identity setup happened outside Service Finder<\/h3>

        Setup opened on a separate NHS platform in a new tab and required users to return manually. Login redirected users back automatically after MFA. This technically correct behaviour was confusing for users. <\/p> <\/li>

      • 04<\/p>

        Accessibility issues existed at multiple levels<\/h3>

        Some issues were minor and could be fixed quickly. Others affected interaction behaviour, page hierarchy, keyboard order, search flows, and repeated patterns \u2014 requiring design work, not just surface fixes. <\/p> <\/li>

      • 05<\/p>

        The local component library became a constraint<\/h3>

        Service Finder used a local React library that had drifted from NHS Design System standards, creating inconsistent UI patterns, accessibility gaps, duplication, and growing maintenance overhead. <\/p> <\/div>

        \u201cThese issues were connected: the identity migration exposed account-state complexity, the accessibility audit exposed structural barriers, and those barriers exposed the limits of the local component library.\u201d <\/p> <\/blockquote> <\/li> <\/ul>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t

        \n\t\t
        \n\t\t\t\t
        \n\t\t\t\t\t\t\t\t\t

        My role<\/p>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t

        \n\t\t\t\t\t

        Senior UX & Interaction Designer<\/h2>\t\t\t\t<\/div>\n\t\t\t\t
        \n\t\t\t\t\t\t\t\t\t

        I led UX across secure access, accessibility, search, and design system alignment \u2014 making complex constraints understandable for users, developers, product stakeholders, and clinical teams. <\/p>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t

        \n\t\t\t\t\t\t\t\t\t
        • \"\"<\/div>

          CIS2 Migration<\/h3>
          • Mapped login journeys and account states<\/li>
          • Designed staged migration messaging<\/li>
          • Aligned in-product experience with wider comms<\/li>
          • Defined recovery paths and access flows<\/li> <\/ul> <\/li>
          • \"\"<\/div>

            Accessibility<\/h3>
            • Audited 36 key pages across web and mobile<\/li>
            • Prioritised quick fixes and structural issues<\/li>
            • Translated findings into developer-ready tickets<\/li>
            • Redesigned critical accessibility barriers<\/li> <\/ul> <\/li>
            • \"\"<\/div>

              Design System<\/h3>
              • Audited local patterns against NHS Design System<\/li>
              • Defined Match \/ Minor Change \/ Does Not Match<\/li>
              • Challenged patching in favour of system-level alignment<\/li> <\/ul> <\/li>
              • \"\"<\/div>

                Interaction Craft<\/h3>
                • Redesigned dense search results for scannability<\/li>
                • Improved structure, hierarchy, and interaction clarity<\/li>
                • Designed search patterns for different intents and devices<\/li> <\/ul> <\/li> <\/ul>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t
                  \n\t\t\t\t\t\t\t\t\t

                  Main contribution:<\/strong> Making complex identity, accessibility, and design system constraints understandable for users, developers, product stakeholders, and clinical teams. <\/p>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t

                  \n\t\t
                  \n\t\t
                  \n\t\t\t\t
                  \n\t\t\t\t\t\t\t\t\t

                  01<\/p>\t\t\t\t\t\t\t\t<\/div>\n\t\t

                  \n\t\t\t\t
                  \n\t\t\t\t\t\t\t\t\t

                  Chapter<\/p>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t

                  \n\t\t\t\t\t

                  Care Identity migration<\/h2>\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t
                  \n\t\t
                  \n\t\t\t\t
                  \n\t\t\t\t\t\t\t\t\t

                  Designing for multiple user and account contexts<\/p>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t

                  \n\t\t\t\t\t

                  One migration, many different<\/em> starting points<\/h3>\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
                  \n\t\t\t\t\t\t\t\t\t

                  Why this mattered<\/p>

                  The Care Identity migration was not a single linear flow. Users arrived with different account histories and levels of readiness. A new user without Care Identity needed a different route from an existing Service Finder user migrating account data. A user with an email mismatch needed a different path again. A user blocked before login still needed help. <\/p>

                  Without this mapping, users could take the wrong route: creating a new account instead of migrating, failing to link accounts because emails did not match, or being blocked before reaching help. <\/p>

                  Collaboration:<\/strong> I worked with a service designer to map the key account states. My focus was translating those states into clear product journeys, interactions, guidance, and recovery paths. <\/p> <\/div> <\/div>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t

                  \n\t\t\t\t\t\t\t\t\t
                  User state<\/th> UX risk<\/th> Designed route<\/th> <\/tr> <\/thead>
                  New user without Care Identity<\/td> Abandons at cross-platform boundary<\/td> Setup guidance + return instructions<\/td> <\/tr>
                  New user with Care Identity<\/td> Creates duplicate account<\/td> Detection \u2192 MFA \u2192 account creation<\/td> <\/tr>
                  Existing user with Care Identity<\/td> Unsure whether to log in or migrate<\/td> Migration route + email linking<\/td> <\/tr>
                  User on legacy Cognito login<\/td> Gets locked out without preparation<\/td> Staged warnings \u2192 interrupt \u2192 decommission<\/td> <\/tr>
                  User with email mismatch<\/td> Thinks account is permanently locked<\/td> Manual email step + recovery route<\/td> <\/tr>
                  User needing approval<\/td> Assumes something is broken<\/td> Approval state + timeline + next steps<\/td> <\/tr>
                  User needing help before login<\/td> Blocked before reaching support<\/td> Help available without authentication<\/td> <\/tr> <\/tbody> <\/table> <\/div>\t\t\t\t\t\t\t\t<\/div>\n\t\t
                  \n\t\t\t\t
                  \n\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t\"\"\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t
                  \n\t\t
                  \n\t\t\t\t
                  \n\t\t\t\t\t\t\t\t\t

                  Designing the transition, not just the login<\/p>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t

                  \n\t\t\t\t\t

                  Staged in-product migration messages<\/em><\/h3>\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
                  \n\t\t\t\t\t\t\t\t\t

                  The challenge<\/p>

                  The hardest part of the migration was not the authentication technology. It was helping a large, busy, mixed-confidence user base change a familiar behaviour. My role was to align the in-product experience with the wider communication plan \u2014 landing page messages, login warnings, interrupt pages, password-reset warnings, help pages, and final decommissioning states. <\/p>

                  The staged approach gave users repeated chances to understand, prepare, act, and recover. In the first week of migration, 94% of users completed the process without contacting support<\/strong>. <\/p>

                  Collaboration:<\/strong> I worked with the content designer on every in-product message. They owned wording and tone; I owned placement, logic, and recovery flows. We reviewed each stage together before sprint delivery. <\/p> <\/div> <\/div>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t

                  \n\t\t\t\t\t\t\t\t\t

                  Migration stages<\/p> <\/span>Owned by me<\/span> <\/span>Wider team<\/span> <\/span>Aligned with me<\/span> <\/div>

                  1. Awareness<\/p>

                    Early phase<\/p>

                    • Landing page banner<\/li>
                    • Login soft prompt<\/li>
                    • Email announcement<\/li>
                    • Webinar invitation<\/li> <\/ul> <\/li>

                    • Preparation<\/p>

                      Mid phase<\/p>

                      • What is Care Identity?<\/li>
                      • How to set up guide<\/li>
                      • Before-you-start page<\/li>
                      • Email: step-by-step<\/li>
                      • Webinar 1 + 2<\/li> <\/ul> <\/li>

                      • Deadline<\/p>

                        Oct 2025<\/p>

                        • Warning banner on login<\/li>
                        • Password reset warning<\/li>
                        • Help pages updated<\/li>
                        • Email: deadline reminder<\/li> <\/ul> <\/li>

                        • Friction<\/p>

                          Nov 2025<\/p>

                          • Interrupt page<\/li>
                          • Skip for now option<\/li>
                          • Having trouble? link<\/li> <\/ul> <\/li>

                          • Decommission<\/p>

                            Nov 2025+<\/p>

                            • Legacy login removed<\/li>
                            • CIS2-only landing state<\/li>
                            • Support before login<\/li> <\/ul> <\/li>

                            • Sunset<\/p>

                              Mar 2026<\/p>

                              • Ambulance trust warning<\/li>
                              • Temp access ending 31 Mar<\/li>
                              • Email to trust users<\/li> <\/ul> <\/li> <\/ol> <\/div>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t
                                \n\t\t
                                \n\t\t\t\t
                                \n\t\t\t\t\t\t\t\t\t

                                Protecting emergency access during winter pressure<\/p>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t

                                \n\t\t\t\t\t

                                Security versus clinical continuity<\/em><\/h3>\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
                                \n\t\t\t\t\t\t\t\t\t

                                The tradeoff<\/p>

                                From a security standpoint, the cleanest option was to move everyone to Care Identity and remove the old login. But the timing overlapped with winter pressure, when urgent and emergency care services face increased demand. <\/p>

                                I worked with engineering to use Ambulance Trust ODS codes<\/strong> as an eligibility rule \u2014 recognising users linked to ambulance trusts and routing them through a temporary safe path. The exception was limited, temporary, intentional, and based on clinical risk, not convenience. <\/p> <\/div> <\/div>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t

                                \n\t\t\t\t\t\t\t\t\t

                                Authentication decision flow<\/p>

                                User attempts login<\/p> \u2193<\/span>

                                Can use Care Identity?<\/p> <\/div>

                                Yes<\/p>

                                Care Identity MFA<\/p> \u2193<\/span>

                                Access granted<\/p> <\/div>

                                No \/ unclear<\/p>

                                Check ODS code<\/p> \u2193<\/span>

                                Amb. trust \u2192 temp route<\/p>

                                Until 31 Mar 2026<\/p> <\/div>

                                Other<\/p>

                                Support \/ recovery<\/p>

                                Help available before login<\/p> <\/div> <\/div> <\/figure>\t\t\t\t\t\t\t\t<\/div>\n\t\t

                                \n\t\t\t\t
                                \n\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t\"\"\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t
                                \n\t\t
                                \n\t\t\t\t
                                \n\t\t\t\t\t\t\t\t\t

                                Making the external handoff understandable and recoverable<\/p>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t

                                \n\t\t\t\t\t

                                Setup vs login: two different handoff behaviours<\/em><\/h3>\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
                                \n\t\t\t\t\t\t\t\t\t

                                The problem<\/p>

                                Care Identity was owned by another national team. Setup and login behaved differently: setup<\/strong> opened in a new tab and required users to return manually; login<\/strong> opened in the same tab and returned users automatically after MFA. This was technically correct, but confusing. <\/p>

                                Working with a content designer, I made the handoff explicit before users left Service Finder \u2014 explaining where they were going, why, whether they needed to return manually, and what to do if setup or login failed. A key decision was making Help available before login, so users blocked before authentication could still get support. <\/p> <\/div> <\/div>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t

                                \n\t\t\t\t\t\t\t\t\t

                                \u2197<\/span> Care Identity setup<\/h4>
                                1. User begins setup from Service Finder<\/span> Before-you-start guidance explains what will happen<\/span> <\/li>
                                2. Care Identity opens in a new tab<\/span> Explicitly told a new tab will open and why<\/span> <\/li>
                                3. User completes MFA and account creation<\/span> <\/li>
                                4. User must return to Service Finder manually<\/span> Guidance explains return steps before they leave<\/span> <\/li>
                                5. User logs in with new Care Identity credentials<\/span> <\/li> <\/ol> <\/article>

                                  Login \u2014 automatic return<\/p>

                                  \u2192<\/span> Care Identity login<\/h4>
                                  1. User selects Care Identity login<\/span> Same-tab redirect begins immediately<\/span> <\/li>
                                  2. Care Identity opens in the same tab<\/span> <\/li>
                                  3. User completes MFA on Care Identity<\/span> <\/li>
                                  4. Service Finder returns the user automatically<\/span> No manual return needed \u2014 access granted<\/span> <\/li> <\/ol> <\/article> <\/div>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t
                                    \n\t\t
                                    \n\t\t\t\t
                                    \n\t\t\t\t\t\t\t\t\t

                                    Recovery states \u2014 login failure scenarios<\/p>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t

                                    \n\t\t\t\t\t\t\t\t\t

                                    • Failed MFA<\/p>

                                      Your authentication code didn\u2019t work<\/h4>

                                      The code may have expired, or your authenticator app may not be synced. This is common and doesn\u2019t mean your account is locked. <\/p>

                                      • Try again<\/li>
                                      • Request a new code<\/li>
                                      • Contact local IT<\/li> <\/ul> <\/li>

                                      • Incomplete setup<\/p>

                                        Your Care Identity setup isn\u2019t finished<\/h4>

                                        You started setting up Care Identity but didn\u2019t complete all steps. Return to finish, then come back and log in. <\/p>

                                        • Return to Care Identity setup<\/li>
                                        • Get help<\/li> <\/ul> <\/li>

                                        • Email or role mismatch<\/p>

                                          We couldn\u2019t match your accounts<\/h4>

                                          The email or role on your Care Identity account differs from your Service Finder account. You can update or contact support to link them manually. <\/p>

                                          • Update email<\/li>
                                          • Contact support<\/li> <\/ul> <\/li>

                                          • Missing organisation data<\/p>

                                            We couldn\u2019t verify your access level<\/h4>

                                            Your organisation or role wasn\u2019t found in Care Identity. This may need to be added by your organisation\u2019s administrator before access can be granted. <\/p>

                                            • Contact your organisation<\/li>
                                            • Request support<\/li> <\/ul> <\/li> <\/ul>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t
                                              \n\t\t
                                              \n\t\t\t\t
                                              \n\t\t\t\t\t\t\t\t\t

                                              Supporting flow: organisation and role verification<\/p>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t

                                              \n\t\t\t\t\t

                                              Designing the professional information journey<\/em><\/h3>\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
                                              \n\t\t\t\t\t\t\t\t\t

                                              The design work<\/p>

                                              Care Identity did more than authenticate users. It also created an opportunity to use trusted organisation and role data to reduce manual access checks. <\/p>

                                              As part of the migration, I designed the Service Finder-side journey for users who needed to provide or confirm professional information, organisation details, and role data before access could be granted. This helped the service route users more clearly: <\/p>

                                              • eligible users could continue with less manual intervention<\/strong>,<\/li>
                                              • users with missing or unclear data were guided to approval or support<\/strong>,<\/li>
                                              • users understood why extra information was needed before accessing the service<\/strong>.<\/li> <\/ul>

                                                The goal was to avoid asking users to manually re-enter information the system could already verify through trusted identity data. <\/p> <\/div> <\/div>\t\t\t\t\t\t\t\t<\/div>\n\t\t

                                                \n\t\t\t\t
                                                \n\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t\"\"\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t
                                                \n\t\t
                                                \n\t\t\t\t
                                                \n\t\t\t\t\t\t\t\t\t

                                                Supporting impact<\/p>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t

                                                \n\t\t\t\t\t\t\t\t\t

                                                Manual onboarding previously took an average of 2.4 days<\/strong>. Using trusted organisation and role data helped reduce access time to near real time for eligible users. <\/p>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t

                                                \n\t\t
                                                \n\t\t
                                                \n\t\t\t\t
                                                \n\t\t\t\t\t\t\t\t\t

                                                02<\/p>\t\t\t\t\t\t\t\t<\/div>\n\t\t

                                                \n\t\t\t\t
                                                \n\t\t\t\t\t\t\t\t\t

                                                Chapter<\/p>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t

                                                \n\t\t\t\t\t

                                                Accessibility audit and prioritisation<\/h2>\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t
                                                \n\t\t
                                                \n\t\t\t\t
                                                \n\t\t\t\t\t\t\t\t\t

                                                From leadership priority to service-wide audit<\/p>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t

                                                \n\t\t\t\t\t

                                                36 pages, 25 issues, two types of problem<\/em><\/h3>\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
                                                \n\t\t\t\t\t\t\t\t\t

                                                The approach<\/p>

                                                After the Care Identity migration, accessibility surfaced as the next priority across leadership, product, design, and engineering. I started with a service-wide audit across 36 key pages on web and mobile. 25 pages had accessibility issues. <\/p>

                                                I classified issues as quick fixes<\/strong> (labels, contrast, helper text, small focus-state issues, semantic structure) or structural issues<\/strong> (search behaviour, page hierarchy, keyboard order, form behaviour, no-results recovery, repeated component patterns). This allowed quick fixes to move fast while structural issues were redesigned properly rather than patched. <\/p> <\/div> <\/div>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t

                                                \n\t\t\t\t\t\t\t\t\t

                                                • 36<\/p>

                                                  Pages audited web + mobile<\/p> <\/li>

                                                • 25<\/p>

                                                  Pages with issues<\/p> <\/li>

                                                • 2<\/p>

                                                  Issue types: quick fixes + structural<\/p> <\/li>

                                                • WCAG AA<\/p>

                                                  Compliance target across all screens<\/p> <\/li> <\/ul>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t

                                                  \n\t\t\t\t\t\t\t\t\t

                                                  Issue classification<\/p>

                                                  Quick fixes<\/h4>

                                                  Labels \u00b7 helper text \u00b7 colour contrast \u00b7 small focus states \u00b7 semantic structure \u00b7 content clarity <\/p> <\/div>

                                                  Structural issues<\/h4>

                                                  Search auto-navigation \u00b7 missing submit actions \u00b7 incorrect focus order \u00b7 unclear link purpose \u00b7 dense result hierarchy \u00b7 repeated component patterns <\/p> <\/div> <\/div> <\/div>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t

                                                  \n\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t\"\"\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t
                                                  \n\t\t
                                                  \n\t\t\t\t
                                                  \n\t\t\t\t\t\t\t\t\t

                                                  Turning findings into developer-ready work<\/p>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t

                                                  \n\t\t\t\t\t

                                                  From audit spreadsheet to actionable Jira tickets<\/em><\/h3>\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
                                                  \n\t\t\t\t\t\t\t\t\t

                                                  The work<\/p>

                                                  The audit spreadsheet identified issues, but it was not implementation-ready. Developers needed clear guidance on what each issue meant, why it mattered, and what behaviour was expected. I translated each finding into a structured Jira ticket with issue description, user impact, WCAG reference, expected behaviour, design guidance, and whether additional design work was required. <\/p> <\/div> <\/div>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t

                                                  \n\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t\"\"\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t
                                                  \n\t\t
                                                  \n\t\t\t\t
                                                  \n\t\t\t\t\t\t\t\t\t

                                                  Building accessibility understanding in the team<\/p>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t

                                                  \n\t\t\t\t\t

                                                  Accessibility as a shared team practice<\/em><\/h3>\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
                                                  \n\t\t\t\t\t\t\t\t\t

                                                  The approach<\/p>

                                                  Accessibility was not treated as a final QA checklist. I helped the team build shared understanding through guidance, tool usage, and workshop activity. The team explored the product from different perspectives: keyboard navigation, VoiceOver, one-finger trackpad use, zoom, and reduced visual context. <\/p> <\/div> <\/div>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t

                                                  \n\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t\"\"\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t
                                                  \n\t\t
                                                  \n\t\t\t\t
                                                  \n\t\t\t\t\t\t\t\t\t

                                                  Redesigning structural accessibility barriers<\/p>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t

                                                  \n\t\t\t\t\t

                                                  Interaction redesign, not surface-level patches<\/em><\/h3>\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
                                                  \n\t\t\t\t\t\t\t\t\t

                                                  The work<\/p>

                                                  Some findings could not be solved through small UI tweaks. Structural issues included search behaviour that moved users unexpectedly, missing or unclear submit actions, incorrect focus order, unclear link purpose, low-contrast or undersized actions, dense result pages, and repeated patterns that made keyboard and screen reader navigation harder. I redesigned these areas so actions were visible, page changes were predictable, and key information was easier to understand. <\/p> <\/div> <\/div>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t

                                                  \n\t\t\t\t\t\t\t\t\t

                                                  Before<\/p>

                                                  After<\/p> <\/div> \"Before <\/figure>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t

                                                  \n\t\t
                                                  \n\t\t\t\t
                                                  \n\t\t\t\t\t\t\t\t\t

                                                  Validation<\/p>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t

                                                  \n\t\t\t\t\t

                                                  Testing and accessibility labs<\/em><\/h3>\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
                                                  \n\t\t\t\t\t\t\t\t\t

                                                  The outcome<\/p>

                                                  Improvements were validated through usability testing and accessibility testing, including accessibility lab sessions. Internal task-based testing showed a 35% improvement in completion speed<\/strong> for users with accessibility needs after the redesign. <\/p> <\/div> <\/div>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t

                                                  \n\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t\"\"\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t
                                                  \n\t\t
                                                  \n\t\t
                                                  \n\t\t\t\t
                                                  \n\t\t\t\t\t\t\t\t\t

                                                  03<\/p>\t\t\t\t\t\t\t\t<\/div>\n\t\t

                                                  \n\t\t\t\t
                                                  \n\t\t\t\t\t\t\t\t\t

                                                  Chapter<\/p>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t

                                                  \n\t\t\t\t\t

                                                  NHS Design System alignment<\/h2>\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t
                                                  \n\t\t
                                                  \n\t\t\t\t
                                                  \n\t\t\t\t\t\t\t\t\t

                                                  From local component debt to system-level alignment<\/p>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t

                                                  \n\t\t\t\t\t

                                                  Design System as a sustainable accessibility strategy<\/em><\/h3>\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
                                                  \n\t\t\t\t\t\t\t\t\t

                                                  The tradeoff<\/p>

                                                  The accessibility work exposed a deeper issue: many barriers were tied to repeated local components that had drifted from NHS Design System standards. Developers proposed patching local components for speed. I understood the short-term logic \u2014 but patching would preserve the long-term problem: maintaining components that imitated NHS patterns and reworking them whenever accessibility or design system standards changed. <\/p>

                                                  The better long-term approach was to move repeated patterns toward NHS Design System components where possible, adapt minor differences, and design Service Finder-specific patterns only where standard NHS components did not fit the use case. <\/p> <\/div> <\/div>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t

                                                  \n\t\t\t\t\t\t\t\t\t
                                                  Type<\/th> Example<\/th> Decision<\/th> <\/tr> <\/thead>
                                                  Match<\/span><\/td> Button, input, checkbox<\/td> Use NHS Design System directly<\/td> <\/tr>
                                                  Minor change<\/span><\/td> Form error, filter panel, banner<\/td> Align content, spacing, focus, labels<\/td> <\/tr>
                                                  Does not match<\/span><\/td> Search result card, auth recovery state, ODS journey<\/td> Create Service Finder-specific pattern<\/td> <\/tr> <\/tbody> <\/table> <\/div>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t
                                                  \n\t\t
                                                  \n\t\t\t\t
                                                  \n\t\t\t\t\t\t\t\t\t

                                                  Service Finder-specific components<\/p>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t

                                                  \n\t\t\t\t\t

                                                  Where NHS patterns didn't fit<\/em><\/h3>\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
                                                  \n\t\t\t\t\t\t\t\t\t

                                                  The approach<\/p>

                                                  Not every Service Finder pattern had a direct NHS Design System equivalent. For dense service result cards, quick search, symptom or clinical keyword search, opening times tables, open\/closed status tags, authentication recovery states, and ODS information flows \u2014 I documented the use case, accessibility needs, interaction behaviour, and relationship to existing NHS patterns before deciding whether to keep the pattern local or discuss it with the NHS Design System team. <\/p> <\/div> <\/div>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t

                                                  \n\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t\"\"\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t
                                                  \n\t\t
                                                  \n\t\t
                                                  \n\t\t\t\t
                                                  \n\t\t\t\t\t\t\t\t\t

                                                  04<\/p>\t\t\t\t\t\t\t\t<\/div>\n\t\t

                                                  \n\t\t\t\t
                                                  \n\t\t\t\t\t\t\t\t\t

                                                  Chapter<\/p>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t

                                                  \n\t\t\t\t\t

                                                  Accessible service search and interaction craft<\/h2>\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t
                                                  \n\t\t
                                                  \n\t\t\t\t
                                                  \n\t\t\t\t\t\t\t\t\t

                                                  Dense service information, fast decisions<\/p>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t

                                                  \n\t\t\t\t\t

                                                  Making search results easier to scan<\/em><\/h3>\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
                                                  \n\t\t\t\t\t\t\t\t\t

                                                  The problem<\/p>

                                                  Each search result carried dense service information: service name, type, distance, opening status, referral route, eligibility, access instructions, contact details, and notes. The problem was not displaying this information \u2014 it was helping users compare services quickly and confidently. <\/p>

                                                  I grouped service information into three priority levels: Primary<\/strong> (service name, type, opening status, distance), Secondary<\/strong> (referral route, eligibility, access criteria), and Supporting<\/strong> (access notes, contact details, additional information). <\/p> <\/div> <\/div>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t

                                                  \n\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t\"\"\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t
                                                  \n\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t\"\"\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t
                                                  \n\t\t
                                                  \n\t\t\t\t
                                                  \n\t\t\t\t\t\t\t\t\t

                                                  Supporting different search behaviours<\/p>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t

                                                  \n\t\t\t\t\t

                                                  Consistent patterns across intent and device<\/em><\/h3>\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
                                                  \n\t\t\t\t\t\t\t\t\t

                                                  The need<\/p>

                                                  Service Finder supported different ways to search: service search, clinical keyword or symptom search, and quick search. These needed consistent patterns while supporting different user intents. I aligned search behaviours across desktop and mobile, making sure users could understand where they were, what they were searching for, and how to recover when results were not useful. <\/p>

                                                  \u201cSearch patterns were aligned across different intents and screen sizes while preserving clear hierarchy and recovery guidance.\u201d<\/em> <\/p> <\/div> <\/div>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t

                                                  \n\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t\"\"\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t
                                                  \n\t\t
                                                  \n\t\t\t\t
                                                  \n\t\t\t\t\t\t\t\t\t

                                                  Accessibility beyond components<\/p>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t

                                                  \n\t\t\t\t\t

                                                  Accessible journeys, not just accessible components<\/em><\/h3>\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
                                                  \n\t\t\t\t\t\t\t\t\t

                                                  The focus<\/p>

                                                  Accessible components were not enough. A button can be accessible in isolation, but the journey can still fail if the page structure is confusing, keyboard order is wrong, error content is unclear, or users cannot recover from no-results states. Accessibility had to work at the level of structure, content, hierarchy, interaction states, and recovery paths. <\/p> <\/div> <\/div>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t

                                                  \n\t\t\t\t\t\t\t\t\t

                                                  Areas addressed<\/p>

                                                  1. 1<\/span> Heading structure<\/strong> \u2014 logical hierarchy for screen reader navigation across all pages.<\/span> <\/li>
                                                  2. 2<\/span> Keyboard focus order<\/strong> \u2014 follows visual reading order through each result and page.<\/span> <\/li>
                                                  3. 3<\/span> Visible focus states<\/strong> \u2014 3px solid ring, visible in light and forced-colour modes, WCAG 2.2.<\/span> <\/li>
                                                  4. 4<\/span> Form labels and errors<\/strong> \u2014 persistent labels, errors above the field, linked via aria-describedby<\/code>.<\/span> <\/li>
                                                  5. 5<\/span> No-results recovery<\/strong> \u2014 actionable next steps instead of dead ends.<\/span> <\/li>
                                                  6. 6<\/span> Contrast and readability<\/strong> \u2014 4.5:1 for text, 3:1 for UI components across all screens.<\/span> <\/li>
                                                  7. 7<\/span> Authentication error recovery<\/strong> \u2014 h1, plain language explanation, and role=\"alert\"<\/code> for screen readers.<\/span> <\/li> <\/ol> <\/div>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t
                                                    \n\t\t
                                                    \n\t\t\t\t
                                                    \n\t\t\t\t\t\t\t\t\t

                                                    Selected final UI<\/p>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t

                                                    \n\t\t\t\t\t

                                                    Final screens<\/em><\/h3>\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
                                                    \n\t\t\t\t\t\t\t\t\t

                                                    Selected final screens from the secure access migration and accessibility-led redesign. <\/p>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t

                                                    \n\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t\"\"\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t
                                                    \n\t\t
                                                    \n\t\t\t\t
                                                    \n\t\t\t\t\t\t\t\t\t

                                                    Outcomes<\/p>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t

                                                    \n\t\t\t\t\t

                                                    What the work achieved<\/em><\/h2>\t\t\t\t<\/div>\n\t\t\t\t
                                                    \n\t\t\t\t\t\t\t\t\t