One of the rewarding aspects of developing new services is seeing our internal capability grow. It’s one of our main principles in DVLA.
Developing our capabilities is allowing us to build a unique culture which is digital by default, confident and focused on you, our customers. It also means we can continue to build excellent services.
To do this we’ve been working together with customers, local businesses, suppliers, and universities to help design and develop our digital services. Our online penalty payment service, currently in private beta, is one example.
Using our skills and capabilities
Understanding our current skills and capability lets us draw on the talents of individuals within our digital talent pool. We’ve been developing our staff with the skills they need to take on challenges we’ll face in the future.
Dan, our UX trainee, is relishing the experience and his blog gave you an insight into how he’s using the skills he’s learned to develop prototypes on related services like our tax your vehicle service.
Our pay a vehicle penalty team
In the last few months we’ve started to welcome new people into our team. People like Mike Dawson and Suzanne Godrich who are software and solution developers.
Here’s what Mike had to say...
Suzanne and I were given our first user stories to work on. They were small, simple changes to help us become familiar with the software and processes needed to release a change. My change needed an email type keyboard to be provided to customers who use a mobile device when entering email addresses.
Sounds simple? Think again. My first guess at the change necessary was to simply change HTML input tag types to ‘email’ in the relevant form fields. I followed the project’s development workflow guide, made my change, tested and submitted it for review.
The review highlighted that default browser error messages could be displayed, when we already had routines to do this. I spoke with developers on the team, made the change (to add ‘novalidate’) which was accepted and moved ready to test in preview. After setting up this change, I tested my local changes using a smartphone on a private network.
This helped me understand how to identify changes scoped into a sprint, and where they are in the process. I also now know how to get a change coded and reviewed by my colleagues. Because it was only a HTML change I didn’t need to create a unit test or document the change. I expect a more involved change would have needed more testing.
I’m looking forward to my next piece of work.
As Mike has illustrated, we’re continuing the process of building our team and developing our capabilities to maintain the new payment service into public beta and into the future.
Building our digital capability will ensure more people than ever continue to use our digital services. Keep an eye out for future updates.