Category: Defects

Defect category covers bug fixing. Defects arise from unit testing, component integration testing, system integration testing, user acceptance testing or from live operation.

  • Yorkshire Building Society Design Failings – part 2

    Yorkshire Building Society Design Failings – part 2

    YBS screen showing session expired and data lost.
    YBS Session Expired – Data Lost

    Here at Storycase we’ve been involved in digital transformation programmes for both the private and public sector. Working with several of industry’s best architects and designers we understand what’s needed to deliver a service that meets the customer’s needs without costing the earth.

    With this lens we’re posting a series of articles to highlight failings we’ve found while using digital services. The intention is to name and shame – not maliciously but to put pressure on organisations to change the way they operate – and to deliver services that work.

    As bank and building society branches close we’ve come to rely on online services and mobile apps for our daily financial transactions. When these do not work as expected we justifiably get annoyed and the stress levels in our daily lives are raised. So what went wrong at YBS when trying to open a joint account and what lessons can we learn?

    Yorkshire Building Society – YBS Joint Account Opening Problems

    As mentioned in our previous post Yorkshire Building Society Design Failings – with increasing inflation rate here in the UK, like many customers with some cash savings we need to open a new YBS account to get a better interest rate. YBS fail to pass on bank base rate increases to existing savers while immediately hiking mortgage rates. Building societies create new account variants that pay a higher interest and fail to pass on rate hikes on older accounts penalising existing customers who fail to act.

    So after less than a year of opening an account we must apply for a new account to chase top rates. It sounds easy – just apply online today! No it’s not that easy at all and here’s why.

    The use case we need is to open a joint account and that’s not been considered a minimum viable product by YBS. While the online form does indeed provide a joint account option, selecting it takes the user down a rabbit hole.

    The form blindly asks for the full details of the joint account holder including a password but does not explain why. And entering all these superfluous details takes time that’s not been allowed so the online session can time out when the customer clicks submit.

    Adding a simple question – Does the joint account holder already have an online account? and if so entry of a username would avoid confusion. But no, the first account holder – they must have an online account in order to apply – is forced to type in the joint holder’s full name, phone numbers, email addresses and passwords that are all unnecessary and so infringe GDPR.

    Bad service design

    Of course the simplest way for existing joint account holders to open a new variant of an existing account eg from a Saver Plus Issue 12 to Saver Plus Issue 13 is to offer an upgrade on the existing account. This enables all account holder to be pre-filled but would be too easy and defeats the real object in YBS creating the new issue in the first place.

    Faced with YBS’s joint account opening form the customer has two options. Neither are good. The first option is to enter the second account holders details including passwords to match the online account that already exists. The second is to give up with opening a joint account and apply to add a second account holder later – which can only be done via post.

    If the second account holder does not have an online account the current form makes more sense but the password should only be set up by the second user at first login to avoid security issues.

    Adding a second account holder is not an online option even for an online only savings account so a paper form must be posted out and returned. With severe postal delays due to Royal Mail strikes and staff shortages here in the UK customers want to avoid post.

    Both journeys will time out if the user does not enter all the information within an unspecified time period or the session will timeout without warning. Clearly no user research or UX has shaped these journeys – I wonder why?

    Clearly it is not in YBS’s financial interest to improve the account opening journey for existing savers – it’s why they created the new account variant in the first place. We complained about the joint account opening experience when it happened a year ago and nothing’s been done. The user journey is still broken.

    Can it get any worse?

    Well, yes it can. After calling YBS customer services and being advised to clear cookies or try another browser and try again (we did neither) we persisted with the joint account user journey.

    Initially it looked successful – the account was opened with an email to both account holders. But the joint account was not visible to the second account holder despite the registration email stating it would be activated overnight.

    It took a further phone call to learn that YBS systems can take up to ten days to merge details and a temporary customer number would be posted out in the meantime. No mention of this online or in the email. Again, the user journey has not been considered.

    Design Failing Summary

    • Account opening form times out without warning – all data entered is lost and customer has to restart the journey.
    • Joint account holder credentials – first applicant forced to enter second account holder’s password
    • No option to use an existing joint account details to open a new account – this would avoid needless data entry.

    Come on YBS – fix your poor online service design or better still, stop the bad practice of spawning new account variants to penalise existing savers.

  • Yorkshire Building Society Design Failings

    Yorkshire Building Society Design Failings

    Here at Storycase we’ve been involved in digital transformation programmes for both the private and public sector. Working with several of industry’s best architects and designers we understand what’s needed to deliver a service that meets the customer’s needs without costing the earth.

    With this lens we’re posting a series of articles to highlight failings we’ve found while using digital services. The intention is to name and shame – not maliciously but to put pressure on organisations to change the way they operate – and to deliver services that work.

    Yorkshire Building Society – YBS Internal Transfer Problems

    As bank and building society branches close we’ve come to rely on apps for our daily financial transactions. When apps do not work as expected we justifiably get annoyed and the stress levels in our daily lives are raised. So what went wrong at YBS and their app?

    With increasing inflation rate here in the UK, like many customers with some cash savings we need to move money between accounts and providers seeking best interest rates. Larger banks and some building societies notoriously delay or fail to pass on bank base rate increases to savers while immediately hiking mortgage rates. Building societies create new account variants that pay higher interest and fail to pass on rate hikes on older accounts penalising existing customers who fail to act.

    Profit’s lie in the difference between deposits they receive from customers and the money providers lend so it’s no surprise that their savings accounts and business processes are designed to maximise profits.

    Customers need to open new accounts chasing the best rates and move funds from one account to another. So there’s an incentive for providers to make it difficult to do this and let fiscal drag increase revenue.

    My use case with YBS was to simply transfer funds from a savings account to another savings provider. We may well close the accounts if the issues highlighted are not addressed but that’s another story.

    Step 1 – transfer between internal accounts

    Each new account needs a separate third-party payee set up if you want to transfer funds out. This involves managing payees and entering the external account name and details but needs verifying with a small amount before sending larger sums so we’d not done this on the new account. As we had already set up the correct payee for an older account, where the rates had plummeted, we needed to do an internal transfer between accounts.

    When the YBS app starts up it shows the balance on each account so it’s easy to see which account has the funds that need moving.

    I begin by using the app to transfer funds internally from account A to account B. Using Transfers this is easy as the internal accounts show up when selecting the destination.

    Step 2 – return to view account balances

    On confirmation the app returns to the home screen and the balance for account A has decreased as expected but the balance for account B did not increase. When I click to view account B details the transfer transaction is not shown. Where has the money gone?

    So I try closing the app and login again – I’m thinking maybe it’s poor design and a restart will refresh the account details. Still the home screen account balances don’t reflect the transfer between accounts – the money I transferred appears to have vanished. Clicking into account B the credit transaction does now show along with the revised account balance but it’s different to the balance on the home screen – it’s very confusing. So there is a data caching issue – I had to exit the app for it to refresh the transaction list – but why did the main account balance screen still fail to show the correct values?

    Step 3 – attempt transfer out

    So next I try to make the payment from account B to the external account that’s already set up and verified. I enter the amount and click confirm. I get an error message – There are insufficient funds in the account to make the payment!

    Ouch. So I transfer funds internally and I can’t access the money I’ve just transferred. That’s not a good customer experience. I blocked – is it deliberate?

    When apps or online journeys fail it’s often due to ‘security’ measures that providers have hastily put in place in response to scams and online fraud which has taken over from the bygone bank raid. In my case I don’t suspect it’s a deliberate act by YBS to stop me making the transfer as I see the account balances are incorrect. But I’m wondering why such a common journey has not been fully tested by YBS before releasing the app – after all they’ve had three years in which to get it right.

    Step 4 – call YBS customer services

    I call the support number and wait in a queue listening to distorted music and a voice telling me how YBS are very busy at the moment and it’s faster to carry out things online. I wait patently.

    After ten minutes a real human answers and I explain the problem. They advise me to logout and wait 10 minutes. I explain I’ve done this while I’ve been waiting to speak to someone and am still seeing the message about insufficient funds. Well you will just have to wait longer they advise me again. I ask how long and am told as YBS is a building society their systems don’t work like banks and some accounts can take time for balances to show.

    This raises an eyebrow or two and I ask if they know this why they don’t include a warning in the app to avoid customers panicking and having to call. I ask if they can see the transfer I’ve just made from their system to reassure me. They can and so I ask if they can make the payment instead as we’re set up for telephone banking. They do so successfully with no need to wait. I then ask for a compliant to be logged detailing the scenario.

    Why should the customer be blocked from making a transfer when the funds are clearly present and the transfer can be made using an internal system?

    What really annoyed me about the whole experience with YBS is the attitude to their customers. They know their systems don’t work and have a story to feed customers that obfuscates the truth. There’s no reason for a building society account to behave differently from a bank when moving monies between internal accounts. Clearly external transfers make suffer different constraints but this should not be used as an excuse for poor system design internally.

    There’s no incentive for YBS to improve this experience because it’s literately in their interest to make it hard for customers to access money and move to better accounts.

    To add insult to injury the reason we installed the YBS app was in response to a YBS Money Guide email to highlight the app’s benefits:

    This month the YBS Savings app turns 3! Since we launched it in 2020, the app has continued to grow and develop. We now have over 300,000 registered users who continue to use it, and we are constantly looking to develop and add new features. Making it even easier to access your savings! If you haven’t already checked out our app, look at our guide for getting started.

    YBS Money Guide email

    Easier to access your savings? This means there’s over 300,000 customers that have or will find they can’t make the external payment they need if they follow this user journey. And they will end up calling the support number creating the high call volume. It’s a vicious circle where the customer ends up suffering due to incompetent system design.

    Lessons learned

    I don’t know what architecture YBS use but clearly there are several layers between the master system of record and the cached views surfaced through app, web and customer services deliver channels. I’ve represented an example of how this could occur below.

    System architecture showing the account balance in each layer

    Each layer may well cache the account balance to take the load off the master database and this can lead to the confusing state I experienced. Poor system design appears to have omitted to refresh the cached values after an internal account transfer. So the new account balance is not available for validation when making another transfer. Login out or restarting the app refreshes some cached balances but not all indicating the server side caches could be out of date.

    If I was writing out a ServiceNow ticket to describe the problems I’d mention the discrepancies between what the customer sees and what actually exists in the system of record. The balance should be consistent.

    User needs

    So what are the user needs and how have YBS failed to meet them?

    Here’s a set of user stories that try to capture what the customer wants followed by the business. We’ll let you the reader decide which is right.

    As an online customer
    I want my account balances to reflect my account transactions immediately
    So that I have confidence the actions I perform are obeyed correctly
    So that I don't worry that money has been stolen from my account
    So that I can carry out further actions with my money
    Given a customer has two immediate access savings accounts A and B
    And a transfer amount M is within the limits on the accounts
    When a transfer is made from account A to account B for amount M
    Then the balance for account A is debited by M
    And the balance for account B is credited by M
    Given a customer has transferred amount M from account A to account B successfully
    When a further transfer payment is requested from account B
    Then the current balance is used for account funds validation and not a cached value
    As a financial savings provider
    I want to delay presenting account balances to customers when they make transactions
    So that I can earn maximum interest from customers deposits 
    
    

    We hope we’re wrong and YBS have not deliberately designed funds transfer user journeys to cause friction and stress to its customers. But we’ve experienced similar behaviour from other financial providers that disregard user experience which makes us skeptical of ethical product management. Or maybe it’s the minimum viable product syndrome that plagues some poorly managed agile delivery programmes.

    Postscript

    YBS did respond to our complaint and upheld it, offering compensation for the time wasted. This was a welcome gesture but we did emphasis the only way to resolve this issue is to fix the underlying stale data cache or whatever reason YBS have for implementing this defective system behaviour.

  • NS&I How did service design go so wrong?

    NS&I How did service design go so wrong?

    NS&I Call Us screen with distraught emoji

    Here in the UK we have National Savings and Investments branded as NS&I which provide popular savings products to the public. NS&I raise revenue for the UK Government and in 2020 delivered £11.6 billion of Net Financing.

    So you would think customer service is top on the director’s agenda to ensure smooth running and secure the income stream from its 25m customers. We’re just one of the customers that have become disillusioned with service and if TrustPilot’s NS&I reviews are representative we’re not alone.

    What’s gone wrong at NS&I?

    Simply, it’s very difficult to speak to an NS&I service advisor anymore. Previously customers picked up the phone or walked into post office to buy Premium Bonds, cash ISAs and Index Linked savings products. As business moved online NS&I moved more of their account opening and management online via their website.

    Poorly designed UX

    Like many organisations that have built businesses using efficient call centres, NS&I decided automation is the way forward. When you try to call NS&I now you are greeted with a voice from a virtual assistant that sounds like a real person. Unfortunately they don’t say they are virtual so the unsuspecting customer may be lead down a series of rabbit holes as they think they are speaking to a human.

    Of course generation Z would likely get they are talking with a virtual assistant immediately as they’d seen the website – but granny or grandpa or generation X may take a little longer to twig. When you do manage to convince the bot they are not up to the task and you need to speak to a real human it all goes wrong. You are told they are experiencing a very high call volume and that the wait time is over 60 minutes. Yes, you heard right, not sixteen, sixty. Do you have over an hour to waste?

    Who ever signed off the IVR contract must have been crazy. We can imagine the meeting. “Okay, so with this new IVR we just spent zillions on we can reduce the call centre staff FTE count by 90% right? And we can do that before the end of Q2 just as we roll out the MVP right? So every one agrees, right.

    Wrong. They failed to think through the service design and volumetrics for the key user journeys. And I bet they failed to consider non-functional requirements, security risk assessment and so on. Here’s why.

    Simple fact – over 25m customers are rich pickings for fraudsters. Not all customers will have or want to use online services no matter how much you want them to. NS&I’s loyal customers got used to picking up the phone and talking to helpful call centre staff. When existing customers call they are told how many of their needs can be handled much faster by visiting the website.

    With call wait times over an hour there’s clearly too few staff to service customers. So why do customers call? In our case we’d tried to register for online or phone service and got an error message about a temporary password that had expired and to call the NS&I help desk.

    So you can see the chicken and egg user journey the fine service designers have set up at NS&I. For clarity, here are some scenarios.

    Scenarios

    Scenario A: Existing customer has no online account and calls NS&I and is persuaded to try online

    Customer calls and IVR tells them it’s much faster online. Customer goes online googles NS&I and follows signage to register. Customer starts registration entering account number and is told their temporary password has expired and to call the help desk. Customer is confused as they don’t remember ever having a temporary password. That’s because either someone else has entered their account number or they tried to register some years ago and gave up. Customer calls and IVR asks why they are calling. Customer says they are having trouble with a temporary password. IVR tells them it’s much faster to reset their password online using the forgotten password option. Customer goes online and clicks the forgotten password option. Customer enters their account number and surname and are shown an error telling them to call the technical help desk on the same number they had called earlier. Customer calls and IVR asks them why they called. Customer says they want the help desk and are told its much faster online. Customer getting angry says they want to speak to help desk IVR says okay, what do you want to speak about. Customer just says put me through to help desk and are told they will be put through. IVR tells them the call wait time is 60 minutes and plays musak.

    And so it goes. It’s woeful customer experience.

    Clearly the user journeys don’t fit the user’s needs. Forgotten passwords must be high on the probability and need an automated solution. The call centre queues are being flooded by requests that don’t need human intervention.

    The problem appears to be a dire inability to design user journeys that work. I bet they only considered true customers. How about this one?

    Scenario B: Fraudster steals letter from NS&I to customer about premium bond win.

    Fraudster steals post, opens letter and finds customer’s name, NS&I account number and details of their premium bond winnings and holder’s number. Lucky fraudster. Fraudster goes to NS&I website and clicks Register online. Fraudster enters account number, name and address from letter and is told to expect a temporary password in the post.

    We could go on but leave the scenario to play out in the reader’s imagination – no point in making it any easier for fraudsters.

    One key underlying problem here is how to authenticate customers given there’s no human interaction. NS&I are not alone in introducing two factor authentication as the traditional username and password is too insecure. NS&I still insist on giving customers a user number that few will every remember so have to write it down somewhere. Why not allow users to choose their own user ID such as a user name they can remember? Why not use OAuth? There are many better ways.

  • Defect Thursday

    Defect Thursday

    Calendar showing Defect task for ThursdaysDoes your development team treat defects differently? A few projects ago the sprint teams I worked with decided the best way of burning down the bug list was to allocate at least a day a week (or every two weeks) to defects. There were several sprints running in parallel with a continuous daily build.  The main sprint’s stories took priority so non critical defects built up. Come defect Thursday everyone dropped the new tasks and picked up the bugs.

    Over several weeks the burn-down charts showed progress with reduced defects along with the main stories. With the weekly expectation of having to focus on defects the sprint teams adopted a more ‘relaxed’ approach to bugs. Of course the critical bugs took priority in the daily stack but the medium and low priority defects were left for Thursdays. This allowed more time to think through a better fix. Thursday’s stand-up could home in on areas that needed refactoring to fix the defect and maybe adopt a better strategy for exception handling or tackling the buggy UI component that had been accepted until now.

    Compared to some other approaches to managing the defect list such as daily developer rotation (oh no it’s not my turn) or swot team (the ‘B’ team – always bug fixing) having a fixture in the calendar my work for you too.