Claim flat rate expenses beta assessment
The service currently allows a user to claim for Flat Rate Expenses (washing and laundering uniforms, small tools, protective clothing) in real-time.
| Service provider: | HMRC |
Previous assessment reports
Service description
The service currently allows a user to claim for Flat Rate Expenses (washing and laundering uniforms, small tools, protective clothing) in real-time. The team is looking to add professional fees and subscriptions that users can also claim later into the service, during the public beta phase.
Service users
This service is for employees who can claim tax relief on expenses for uniforms, protective clothing and small tools.
1. Understand user needs
Decision
The team met point 1 of the Standard.
What the team has done well
The panel was impressed that:
- the team are doing call centre analysis and ticket analysis and using the findings from this to understand more about their service
- the team are carrying out regular research including face to face, contextual and remote research to drive the development of the service
- the team have done assisted digital and accessibility research throughout, built into each round of research.
What the team needs to explore
Before their next assessment, the team needs to:
- look more broadly at understanding the context of potential service users and their needs in relation to claiming employee expenses. Point 1 in the service standard explains how “service teams should learn as much as possible about the problem users need them to solve” and “focusing on the user and the problem they’re trying to solve - rather than a particular solution - often means that you learn unexpected things about their needs.” Yet the team don’t seem to have any surprising findings which may be because the scope of the research is a bit narrow. It’s great that the team is focused on one slice of the journey but they must explore further what that slice is doing in the context of the broader user problem
- writing user needs in the user story format is a helpful way of communicating to a delivery team what the service should do to meet user needs. I would encourage making some of the needs higher level which describe the problem the user needs solving
- expand assisted digital research and do research with people with a wider range of access needs. The team have covered this so far, but expanding the range of accessibility research can help identify problems with the service.
2. Do ongoing user research
Decision
The team met point 2 of the Standard.
What the team has done well
The panel was impressed that:
- the team are iterating the design of the service and the backlog driven by regular research. This is built into the team’s planning which is great to see, they continuously monitor user needs, pain points and quotes as part of every sprint
- the team have done a variety of research and alternate their methodology as is appropriate to what aspects of the service they’re looking at. The team also have a plan to go into public beta which covers a variety of research methods, as well as participants who might need assisted digital support
- the whole team is involved in research and seem to enjoy the theatre of going to the lab to see people use the service. This is really great and the team should continue to take part in research as much as possible.
What the team needs to explore
Before their next assessment, the team needs to:
- give a bit more focus to their research questions. The backlog is correctly being driven by what’s in research, but there are a few examples of where they might be optimising pages rather than solving user problems. Writing research questions and hypotheses could be a good way of focusing the research on solving the user problem. These questions/hypotheses shouldn’t look at a page-level, but at a problem level
- do more research looking at how other journeys intersect with the one they’re developing. One important aspect of this is how assisted digital might work alongside this. An important part of understanding assisted digital is about understanding why a user might be or feel excluded from an online service. People might have low digital confidence, or just be mistrustful of using online services. Another aspect of this is looking at the end to end journey and identifying where the different journeys intersect and why - for example, do people who are claiming multiple expenses use this service and the other service (or not bother to claim the other expenses) because it’s easier. The public beta should give the team more opportunity to explore this
- link user needs and research questions to KPIs. For example, currently in the performance framework the team showed the user need ‘I need to know how much I can claim’ doesn’t appear to be measured by any of the metrics (unless they’re very proxy measures) and the metric ‘top industry list choices’ doesn’t appear to map to any objective or user need. If the team have a broader understanding of the user problem they’re solving for users and link this to their KPIs then looking to understand how well the service is meeting those needs can drive future research. GDS can put the service team in touch with a performance analyst who can work with the team to improve their performance framework.
3. Have a multidisciplinary team
Decision
The team met point 3 of the Standard.
What the team has done well
The panel was impressed that:
- the team are nearly 80% civil servants so have excelled in building digital capability
- civil servant roles include, an empowered and very knowledgeable product owner, business analyst, scrum master, four apprentice developers and a Service Manager which is to be commended as building digital capability within a department at this scale is very rare. Other roles include designers, user researcher, performance analyst, dev and test and dev ops. The team believe they have a full complement of staff and this will not change as they move into public beta
- the team are co located in Newcastle and work closely with non digital elements of the service such as the Service Desk. The Service Desk Team (first tier support) sit two desks away from the service team, which will prove invaluable when the team enter public beta. This will ensure that live feedback and problems can be fed to the service team directly and minimise the resolution time.
What the team needs to explore
Before their next assessment, the team needs to:
- try to embed the policy staff into the service delivery team more. There is a danger that if the service team do not change the dynamic to incorporate policy staff and thinking early, a ‘them and us culture’ could develop. It is also imperative that Policy makers should be exposed to user needs to help inform policy decisions
- manage the dependencies. The digital journey has a number of functions which are not directly owned by the service team: the eligibility checker (although this has just come under the team’s ownership), Government Gateway sign on, and the address checker. As these are not owned by the service team and in their control, they should ensure that a representative from the dependant services is working alongside the service to ensure user research, testing and feedback from the public beta can be shared, to improve the whole digital journey.
4. Use agile methods
Decision
The team met point 4 of the Standard.
What the team has done well
The panel was impressed that:
- the team are working in 2 weekly sprints, daily stand ups, retrospectives and sprint planning. The whole team is involved in discussions about the priorities but ultimately the final call on priorities are down to the Product Owner and Service Manager, but informed by user research and policy imperatives
- the service team have a good understanding of their users needs. All of the team attend user research sessions including the technical disciplines which again is to be commended. There is a good rhythm to the sprints from user needs, test to development and the team demonstrated many iterations of the product which shows the team can respond to changing user needs and policy changes quickly
- the show and tells are well attended and are regularly attended by the board which are predominantly the policy team.
What the team needs to explore
Before their next assessment, the team needs to:
- understand the full user journey including pulling in elements of the user journey that sit outside of the team’s direct control
- iterate the products in their control with minimal intervention from CABs as they have already gone into production. The team are already doing this but must ensure that this remains the case so the team can make quick changes to the product in public beta.
5. Iterate and improve frequently
Decision
The team met point 5 of the Standard.
What the team has done well
The panel was impressed that:
- the team have a good understanding of user needs across the entire journey and demonstrated that they have iterated the journey frequently. The team have 50 plus different radio screens to cater for the needs of users however a typical user will only need 6
- the team report into a governance board that empower the team to develop functionality based on user needs. However the team must talk to the board if there are changes to the journeys. The team needs to ensure that there is an avoidance of asking permission from the board as this will become a blocker and impediment to fluid iterations of the product
- the team now own the eligibility checker component of the service and can now make changes to that without any approvals. This is very good and will help improve the tool, informed by user needs.
What the team needs to explore
Before their next assessment, the team needs to:
- include policy representatives in stand ups and show and tells or ideally embed policy people into the service development team. This is a cultural change that GDS can help with
- understand how the wider journey and content works alongside the transaction. There is content on GOV.UK that relates to employees that the team should explore linking to
- improve the eligibility checker to incorporate changes that are informed by testing and user needs (now that the team have ownership). This will create a sound end to end journey for the users
- test the assisted digital triage model in public beta. The team needs to test that users do indeed get assisted digital help where needed and if there is a problem rectify it before the team enter into the live running of the service.
6. Evaluate tools and systems
Decision
The team met point 6 of the Standard.
What the team has done well
The panel was impressed that:
- the team is moving to a more maintainable and flexible microservices architecture and away from the previous iForm solution
- the team is using existing back-end services and extending them to fit their user needs
- the team are using HMRC standard toolsets and languages which should ensure long term support whilst having some freedom to deviate from the standard libraries where it made sense.
7. Understand security and privacy issues
Decision
The team met point 7 of the Standard.
What the team has done well
The panel was impressed that:
- the team are using best practice approaches to infrastructure security and maintaining the privacy of user data.
8. Make all new source code open
Decision
The team met point 8 of the Standard.
What the team has done well
The panel was impressed that:
- the code is available at https://github.com/hmrc/employee-expenses-frontend.
9. Use open standards and common platforms
Decision
The team met point 9 of the Standard.
What the team has done well
The panel was impressed that:
- the team are using open standards and common platforms available to HMRC teams and gov.uk front-end systems.
10. Test the end-to-end service
Decision
The team met point 10 of the Standard.
What the team has done well
The panel was impressed that:
- the team has tested the MVP system end to end.
What the team needs to explore
Before their next assessment, the team needs to:
- whilst end to end testing exists for the MVP, there are a number of challenges to be met beyond the MVP and these will require significant changes that should be thoroughly tested.
11. Make a plan for being offline
Decision
The team met point 11 of the Standard.
What the team has done well
The panel was impressed that:
- the team has a plan for handling offline scenarios of this service via the preexisting iForms version plus paper form back ups.
12: Make sure users succeed first time
Decision
The team met point 12 of the Standard.
What the team has done well
The panel was impressed that:
- the team has done detailed iteration on the framing of questions to increase success rates for users answering each question correctly, for example 94% of users they have tested with were able to select the correct industry
- the team have reviewed and tested iterations to the letter and will make recommendations to NPS (National Insurance and PAYE Service) on improving it
- call advisors have been given information about the service so they can guide users through online, or take the application over the phone.
What the team needs to explore
Before their next assessment, the team needs to:
- look at the full end-to-end journey (to the point where users are receiving the tax relief they have applied for) and consider what success means in this context - in other words, success means all users who are eligible are receiving the tax relief they are entitled to and understand that this has happened. Currently the team are unable to measure whether users of their form actually achieve the outcome they are hoping to achieve because they don’t own the next step in the process - the letter from NPS.
- from the MVP, to begin to widen the scope of their service to cater for the whole user group and full end-to-end user journey. The team now have ownership of the eligibility checker which means they can continue to expand the scope of their design work, and tie together more of the end-to-end journey. In general the team should push for collaboration with other teams across HMRC who own other bits of the user journey, such as NPS
- the team should also explore the long tail journey of this claim, for example so that users update their claim details when they change jobs
- the team should further explore the support/assisted digital channel and how this can support users who get stuck at points in the online form (the team have already said this is something they are looking to do). Something to consider is simulating this call experience in the lab using call advisors, which would allow them to try different approaches to how this support is delivered
- we recommend that HMRC as a whole needs to join up better to allow easier iteration of these common elements of the user’s journeys (such as letters, or updating address details).
13. Make the user experience consistent with GOV.UK
Decision
The team met point 13 of the Standard.
What the team has done well
The panel was impressed that:
- the design is consistent with GOV.UK’s design patterns
- the team has done an accessibility audit and addressed the majority of issues
- the team have considered many options for raising awareness for the service.
What the team needs to explore
Before their next assessment, the team needs to:
- the team suggested they would like to make recommendations about changing the “Check your answers” pattern, but the root cause of the pattern issue seems to be that users are unable to change their address within the service itself. If they can’t allow users to update their address through this service, another approach to try is looking at the flow of questions and at what point they ask about the employer and address. The current flow is confusing, and leads to a misleading “check your answers” page. One option could be for the address and employer playback to come after the “check your answers” page in the context of “what happens next”
- more broadly, the team should consider how this service sits in the context of the wider user need and the journeys they might be taking on GOV.UK. The team needs to look at related activities around starting a new job. For example, from the employee and employer side, or perhaps there is some sector specific content they could join up with. The team could also consider how their service fits within the content currently linked to in the Employ someone: step by step. This step by step navigation was put together by the “Employing people” service community
- follow the recommendations set out in the content review.
14. Encourage everyone to use the digital service
Decision
The team met point 14 of the Standard.
What the team has done well
The panel was impressed that:
- the team have a roll out strategy and intend to onboard users in public beta
- plans are in place to use campaign channels to make employees aware of the fact that they can claim and linking in with money savings experts was planned
- the expectation is that there is a potential user base of 400,000 users.
What the team needs to explore
Before their next assessment, the team needs to:
- as mentioned before, the team need to explore additional routes into the service. A great deal of information already exists on GOV.UK which is targeted at employees meaning there is an opportunity to reference the service in that content
- the team have been triaging live users from the existing journey onto the new journey during private Beta. However there are multiple things an individual can claim expenses for other than laundering uniforms. It would be good for the team to do more work in public Beta to understand when the other expense claims could be incorporated into the transaction. To turn off those other expense claim transactions would then force users to use the new transaction.
15. Collect performance data
Decision
The team met point 15 of theStandard.
What the team has done well
The panel was impressed that:
- the team have implemented Google Analytics (through Google Tag Manager), and are capturing detail beyond page-level. For example, they are capturing events such as when checkboxes are selected, which will allow them to see how often users change their answers which may indicate a question is unclear.
What the team needs to explore
Before their next assessment, the team needs to:
- explore whether they can measure the success of the service against policy objectives, such as the proportion of employees who are eligible to claim tax relief for uniform who are doing so. The team does not currently have an estimate of the total number of employees who are eligible, so it is not possible to make an assessment of the proportion of these who are claiming
- ensure any marketing undertaken utilises utm tracking codes, so the source of visits can be identified when they are driven by marketing activity. This will allow them to assess the effectiveness of different marketing activities in terms of driving users to the service, and driving users who complete the transaction to the service. This information can be used to improve the effectiveness and value for money of any marketing activity
- ensure they are assessing the correctness of information submitted against reliable data. For example, whether the industry a user says they are employed in is correct should be assessed against employment information.
16. Identify performance indicators
Decision
The team met point 16 of theStandard.
What the team has done well
The panel was impressed that:
- the team have identified some KPIs in addition to the mandatory ones.
What the team needs to explore
Before their next assessment, the team needs to:
-
develop KPIs that cover the whole service rather than solely the online element. For example:
- what volume of claims would mean the service is a success - the team needs to develop an estimate of the number of employees eligible for tax relief for uniform, and work with policy colleagues to develop a KPI to measure whether take-up is sufficient
- costs of delivering the service. For example, phone calls to enquire, claim or chase progress are costly. If marketing activity increases the volume of calls this may increase the cost of the service, and require action to reduce the volume of calls, for example by adjusting marketing, or other channel shift activities
-
reducing the number/proportion of claims that are submitted via handling agencies was mentioned as a goal. A KPI should be developed around this, particularly as these companies tend to submit claims by post which is a more costly channel than digital.
- the team should also develop measures around correctness of information submitted. The claim process does not involve much verification of details such as whether the industry the user says they work in is correct. Without being able to measure whether the service is gathering accurate information it is not possible to assess the level of incorrect claims are submitted and take action to reduce this. Correctness should be measured by reference to employment records held by HMRC as far as possible, rather than relying on user research. It might be possible to do some verification manually, to check a sample of cases at regular intervals to measure the performance of this part of the data to ensure its gathering the correct information.
17. Report performance data on the Performance Platform
Decision
The team met point 17 of the Standard.
What the team has done well
The panel was impressed that:
- the team have worked towards publishing the data from the service but have had to seek approval due to some sensitivities. The team are working appropriately to get that approval.
What the team needs to explore
Before their next assessment, the team needs to:
- talk to the Performance Platform Team for GOV.UK once they get the approval during public beta to ensure they are publishing data from the service.
18. Test with the minister
Decision
The team met point 18 of the Standard.
What the team has done well
The panel was impressed that:
- the team has tested the service with their SRO who also provided feedback to ensure that the service is also meeting the policy intent. These comments were fed back to the Treasury to make them aware of the changes that are being made.
- the SRO has been involved with the project since the beginning of discovery, attending most show and tells and also attending user research to see how the service is performing.
What the team needs to explore
Before their next assessment, the team needs to:
- test with the minister before coming for their live assessment.
Updates to this page
Published 5 August 2019