Author: R

  • Fraudsters opening BT business accounts

    So there has been much written about online scams and fraud affecting phone companies but little on the customer experience impact. My recent encounter with BT when reporting an incident raises several concerns and highlights a catalogue of UX failures.

    It all started with two near identical letters from BT requesting bank account details to set up direct debits for accounts I’d not ordered. The letters suggested direct debit was the easy way to pay your bill. Trouble is these were not my bills. You would think it’s easy to contact BT and report the fraud. I reached for the phone and dialled 150. The automated voice recognition asked in a few words why I was calling. “To report a fraud” I say. Ok is this the number you want to speak about? it asks. Well no I thought so I key in option 2. Enter the number you want to call about it demanded. Hmmm, the helpful letters don’t mention any phone number, in fact the letters fail to describe any products or services the bill is in connection with. So I just key double hash and join a queue that keeps telling me how important my call is to BT and how they are so very busy at the moment.

    Let’s just think about this journey. I ask to report a fraud and am told okay, I don’t have a phone number I want to talk about and am not given another option other than to hack the system with a double hash. (I remembered one helpful bank telling me this trick and it seems to work).

    I hang on for 7 minutes to be greeted by a real person who wants to know my name and first line of my address and postcode. The guy has no idea why I’m calling so telling the AVR was pointless. So I say I want to report what I suspect is a fraud. I run through the details in the letters and I tell him the account numbers. He puts me on hold, another 5 minutes pass and he says the account is a business account that he does not have access to. He suggests I contact business team and asks if I want to be put through. It’s gone 7pm I say are they still available? Yes, he says and puts me through. After a short delay I hear an automated recording telling me the team are available between 9am and 6pm Monday to Friday and 1pm on Saturdays. Great, after 19 minutes I hang up.

    So I have another go. This time I try “Fraud, fraud, fraud” as the reason for calling and wait 5 minutes for a human to answer. This time I launch staring in to I want to report a fraud on a business account. Daniella says she’ll try BT security and puts me on hold. After a few minutes she comes back and says I can’t speak directly with security as they need her to ask me some questions about the account first. I repeat what I told the first guy and she relays this to ‘Security’. What details do they need I ask? Postcode she says. Well try my postcode I gave her I suggest. After another period on hold Daniella returns to say BT security need details on when the business account was applied for to log the issue and security don’t have access to business accounts. It’s catch 22. How would I know when the account was requested if I did not set up the account! I ask for a call reference number but Daniella does not have one. She suggests I must call BT business when they are open tomorrow so they can speak to security. I hang up, another 30 minutes wasted.

    Let’s review the user experience so far. I need to report a fraudulent use of my identity by BT to BT. I try calling the BT care number but my reply as to why I’m calling is not confirmed as being recognised. Front line agents only have access to residential account details and they won’t connect me with security department because they can’t validate. BT care can’t log the report for me and won’t let me do so directly. The process is clearly broken.

    So I decide to tweet. Social networking to the rescue. Next day, I scan my replies and see BT business care agree my experience is not good, suggest I call BT security and give me the direct number. It’s 0800 321 999 if you need it by the way. One more time I call. I get another IVR system with 5 choices from checking identify of BT worker to reporting bomb threats.Then another 5 or so choices none of which seem appropriate so I pick 4.  In the end I speak to Phil. Someone sensible at last. He asks me many of the same questions but there’s no mention of needing another system. In fact his demeanour reminds me of the conscientious policeman noting every detail down and checking it. He gives me an SIR number (security incident report number). I ask him why BT care did not pass me though yesterday. He did not know, we’re open 24×7 he says.

    It will take up to 10 working days to get a response to BT about my report and complaint. I’m promised they will put an immediate disassociation order on the fraudulent accounts so I’m not connected to them. I raise the issue of bad credit rating as the bills won’t be paid by me. Phil suggests I should be okay but to raise it when they followup the report.

    Next day the postman leaves a BT Business Smart modem on the doorstep. The label has a helpful instruction to leave with a neighbour if addressee is out but that’s not been read. It’s addressed to me, no mention of a ‘trading as’ company name, obviously BT fulfilment are more used to dealing with residential customers and reuse the standard label maybe. I think about calling 150 and having a tedious conversation with AVR and a Care advisor but decide to let BT security know instead. I can try out the SIR number to see if it’s a key.

    Phil doesn’t answer this time, it’s a nice lady who’s a bit taken aback by my opening comment that intranet.secuity.bt.com mentioned in their IVR returns a 404. “Oh, that’s for internal use only” she explains. Ah okay, so how would I know that? I ask. Apparently the 0800 number for BT security is also used by BT staff most of the time and nobody’s thought to set up an IVR fork to help befuddled customers get a sensible user experience. No matter the lady was very helpful and the SIR works a treat to update yesterday’s report.

    So I’ve written this post with intended sarcasm triggered by a catalogue of bad user experience from BT that I feel should have been far better. Some major questions I suggest BT should ask themselves are:

    1. Why can a BT business account be opened without sufficient checks being made to verify the validity of the identity of the requestor?
    2. Why is the main BT care AVR so poorly designed in that a) it fails to confirm it’s understood what the reason for the call is; b) the flow choices have not been designed to cover sufficient scenarios.
    3. Why have BT care advisors not been trained to hand off requests to report fraud to avoid the farcical situation above.
    4. Why have security scenarios crossing BT residential and BT business not been thought through?

    Names may have been changed to protect the innocent.

     

  • 3 Tribes Experiment UX Camp

    3 Tribes Experiment UX Camp

    After some persuasion by colleague Patrick Sansom I presented the 3 Tribes Experiment at UX Camp Brighton 2017, an annual event full of shared learning and fun. This year there were five rooms that offered a choice of presenters and subjects covering diverse topics as user experience, user research, lean coffee discussion on design sprints, to Chris How’s memorable Machiavellian masterclass in manipulation and Richard Vahrman’s wearable musical interfaces. Something for everyone.

    It’s well worth spending a day there immersed in current thinking and practice and opportunity to meet some impressive people. Sessions are all time boxed so each slot is focused but still offers plenty of audience participation and interaction as you would expect for such an event.

    My 3 Tribes experiment examines the link between personality and empathy that can influence the way we think about solving problems. It’s been rattling around in my mind for a while and UX Camp was an opportunity to test the theory. The slides I used together with the experiment results are available to download here UXCamp-3Tribes.

    The experiment began by asking all participants to choose one of three questions they most identified with and take a red, green or blue sticky to remember their choice. Each question is based on a Myres Briggs personality test and selected to distinguish a participant’s empathy. As you will see from the slides the questions were never intended to provide an accurate determination of personality but would at least give some segregation. Next the participants were set a challenge of improving a well known end user experience problem, that of the ‘Unexpected item in the bagging area’. I asked everyone to think about their ideas individually at first so they would not be biased by others. The silence was deafening and after a long minute I let them group into their tribes to discuss ideas.

    Think around 20 attended and 15 participants returned results for the experiment. To my surprise, the results show a significant correlation between expected empathy and improvement approach taken for design and business process. All participants that chose a blue tribe sticky responded with a business needs empathy. And participants that chose a green tribe sticky responded with a design needs empathy with one also voting ‘half’ for user needs. Two thirds of participants that chose a red tribe sticky responded with a user needs empathy. Caveat – participants agreed their user empathy was biased by their past experience as customers. Each participant determined their empathy based on the examples I demonstrated after we’d discussed a few improvements from each tribe.

    I’m sure psychologists would find many mistakes in my amateur experiment and point out bias was inevitable but I do find the results interesting and hope you do too.

    UX Camp offered several speakers with similar themes including Leo Barnes and Mark McElhaw’s Mindstates which I’ll be finding out more about.

    Shows combination of user, design and business needs
    3 Tribes Combined
  • Storycase design web site for Juditmarden.com

    Storycase design web site for Juditmarden.com

    February 2017: Storycase have designed and built a website for Judit Marden a garden designer based in Surrey, UK. Graduating from London’s Inchbald School of Garden Design, Judit’s site juditmarden.com showcases a variety of garden landscape designs including small urban gardens and larger public spaces and country gardens. Storycase utilised a fully responsive WordPress solution with custom templates and plugins.

     

  • Storycase design web site for Timothy Noad

    February 2016: Storycase design and build website for Timothy Noad professional calligrapher, illuminator and heraldic artist. Tim’s site timothynoad.com show cases his exquisite artwork including designs for medals and coins you may even have in your pocket. Storycase built a fully responsive site based on WordPress CMS and provided training to manage the content.

  • How to capture non functional requirements with stories

    How to capture non functional requirements with stories

    Non Functional Requirements
    Non Functional Requirements

    I’ve used several ways to capture or address non functional requirements (NFRs) with user stories. Agile practitioners such a Mike Cohn have written about the challenge. Most agree there are two main approaches: write each NFR as a user story or include NFRs in the definition of done (DoD). Let’s see how each approach can work in practice.

    First what do we mean by non functional requirement and is it an oxymoron? NFRs or quality goals for applications and services include: the service must be available 24x7x365 with 99.99% uptime. Or all user requests must be returned within 3 seconds. Or maybe DevOps must be notified to resolve critical outages, etc.

    Many of the quality goals are really cross functional requirements that determine choice of service architecture. Other NFRs help shape the company’s brand by promoting a consistent style and behaviour.

    A good way to decide how to approach an NFR is to ask how can I test it. User stories with clear behavioural driven acceptance criteria make an obvious place to start.

    User Stories

    As a bank customer 
    I want to access my account at any time
    So that I am not restricted to normal banking hours
    SCENARIO Registered customer accesses their account at any time of day
    GIVEN customer has active account
    WHEN customer logs in with valid credentials
    THEN all account services are available for use

    Testing this story needs some thought. Any time literally means always so how many times should the automated tests run? And all account services suggested a complete set of the online account services are checked for each invocation. Clearly an onerous test. Suppose we consider a related NFR for number of concurrent users:

    As bank service provider
    I want to support up to 10,000 users accessing their online account
    details simultaneously
    So that peak demand by customers at busy periods is satisfied

    Now we have 1000 user requests at any time of day wanting to access the service. We need one more NFR to close out acceptance criteria:

    As a bank customer
    I want to see my account details within a few seconds of logging in
    So that I can access my account quickly
    SCENARIO 10,000 registered customers simultaneously access their account at any time of day
    GIVEN customers have active accounts
    WHEN 10,000 customers log in with valid credentials within the same second
    THEN all customer's account services are available for use within 5 seconds

    A combination of NFRs framed in a set of user stories help build test scenarios that ensure quality goals are achievable and measured. But if every user story needs to include the response time and common error handling it makes for a lot of repetition.

    Definition of Done

    Another approach to cross cutting NFRs is to build them into the DoD. For example a team might commit to a DoD for each story such as:

    • All acceptance criteria met
    • No critical or major defects found
    • Minor and cosmetic defects logged
    • Audit log entries captured for all transactions
    • Maximum response time achieved
    • Minimum concurrent users supported
    • Branding guidelines adhered
    • WAI accessibility requirements met
    • etc.

    The DoD becomes a wish list for all the quality goals and can quickly grow. With a tightly integrated test team that can define BDD criteria for each requirement the DoD can be used.

    Back to the question of what an NFR means. Each quality goal needs quantitive values to perform tests and determine if the outcome passes or fails. Failure of a test is logged as a defect and development effort put in to correct it. But what if the test fails when the service is operational? It’s the user who has to log the defect and that can be an expensive or costly for reputation.

    That’s why I suggest an NFR is often an oxymoron as it’s really a functional requirement or rather it needs a user story to ensure the service always behaves in a desired way. For example if we return to the availability NFR and the business and user’s needs:

    As bank service provider
    I want to support up to 10,000 users accessing their online account details simultaneously
    So that peak demand by customers at busy periods is satisfied
    As a bank service provider
    I want to inform customers when my online service has reached maximum capacity
    So that users know why they can't access their account

    Or from the user’s perspective

    As a bank customer
    I want the online service to tell me when it's too busy for me to login
    So that I can come back later (or go find another bank!)

    A good quality service is one that works with minimum friction but customers know things can go wrong. What customers hate is not being told when things go wrong. It’s like being on a train that just stops for a while and there’s no announcement to say why. So a good service needs to have behaviour built in to respond to operational issues and that needs a user story to define, build and test the behaviour to ensure it’s done.

  • User need driven stories

    In the UK the Government has sought to improve digital service design by focusing on users and their needs rather than more traditional requirements driven approaches. User research is at the heart of a project’s discovery or inception phase and follows through subsequent alpha and beta phases. The user researcher is a clear an distinct agile team role responsible for coordinating and planning multivariate experiments and presenting findings to feed into user interaction design and stories.

    Agile user stories that adopt the common template of

    As a <user role>
    I want <user goal>
    So that <user reason / benefit>

    help capture user needs by stating the user’s goal and reason of each story. It seems easy to equate user need to user goal and satisfy user researcher’s suggestions.

    There are a few traps that may trip you up though. Let’s consider a simple login service as many sites have them. If you are not using OAuth and need to enter a site username and password for authentication then you likely have a typical user story:

    As a registered user
    I want to enter my credentials
    So that I can login to the service
    
    

    User research adds some acceptance criteria:

    SCENARIO User enters an incorrect password and attempts to login
    GIVEN user has entered an incorrect password
    AND user has entered a valid username
    WHEN user requests login
    THEN user is told their password is incorrect

    And the site’s security users demand:

    GIVEN user has entered a incorrect password
    AND user has entered a valid username
    WHEN user requests login
    THEN user is told their username or password is incorrect

    It’s just a small difference but to a true user who may use the service infrequently or is logging in from a different device that does not remember credentials it’s a frustrating experience. Which is incorrect – username or password? The service must obey the security needs the penetration testers say or they won’t pass the system acceptance test. A hacker may be trying to find valid usernames and if they are told the truth about credentials they can harvest them easily.

    So what’s missing here is a better way to capture the user needs and design a less frustrating user experience. Let’s start with the user stories:

    As a registered user
    I want to know when my credentials are incorrect
    So that I can login to the service easily

    Also we’ll include other users:

    As security officer
    I want to hide knowledge of incorrect usernames or passwords
    So that hackers can't guess credentials easily

    Or if you prefer one technique is to recognise and represent malicious users with stories as threats and design specific behaviour to counteract:

    As a hacker
    I want to discover valid usernames
    So that I can use a registered user's account to gain access to the service

    So now we can see there are three types of user with conflicting user needs. Unfortunately for the real user many web sites prioritise security user needs and don’t recognise or deal with the conflict. Cyber security is trump card.

    Is there a better way? Let’s have another look at the login story to see where the problems lie.

    As a registered user
    I want to know when my credentials are incorrect
    So that I can login to the service easily

    From the real user’s perspective they have registered at some point and set up an account. They may or may not have entered the correct username / email address but they think the service should tell them if it’s wrong. Users may not realise that without a correct user name the service can’t validate the password although it’s obvious to the analyst and developers. User research can pick up on these aspects and lead to a better user story:

    As a registered user
    I want the service to help me when my credentials are incorrect
    So that I can recover my username or password if I forget them

    Here the user journey changes to scenarios that can help real users discover what they have done wrong. Instead of “You have entered an incorrect username or password” the service offers ways to retrieve forgotten username or password and by so doing establishes the persona rather than assuming any. Obviously this needs more effort and care to keep the security officer happy that no vulnerability is being introduced.

     

  • Storycase wins contract with Civica

    Storycase provide business analysis consultancy services for Civica on a Nuxeo implementation. Storycase will work with stakeholders to define the product backlog and drive the agile scrum team to delivery a document and web content management solution.