Residency tax status look up service (relief at source) - alpha

RESIDENCY TAX STATUS LOOK UP SERVICE (RELIEF AT SOURCE) - ALPHA The report from the alpha assessment for HMRC’s Residency Tax Status Look Up Service (Relief at Source) service on 6 October

2017. CONTENTS * The service met the Standard because * About the service * Description * Service users * Detail * User needs * Team * Technology * Design * Analytics * Recommendations * To

pass the next assessment, the service team must * The service team should also * Digital Service Standard points From: Central Digital and Data Office Assessment date: 06 October 2017 Stage:

Alpha Result: Met Service provider: HMRC THE SERVICE MET THE STANDARD BECAUSE: * The team have developed a strong understanding of their users and have good evidence that the service they

have designed will meet their users’ needs. * The team is well-balanced, working effectively and has the skills it needs to design and build a good service. * The team had designed a modular

service and extensible API and is already make some of their source code open. ABOUT THE SERVICE DESCRIPTION When a person joins a personal pension scheme that qualifies for ‘relief at

source’, the Pension Scheme Administrator (PSA) can claim tax relief from HMRC on the pension contributions. The Relief at Source lookup service will allow PSAs to enter the member’s

personal details to confirm the residency tax status of the new scheme member so that they can claim the correct rate of monthly tax relief from the point they join and make a pension

contribution. SERVICE USERS Employees of PSAs will be the users of the RAS look up service. The type of user within the organisation will depend of the size and type of PSA. DETAIL USER

NEEDS The team demonstrated a thorough understanding of the different kinds of likely users at different kinds of pension scheme provider. They also have a good understanding of the needs of

developers working within pension scheme providers and in specialist software providers who will access the service through an API. The team gained this understanding through a variety of

research methods, including contextual research with pension scheme providers and with developers. The team have done some work to learn about users who might need support. From this they

are aiming to provide a specialist support desk for developers, and route other users to existing HMRC support channels. The team have completed an internal accessibility review of the

web-based service. The team have produced a good set of persons and journey maps to describe what they have learned so far. The team have a good overall plan for running a private beta and

moving into an open beta. But the team needs to be clearer about how it will learn from beta users and how it will test it’s support model. The team are commissioning a full accessibility

audit of their beta service. The team should also engage with relevant staff groups within pension scheme providers to test the accessibility of their service in context and learn more about

potential accessibility issues. TEAM The panel were impressed by the small but balanced and effective team. The team are part of a broader group working on tax relief at source. They are

working well with other teams building related services, and are in contact with the Scottish Government. They have worked hard to build a detailed understanding of the broader landscape

their service fits into. The team are working in 2 week sprints, with a clear and effective feedback cycle. They have regular retros and are using them to improve how they work. The team are

challenging policy and legal constraints where appropriate to make sure the service works well for users. And they looking at broader potential improvements to simplify the service both for

pension scheme providers and HMRC. The team are engaging well with pension scheme providers and developers to ensure effective take up of the service. The team will stay together through

beta. TECHNOLOGY The panel was pleased to see that the team is using the prototype kit for quick iteration to shorten the lifecycle of a story. For private beta, the team is building a full

feature app on a technology stack they understand well and is widely used among the teams in their area, so there is potential to reuse and share code. The team has set up a deployment

system and environments that enable them to deploy frequently without affecting users of their service. They have a robust system of authentication in place, as well as policies that

mitigate any potential security threats. They are making their code open-source - some is already on Github. They’re thinking about ways to design their API so that it is modular and

extendable. The panel was pleased to see that the team have set up environments that are scalable and easy to create. The team are able to run performance test on environments as well as

monitor their status. The team is already working on procedures and communication for if/when their service is offline. The team is working with HMRC’s accessibility champion to ensure their

service is accessible to their users. DESIGN The team have tried a few different design options during Alpha which is good to see. The reason for moving to the ‘one page per thing’ format

needs to be based on user research. This service will potentially have a lot of repetitive use and therefore ‘one page per thing’ should be tested so it doesn’t slow down these specialist

PSA users (versus a single page format for example). The team have already spoke to approx. 20% of all PSAs who would use this service, so there is plenty of scope to get valuable feedback

on this. The team also discussed they are examining the need for a bulk upload option. If there is a clear need defined for this it should be usability tested and iterated. Some language

inconsistencies were spotted and suggestions made in a separate content report which will be sent to the team. Any existing language inconsistencies should be ironed out as the service is

iterated. The team noted they were iterating terminology based on research which is good. The team are working well to define and improve support for unhappy paths within the service and

should continue to do this. The team are working with GOV.UK content teams to make sure the journey from guidance is effective and in keeping with GOV.UK start page guidelines. There is no

alternative to the service, but long deadlines mean that pension scheme providers have several weeks to catch up, and the fallback is to assign the person to rest of UK. There is guidance on

GOV.UK on what to do in different situations. ANALYTICS The service team have an analyst from the HMRC performance team joining them to establish measures of completion, cost and

satisfaction. The team are working on measure of success for their new service, including measuring actual numbers of transactions and results (Scotland or Rest of UK) against expected. The

team also plan to better understand the use of the service by measuring how different sizes and types of pension scheme providers use the web-based and API channels. RECOMMENDATIONS TO PASS

THE NEXT ASSESSMENT, THE SERVICE TEAM MUST: * Do more work with people with disabilities working in pension scheme providers to understand potential barriers and uncover any accessibility

issues. * Have a clearer plan for getting feedback from beta users. * Have a clearer plan for testing their support model. THE SERVICE TEAM SHOULD ALSO: * Continue to use existing tools and

technologies to deliver their service, allowing them to build a modular and extendable service and API solution DIGITAL SERVICE STANDARD POINTS Point Description Result 1 Understanding user

needs Met 2 Improving the service based on user research and usability testing Met 3 Having a sustainable, multidisciplinary team in place Met 4 Building using agile, iterative and

user-centred methods Met 5 Iterating and improving the service on a frequent basis Met 6 Evaluating tools, systems, and ways of procuring them Met 7 Managing data, security level, legal

responsibilities, privacy issues and risks Met 8 Making code available as open source Met 9 Using open standards and common government platforms Met 10 Testing the end-to-end service, and

browser and device testing Met 11 Planning for the service being taken temporarily offline Met 12 Creating a simple and intuitive service Met 13 Ensuring consistency with the design and

style of GOV.UK Met 14 Encouraging digital take-up Met 15 Using analytics tools to collect and act on performance data Met 16 Defining KPIs and establishing performance benchmarks Met 17

Reporting performance data on the Performance Platform Met 18 Testing the service with the minister responsible for it Met UPDATES TO THIS PAGE Published 30 July 2018 Contents