Reducing complexity
Case Study
My role
As the sole UX designer, I was responsible for providing input and support to two engineering squads. This case study focuses on an exploratory project aimed at identifying a tailored product line for a new market segment.
About Backbase
Backbase is the world's largest engagement banking platform, enabling banks to provide the very best digital experience for their customers.
The goal
To enable banks to offer their small-medium-enterprise (SME) business customers the ability to manage the account-based permissions of their employees.
What we knew
Insights from our sales and customer project implementation teams indicated that our current product offering, designed for large corporations, was struggling to meet the needs of smaller business customers; and that addressing this gap would present a significant business opportunity for the company.
What would success look like?
We strengthen the business case presented by our sales and customer-facing colleagues and persuade the leadership team to invest in a development team to build and maintain the product offering.
Learn fast (and cheaply)
Inspired by Google Venture's SPRINT methodology, which prioritises testing and validating ideas before delving into execution, I decided to adopt a similar approach for this project - and stakeholders agreed.
Planning the approach
While I didn't strictly adhere to the day-by-day SPRINT plan, I dedicated significant blocks of time in our schedules to ensure the foundational principles of design thinking and the elimination of biases were effectively implemented.
Design Sprint(ing)
Monday
To initiate the exploration, our initial step was to test the current product offering with a selection of target SME market users.
At this early phase, a primary objective was to understand the product's usability performance. We deliberately refrained from analysing the product before testing to prevent any unwarranted biases from influencing the tests.
This method allowed all team members, regardless of their company roles, to objectively and empathetically observe how users perceived and engaged with the product.
User context
In each user test, we made it a point to start every call with a set of discovery questions aimed at understanding the shape and size of the user's business, as well as their past encounters with applying user permissions in their daily banking processes.
Even though the individuals we interviewed had limited exposure to utilising this functionality in their present business activities, our screening process assured us that these users possessed experience from previous employment engagements.
Usability results
The usability test results reinforced the feedback we received from our sales team, indicating that the product is perceived as "too complex" and not aligned with the needs of the SME target market.
Without the user researcher on the call to navigate the user through multiple usability blockages, our results would have suffered further.
Key areas of focus
To center the team's attention on Tuesday's exercises, we conducted a 'How Might We' session based on our research findings. We synthesised the key challenges that were deemed most important to explore further.The decision was made to focus on seeking inspiration for 'reducing complexity' and 'making key tasks easier to comprehend/action' during Tuesday's 'sketch' activities.
Tuesday
Tuesday started with each team member presenting a lightning demo showcasing common functionalities that they believed addressed problems similar to the ones we had identified.
Quickly, we identified a common thread among our examples - each one shared 'a simplified approach to settings creation.'
Tweaking the formula
Given other business commitments, our team could only allocate a half-day to the Tuesday’s SPRINT activities. Considering this constraint, I aimed for the group to capture initial sketch thoughts based on the insights shared during the lightning demos and contextualise them with the problem statements.
To help guide the participants with there explorations, it was useful to remind them of the key patterns we would need to mimic within our design solution.
Sketching
Trusting the team to articulate their ideas through sketches, I introduced them all to a variety of Miro assets (based off of our existing design system) before concluding the half-day activities. During the call, I swiftly generated the following ideas to demonstrate the diverse ways a design idea could be communicated.
Wednesday
Wednesday started with each team member presenting back their sketch explorations to the group. Following this, we all dot-voted on which ideas had the most potential in helping us solve the task at hand.
After lengthy deliberation over a wide-range of examples, we came to the agreement to progress the following ideas.
Key threads
These two ideas diverged significantly from the existing features in the product, which was a positive outcome. While the question of whether both could coexist in the same prototype remained a consideration for later stages, there was unanimous agreement that the 'templated path' and the 'wizard' approaches aligned with our initial objectives.
To explore the feasibility of incorporating both ideas into a single prototype, I proposed a story-mapping exercise as a means to bring us closer to a conclusive answer.
Story-mapping
To ensure group alignment and set a clear direction for tomorrow's prototyping exercises, we collectively decided that the demo should concentrate on customers specifically interested in 'setting up entitlement settings for their business operations.'
With this consensus, we concluded the day with anticipation, looking forward to testing our new assumptions
Thursday
As the only team member proficient in Figma, Thursday was dedicated to prototyping and ensuring alignment with the interview script plans.
Contextualising the research tests
To ensure that we could effectively test our key assumption of ‘pre-configured options simplifying the experience’ - we opted to tweak the test scripts to ensure that we could effectively contextualise the prototype to a typical user scenario.
To facilitate this, we opted to have certain items pre-existing in the prototype rather than requiring users to create everything from scratch.
Friday
This day was dedicated to collecting user insights. We organised five user interviews, three of which included participants we had initially tested with. The focus was on conducting contextual interviews with participants before they engaged in usability testing of the prototype.
Recording findings
By involving the entire team in the test interviews, we were able to quickly gather valuable insights on the prototype's usability performance.
Testing results
To wrap up the SPRINT we synthesised the usability insights that had been collected and categorised them into common themes based on their significance.
Our initial impression was that we had effectively validated our primary assumption, given that the majority of identified usability issues were deemed to be 'quick fixes' that could be resolved through adjustments to the UI.
Final thoughts
The prototyped solution clearly demonstrated that implementing a new UI approach would reduce the complexity of the entitlements engine and enhance task completions.
Users expressed a sense of comfort and confidence in using the prototype, a notion we could now support via data collected on mis-clicks and task-time-to-completion rates.
Given the project’s highly successful outcome, we then started to question whether this UI pattern would also prove beneficial for larger corporate banks and if the existing pattern still remained a valid use-case for adoption.
Outcome: Success
The product leadership team were thrilled with the outcome of these SPRINT activities, recognising the immediate benefit and value this solution would add to the product offering.
Prior to allocating developer resources to the product build, we first needed to validate that the pattern could effectively extend across the entire entitlements product (not just the scenario we had tested). To accomplish this, we needed to construct and rigorously test a fully-functional prototype covering all use cases.
Sprint review
It’s fair to say that we all exited the week with the mindset that the sprint activities had been a resounding success in helping us to achieve a positive understanding that the product had a valid market-fit.
With this, we presented our findings and business-case back to the leadership team for decisioning.
Business impact
The deliverable successfully achieved its goal of presenting a compelling business case to leadership for investment in a new line of product functionality.
What was not anticipated was the validity of positioning the product alongside the existing offering as a 'quick setup' or 'wizard' tool for users who sporadically use this functionality throughout the year.
