Design and Development Decisions for a Pension Calculator

Design

At retirement, members of GUS — the (Isle of Man) Government Unified Scheme — are entitled to take a portion of their pension in a ‘lump sum’ (sometimes known as a commutation). When the scheme came into effect in 2012 an online calculator was built as part of a new website for the scheme. At the end of this month the website is due to be decommissioned, meaning a new lump sum calculator is required.

Dev team trainees Jon and I were tasked with the design and development of a replacement calculator. Tooled only with a loose set of requirements in the form of an excel spreadsheet, the original calculator and a very hazy understanding of the pension scheme we set to work.

First off, we carried out some pretty basic user-testing with the existing Lump Sum (LS) calculator ourselves. Self testing is certainly less than ideal but we had limited resources and anyway, with our hazy understanding at this point we probably made for ideal candidates. Some things became very clear, others less so…

Ok, we see it’s fairly straightforward unless you’re in section 7. So what do the sections refer to? What is a commutation factor? A little read through the Member’s Guide tells us which section means what and the a commutation factor is a factor used in calculating your lump sum amount.

Time to look at the spreadsheet, here’s a little something we found:

=IF(C8<>7,H19,IF(AND(C8=7,C9=”No”,C11>54),H19,IF(AND(C8=7,C9=”No”,C11<55),O14,AD27)))

yikes…

or when written in a language we can understand:

if (section != 7 || (section == 7 && protected == False && Age > 54)) {
return 18;
}
else if(section == 7 && protected == false && Age < 54 ) {
return CommutationFactorForANonProtectedSection7Member()
}
else {
return CommutationFactorForAProtectedSection7Member()
}

So it turns out section 7 is unique as we suspected, all other sections having a factor of 18 — something to factor into the design. Additionally at this point we went about writing out the calculations needed for the calculator in code.

Jon and I spoke about some design decisions before moving forward. From our experimentation with the existing calculator, it was clear we were not working on a complete redesign. Some design choices we noted to be beneficial to the user included:

• A regular F shape of the content in line with well-understood research about user gaze over a screen.
• Progressive disclosure of information by only displaying extra form elements for section 7.
• Displaying the result in a graph to offer the user a friendly visual presentation of the data as well as a data table for a more detailed look.
• A concise minimum viable product that seeks to solve one problem only.

Nonetheless there were improvements that could be made. But before moving on, it is important to note: The calculator is just a calculator — no data is being posted up to a server and therefore all calculations are being made client-side. Additionally, (even when used whilst signed in) anything that is calculated is lost when closing or refreshing the page. As a result, the functionality of the calculator would be written in JavaScript making for a smooth, fast and cross-browser friendly service. With this in mind we identified a few ways in which we could improve on the current design:

Smoothen the user experience further by keeping all controls on a single screen allowing the user to change any of their input data and see updated results instantly.

• Reduce pension specific jargon (commutation, section etc).
• Improve and modernise some UI controls in line with current user experience research.
• Ensure a mobile friendly design that would be functional on a range of screen sizes.
• Most importantly the styling and UI controls needed to fit within the gov.im online services framework

Mindful of these improvements we went away to sketch some ideas before reconvening to compare and compile our work. After a few rounds of sketching and comparing we made some paper prototypes for both desktop and mobile versions and set to work testing on colleagues (GUS members).

The process encourages users to behave as though they were interacting with a final digital product, using their fingers in place of a keyboard and mouse allowing the test operator to observe the potential problems with their design. It was beneficial to our process primarily because it outlined problems we hadn’t fully anticipated, most notably that no one was fully aware of which section they were a member of — it was clear that we needed to find a way to reduce the amount of department specific jargon to allow the the greatest possible number of users to comfortably use the service.

Finally, some reworking of the UI controls was needed. Certain things about the current LS calculator stuck out. Consider this:

It may feel like a strange question to the average user (at least, until you read the Member’s Guide) but to offer the user only the option of ticking a box is what’s troubling here. To an experienced web user, it’s clear how we’re expected to answer this but to many it would be unclear. How about offering you user a conscious choice between yes and no? Having to make a clear positive action to submit their decision helps the user understand what they’re really saying. Here’s what we came up with:

Finally we felt it was important to move the calculator to a single interface. This would allow the user to use the slider or number input method without having to move to another page and see the results live update as they changed their input.

Development

okay…

TDD

This project marked the first time we used TDD on a front-end language. Whilst TDD may add some extra production time, there are a number of advantages to working in this way. In our case the greatest advantage was seen in ensuring our calculations, transposed from the excel spreadsheet were done so correctly long before we had to write any of the other code. As our calculations were written in JavaScript, we chose QUnit as our testing framework, which prints out your test results on a html page (<) — works like a charm.

Technologies

Developing for the Gov.im Online Services framework, we needed to provide a .NET service wrapper (implemented using MVC) around our project in order to integrate with the rest of the site. This gave us access to HTML helper methods for rendering parts of the form, common stylesheets and access to jQuery without worrying about loading it in ourselves. And as discussed above, we had settled on JS early in the process to handle our forms, calculations and data display. We had previously nothing on Online Services displaying data in a chart, so before we went any further we did some research on a framework to best do this. Chart.js was a clear winner, fitting all of our requirements: responsive, lightweight, highly customisable. It’s also nice and easy to pass in data from calculations, and animated which leads to some pretty smooth updating when input data is changed. Additionally Rangeslider.js was used to bring slider support to IE9.

Implementation

The calculator project was the first of it’s kind for our team and with it came a number of learning opportunities. For Jon and I it also came as an introduction to the realities of development in the public sector; unfortunately the pensions department kicked back against our proposed changes to the section dropdown and wording despite our research and design process. We were able to compromise and move the calculator to a single page view but we knew we had to focus our efforts on enhancing the usability on a micro interaction scale as well. Here’s some of what we came up with:

One of the challenges we faced was how to make the calculator feel as much like an interactive tool as possible. The requirement of form inputs meant we needed to find a way to allow the user to recalculate/update the results when any value is changed. A submit button would require an extra click every time the user wanted to see how their changes affected the results. So we decided to do away with it completely. Instead we wrote a small script to wait for the user to stop typing in any trigger an update once they have. If the user keeps typing, the timer keeps waiting…

Additionally we were able to perform input validation once the user has completed what they’re typing without requiring an extra click or displaying annoying error messages on each keystroke. Small victories!

Finally

Utilising UX practices and test driving our code didn’t make for a quick an easy project, it lengthened the working time significantly and threw us a number of unforeseen issues but I feel strongly that we have made a better tool for our users and more maintainable code for ourselves going forward. As designers and developers we have a responsibility to deliver a usable and maintainable product but we also have a (sometimes conflicting) responsibility to simply deliver. The LS calculator is not perfect, neither in code nor design, but we approached it with a view of building the best we could with what we had and we’re pretty happy with how it turned out.

The Lump Sum Calculator is now live and available to use here.

— Benjamin Jones, Trainee Enterprise Application Developer