Category: Analysis

Analysis category includes requirements analysis, business system analysis and modelling using UML diagrams such as activity flows / swimlanes, domain models, class daigrams, use case models and, state diagrams.

  • Marcus Joint Account Opening a Design Delight

    Marcus Joint Account Opening a Design Delight

    Following our series highlighting user experience design failings, this post runs through a great example of a well thought through user journey. We’ll show you, and other financial organisations, that it is indeed possible to provide an effective joint account opening process without the need for paper or post.

    Context

    In Yorkshire Building Society Design Failings – part 2 we showed you one example of how some financial services providers ignore the digital user needs of joint account holders. Although these providers offer the latest mobile Apps and promote online access as their primary delivery channel they fail to deliver for some user types. Joint account holders are often classified as lower priority and revert to paper or physical channels resulting in lengthy delays.

    User authentication is often cited as the reason for the poor joint account opening UX. The primary account holder begins the online account opening process but the introduction of a secondary account holder results in complexities and the provider’s product owner decides to digitise that part later citing Minimum Viable Product or MVP! I guess the account opening project team get so focused on delivering primary use case scenarios they never get around to implementing the alternatives.

    However, joint account holders, together with an increasing aging population, are an important cohort of user types and should not be ignored. Although there may be fewer joint accounts, their average savings balances are often larger and so it makes sense for providers to consider their online needs.

    Doing it right

    Marcus, by Goldman Sachs, are of course a new entrant to UK consumer banking having launched here in 2018. So you may argue they don’t carry the legacy of traditional paper based processes that incumbent UK financial organisations have endured.

    On their website’s About us section Marcus highlights they combine over 150 years of Goldman Sachs’ financial expertise so you may think there’s a legacy in old ways. However, Marcus also mention this is combined with the innovation of a fin-tech and that they want to “help you manage your savings easily and effectively.” As I’ll show, Marcus have indeed managed to deliver a fully online joint account opening process.

    So can this simple philosophy of putting the user’s need before that of the product team’s delivery be the reason for the success? It’s easy to dismiss corporate mission statements or perhaps simply ignore them when embarking on a new agile delivery. Here at Storycase, we’ve seen several digital transformation programmes with a plethora of mission objectives and hierarchies of target operating models were it’s too easy to loose sight of the hapless users.

    Driven by user needs

    In a joint account opening process there are two primary users. And that’s the problem for an online delivery channel in which there’s usually only one authenticated user. How can a second user be part of the journey when they don’t have a user account and are not logged in? Let’s just revert to paper, right? No. For Marcus and other enlightened providers paper is not an option as it does not align with the corporate mission and certainly does not meet the user’s need.

    Let’s look at how Marcus solves this. When you chose to apply for a joint account. You and your joint applicant will both need your own email address, because this is what you’ll use to log into your account. Both need to be present during the application as you’ll each have your own part to complete. You will be taken through the application first, then the other.
    You have to successfully complete your part before they can agree to open an account for you.

    Simple and effective. Of course, each applicant has to answer questions to ensure Marcus can identify the individual and pass the AML regulations that apply. And as a joint account holder, some of your personal information may be visible to the other joint account holder. But this should be reasonable as it’s a joint account!

    Modelling this journey with swim lanes demonstrates how the first applicant’s online session is used to pass from one applicant to another. The second applicant doesn’t need to login on their mobile or laptop, they simply pass control between each other using one device.

    Once the joint account application has passed verification and email is sent to each applicant to set up their online account. This way each applicant can choose their personal security credentials. Overall a smooth user experience which enables immediate account opening for both applicants. I should point out that each applicant must pass an online verification process and this will inevitably restrict certain people with insufficient criteria.

    UX design features

    The design team at Marcus have also made it smoother for applicants as they step through the data entry screens. Here are some examples.

    Dates

    Notice the expected date format is shown in the heading along with the hint text that pre fills the date. As you enter a character the hint is overwritten and separators appear automatically. If you make a mistake and backspace the hint reappears. This makes it super easy to use and avoid mistakes.

    As you expect, if you move away from an incomplete entry the data issue is highlighted:

    Marcus has followed an industry standard and used a red colour to draw attention to errors albeit the only data entry in error above is not actually red! Accessibility has also been considered with an exclamation icon and a textual error description for screen readers.

  • 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 Loyalty with Aimia.com

    February 2012: Storycase wins contract with Aimia.com to provide agile business analysis to develop a next generation loyalty platform. Aimia (formerly Groupe Aeroplan) is a global leader in loyalty management and run Nectar in the UK.

  • Agile analysts – do they exist?

    I like to think I’m agile. Most of the time I’m working as an analyst on projects, split between business and system analysis tasks. I talk with the business experts and help them define their requirements from requests to change or add new behaviour to adapt to business needs. In an ideal agile world I’d be redundant, as the business would have resource to allocate experts to work alongside developers in the project team. Fortunately for me and many other analysts the business are rarely flushed with enough experienced business experts and must rely on a go between to convey their message. I like to think I add value by removing any preconceived notions the business may have in specifying how they want the new functionality to work, by filtering their requirements and extracting what they want it to do. I might write a story that details a change to an operational report or define a new addition to the product set. I seek estimates from the developers and feed this back to the business for approval. As a go-between, I’m fulfilling a legitimate agile role.

    But is there really a need for an agile analyst? Is the term an oxymoron? It’s a question often asked by companies starting out on the agile path. CEOs read agile books about empowerment and business sponsors and plough in with pilot projects that bring swift results. They attend seminars and see the productivity of pair programming. Six months or so after the heady kick-off meeting and countless show and tell sessions the business realise they have more work to do than automation can bring. Who’s going to handle the customer support lines? Who will send the white mail and respond to written enquiries? Just what does Sox mean to audit? Soon the full time business sponsor is part time or has little or no time to spare at all. We’ve seen it happen on several projects.

    Beyond the consultant’s vocabulary of business process change and IT infrastructure lays the reality of an end-to-end process. In the haste to embrace agility the business may forget this. But I like to think the analyst never will. The agile analyst can fill the gap when the initial sponsor retreats or play the role of surrogate business expert when full time secondment was never an option. They may even re-badge themselves as product specialists.

    I like to think the agile analyst brings a few more tools and techniques that the businesses sponsor or developer could rarely provide. As an analyst I can create models and unambiguous diagrams that slay endless business arguments. For example, a state diagram that clarify exactly in which circumstances we will accept a certain business event. Or I can create a data model that captures the legitimate rules for relating product to service. It’s true, once these business requirements are understood by the developers my effort if no longer required, I’ve fulfilled my role. But when significant changes are required later on the analyst can again help filter and convey requirements without bias of technical forethought.