MAS Annuities Comparison

Rob Money Advice Service

The Organisation Money Advice Service / FSA

[eb_page_meta]The Money Advice Service was set up by government to provide free impartial advice to the British public. Its board members include representatives from the Financial Services Authority, the Association of British Insurers as well as various political representatives. The site as a whole receives 200,000+ unique visits per week from the UK general public in relation to all possible life events.

The brief [eb_page_title]

Make annuities great!

MAS already had an existing site for the Annuities Comparison Table. A legacy application that dated back to the FSA 2 years prior to the creation of the Money Advice Service. The tables were the defacto goto place for annuities calculations and comparison by FAs (financial advisors) and IFAs (independant FAs) alike and are still often referred to as the FSA Annuity Comparison Tables.

The complication

Nothing like this had been created before.  All previous comparison tables were based purely on profit margins. But these were the only models that existed: people knew about them, thought they understood them and therefore trusted them to give the best deal. The trouble was – they didn’t.

You could be eligible for a 40% increase due to your health and

Not exactly intuitive..!  This meant challenging the existing cognitive biases associated with current financial products available and the organisations that sold them.  We were playing on their home ground, but now we had an understanding of what we were up against, and better still, a plan.  Where they zigged, our best option was to zag.

The key to success then was focussing on educating the customer, so that their understanding took precedence over the “sale”. The primary aim wasn’t to sell, but to lift the skirt on annuities to show its dirty laundry and, by doing this, give the customer more control.

 The preparation

Heuristic Eval

Heuristic evaluations were loosely conducted on the current system to understand the manner in which questions were being asked, the guidance (if any) that was being offered to aid in answering and if the method of answering given to the user was appropriate to the question.

And the results are in …

What we found, at best, could be labelled “dry”; the end-user was essentially flying blind. The terminology used in what guidance there was often required additional guidance from someone with a background in financial services, the method of asking questions was often too specific for its end state purpose and the users were unable to understand the impact of any of there choices until they had completed the full journey.  This often lead to the user in a more confused state that when they began the exercise and went against the overriding objective of the tool in the first place.

Questions, issues and KWAs

[Rob] was quick to mock up possible changes on the fly, allowing decisions to be reached more quickly. His breadth of knowledge has helped to explore a variety of ways to communicate complicated messages to consumers.Nick Hill, Proposition & Product Development Manager at Money Advice Service

An list of questions and issues was drawn up and mapped to Key Working Assumptions (KWA). These were then broken down into the following categories:

  • Proposition, Scope and Audience
  • MAS Stance
  • Tools/Content Flow

From this viewpoint, we were then able to construct a decision tree that would form the basis of a journey flow diagram specific to each use-case.

(A tiny bit of) Guerrilla Testing

We wanted to test if the question was contextually understandable, and if the type of answer given was robust enough to satisfy further scrutiny by the user.

Information Architecture

We wanted to know if the given response by the end user mapped accurately to the input requirements of the API’s (or if an additional middleware parsing routine was being used to ‘adjust’ the user inputted results into a pattern usable by the back end software)

Working with SMEs, the outsourced dev agency and existing understanding (based on the previous tables) gave us a good breakdown of available data provider returns that allowed us to rapidly redress the existing information architecture (IA) into something that would be of a greater benefit to end users.

Journey Mapping

To speed up the group understanding and gain quicker senior level buy in, the individual epics were mapped and each user story was marked on the map. Vertically displayed underneath were the associated user journeys, fragmented into their PBIs (Product backlog Items), these were loosely prioritised into releases aligned with the expected availability of the back-end APIs.


The prototype was built up during the sprint cycles with each iteration concentrating solely on small functional iterations, after which the prototype was tested for user feedback and results being incorporated as PBIs into either the sprint or product backlog as necessary.

view prototype

device_tablet device_pc

Wireframes and Functional Specifications

Due to several factors surrounding this project, it could not be conducted in an agile manner, instead a dirty hybrid of iterating through journey flows and designs in an agile manner based on scope and functional acceptance criteria followed by a round of document creation. This resulted in some quite heavy functional specification documents being created.

 The results

Product Visual

Application entrance screen

Annuities Start Screen

Product Visual

Tax Free Choices

Annuities Start Screen

Product Visual


Annuities Start Screen