The Planning team had a new service going live within a tight deadline. They were trying to make it easier for customers to make payments. This might even reduce their workload. Planning was already up against it in terms of work and really didn’t need any extra admin.
The ICT team were already really overstretched, and the Digital First programme developers were tied up on another similar project. So we decided to build the form alongside another, which had similar requirements and which already had development time allocated.
What went right
This was a good example of identifying and developing a Minimum Viable Product (MVP) quickly, working closely with a service.
Planning also praised our agile way of reacting and willingness to help. This will give our digital development team a good reputation and, I hope, open doors with services across the organisation.
On the actual development side, we’ve developed a new way of paying that keeps customers within an online application form. This is great because going outside the form results in a pretty mediocre experience. The new way is slick, easy to use and has been adopted with great delight by the Registrar team. We hope now that other services will want to use it.
Learning from what went wrong
One thing we learnt the hard way is we that we have to hold our ground and insist on discovery work, even facing high pressure deadlines.
By doing the discovery work it’s likely we would have avoided the outcome when Planning’s form went live.
At the start, we all thought fast payment would help Planning and would be something all customers would want. Right?
Well, that’s not how it happened.
Once we put it live, we only had one payment via the form.
This particular group of customers are normally businesses paying very large sums. They don’t want to do this by card. Card charges are too high on large amounts.
This was not anticipated before. The development team assumed that easy online payment would be simplest and quickest for everyone.
Most customers still want to pay by invoice.
So Planning didn’t avoid the extra admin either.
Putting user needs first
The Planning team were kind to us with their feedback. They said: “Your team did your bit brilliantly, but I guess it is hard to ignore the most used avenues of payment.”
We don’t think we did do that brilliantly. We built the form brilliantly, but there’s no point in building something brilliant if customers don’t want to use it.
No matter the time pressure, we should have asked the customer! User needs come first, and you need to know those needs to put them first. We’ve got to be expert at guiding staff on the importance of this.
First thing, before anything else, is to always ask the user!
We have the feedback from customers now and we know that they would use BACS in the form if available. Hopefully we can add this when we upgrade our payment system in the future. After more discovery work, that is.
This is a tough lesson learned, but one we can use as an example. When pressure from managers to deliver is high, we can use this example to show that good discovery will save time and money in the long run.