Chasing money, misplacing account details, chasing again; it’s fair to say that paying back friends and family can be a bit of a minefield. We built our new feature Settle Up to make it a little more straightforward – and a whole lot quicker. No need for sort code swapping, or awkward chasing messages, no double checking details – with just a few taps, a single link, and you’re all settled up.
In pushing ourselves to create the best current account possible, we’re constantly opening up our engineering team to a range of challenges which the finance industry hasn’t faced before – particularly with respect to how we build truly seamless experiences with money. To do that, we’ve left outdated team structures in the past and allowed our engineers to manage projects – from planning and prototyping, right through to execution.
So why does Settle Up need a website?
The website exists so that you can request money from any of your friends, regardless of whether they have a Starling account or not by sending them a personal Settle Up link. If they have an account with us, the link you share with them will open in the Starling app and allow them to pay you back in just three taps. If they are not a Starling customer (yet) or aren’t on their mobile, the link will open our Settle Up website in the browser. So wherever they are, your friends can pay you back seamlessly on any platform or device – whether they’re a Starling customer or not.
How did you approach it?
I had plenty of autonomy over the building of the Settle Up website, whilst working alongside Product and Compliance. While there were certain key requirements requested by our Product Managers, and designs from our Web Designer, it was my responsibility to review and select technologies that fulfilled these requirements, in particular the responsive and user experience design.
Once you’d settled on the tech needed, how did you go about building the Settle Up website?
I initially joined the project back in mid-December 2017 and spent the first two weeks of engineering time exploring the various methods, and weighing up how I would approach the build. I find the best way to do this is to jump right in and build some prototypes. I then have something to play with, giving me a clearer view of the objectives and how they might be achieved.
The initial implementation used a technique called server-side rendering, where the final page content is delivered directly to the browser. The alternative is client-side rendering, where the browser receives all the pieces but has to do some assembly before they can be displayed.
For our use-case, server-side rendering didn’t give the best user experience. The main issue with the technique is that every user interaction, like clicking a button, required a round trip to the server to get new content, resulting in a full-page reload. This meant that every interaction left you waiting for far too long and was not a good user experience.
However, with the client-rendered prototype, everything that is needed to use and navigate the site is delivered as you land on the first page. This approach gave near-instant UI interactions at the cost of slightly longer initial load times. This was also important as we know many people would be visiting the page on mobile devices and using a mobile device – so it had to be quick and responsively designed.