Building a Digital Challenger Bank

Design sprints at 22seven
Background
22seven is South Africa’s leading personal financial management app. By automatically pulling in bank transactions and analysing it, drawing insight from the data, combined with an intuitive budgeting tool, 22seven helps people better understand and manage their finances.
‍
In early 2016, 22seven set its sights on a new direction - to be a digital challenger bank. This meant participation in design innovation efforts like Customer Activity Cycles, Google Ventures’ Design Sprints and extensive user validation testing. 
My Contribution
Senior Product Designer

I participated in discovery, ideation, Design Sprints and I produced most of the wireframes, prototypes and concepts.

Concept for a pitch deck showing savings goals with aggregated deals and short term loan suggestions.
The business reorganised itself around this goal, dividing staff into cross-functional teams on rotational basis, each team working on various problem statements. Frameworks and methodologies used were Design Thinking based. 
Discovery
To set us off on our transformative trajectory toward a customer-centric nue bank, the business followed the Customer Activity Cycle (CAC) framework as devised by Sandra van Der Merwe in her book Breaking Through - Implementing disruptive customer-centricity. 
‍
CACs are a methodology, very similar to Customer Journey Mapping, in that customer touch points, pain points and opportunities are defined by studying the customer’s  journey, or the customer’s activity cycle in this case, in doing a particular thing. 
‍
Essentially the process looks something like:
  1. Identify the customer’s activities in the “buying” process, or as applied to product development, activities the customer would take in performing a job-to-be-done (JTBD).
  2. Identify problem areas a customer might experience at each touch point (pain points).
  3. Ideate around each activity, considering the pains (opportunities) and how one might solve for it.
The methodology also identifies areas where the customer can be “locked on” and value can be added. This can be illustrated with two diagrams. The first one shows the customer activity cycle and the second one shows how value can be added at different stages of the cycle (see the text in the green boxes).
During the ideation phase, solutions were generated and organised according to its merits in terms of “lock-on”, “switch-on” and “shareability”. Does the solution have customer lock-on, switch-on and share ability?

So what is lock-on, switch-on and shareability?
‍
Lock-on is when a solution or service has the characteristic of a customer voluntarily wanting it as sole or main choice, amoung competition. It has the potential to become indispensable to the customer, a self-reinforcing loop.

Switch-on is when a solution has the potential to activate a customer - is it an attractive or compelling offering such that a customer might sign-up or try it. 
‍
Shareability is when a solution is unique or compelling enough that customers might talk about and recommend it - essentially what traditional marketers refer to as word-of-mouth. 

Here’s a snapshot of the outcome of the CACs:
Prototype, test, repeat
For the next phase, essentially the second diamond in the double-diamond framework, we unpacked, hypothesized, ideated, prototyped and tested solutions, following the Google Design Sprint framework.

We covered a lot of work in this phase, far too much work to detail here. For the sake of brevity I will discuss only one of the design sprints - Validating the Goals and Milestones CVP.

Extended material covering further sprints and prototypes are available here. 
Validating the Goals and Milestones CVP
I was in the Yellow team for this sprint
The day the Yellow team arrived at work, all wearing maroon t-shirts
Google Ventures' framework for a week-long Design Sprint, as detailed in Jake Knapp's book Sprint
Monday - Map

10:00 - Sprint intro
10:30 - Set a long term goal, list sprint goals
11:30 - Make a map
13:00 - Lunch
14:00 - Lightning talks & How Might We (HMW) notes
16:00 - Organise HMWs
16:15 - Vote on HMWs
16:30 - Pick a target

On the first day of the sprint, our aim was to understand the problem, share and absorb related knowledge and define what we want to achieve by the end of the week. 
‍
In the morning, we agreed on a long-term goal - why are we doing this? Where do we want to be in 6 months, a year or 5 years. The sprint challenge we set ourselves was to:
Design and test a way to motivate customers to reach financial goals.
Key sprint questions
‍1. What will motivate / demotivate people?
2. Do people want to be guided?

Next we made a map of the challenge - a sort of high-level user journey. 
In the afternoon, we got Subject Matter Experts (SMEs) at the company  to share what they know, important considerations from their domain. These are called Lightning Talks. By way of example, our Product Owner spoke to us about stock and flow, healthy financial ratios and so on. Following the talks informed by our deeper understanding of the problem space, we set about reframing the problem /challenge in the How Might We format. 
Lightning talks from SMEs
How Might We notes generated. I am aware that the HMW format here is not entirely aligned with the recommended template (action / primary user / desired outcome) - we didn't know any better at the time (2016).
Top "How Might We" notes:
  • Show you that your choice is achievable.
  • Encourage small habits (improvements).
  • Start small and build bigger (towards your goals).
  • Show achievability of my financial goal.
  • Make financial planning bull$hit simple and easy to
    understand.
  • Simply show you’re moving towards or away from
    your goal target.
  • Simple goal tracking mechanism :) :| :(
  • How might we assign money in one account to goals
    and lock it in, i.e. pockets?
  • Make a flexible goal framework.
  • Show you that your spending impacts your goals.
Group → Vote → Set a target
Our final HMW reframing our sprint challenge: 
How Might We motivate our customers save toward and reach their goals.
Tuesday - Sketch

10:00 - Lightning demos
12:30 - Divide or swarm - which part of map, who
13:00 - Lunch
14:00 - 4 Step sketches
17:00 - Home time

We start the day with the lighting demos session - 30 minutes finding and looking at solutions from other companies or apps and capturing and remixing the good ideas with a sketch - 3 minutes per  sketch. 
Apps that inspired us:
  • Fab (goals)
  • Calm (meditation)
  • Sweat (fitness)
  • Strive (streaks concept)
  • Google fit (daily tracking & streaks)
Next we assigned a portions of our journey to team members to sketch in the following step, the 4-step sketches:
  1. Notes. Twenty minutes, silently walking the room gathering notes.
  2. Ideas. Twenty minutes, privately jotting down rough ideas, circling the most promising ones.
  3. Crazy 8s. My favourite part of the day. Eight minutes, on a folded sheet of paper (folded to eight frames), sketching a variation of one of the best ideas in each frame spending one minute per frame only.
  4. Solution sketch. Thirty to ninety minutes, each member creating a three-panel storyboard by sketching in three sticky notes on a sheet of paper. We were tasked to make it self-explanatory, keep it anonymous and give it a catchy title. Ugly was okay but words mattered.
4-step sketching
Wednesday - Decide

10:00 - Sticky decisions
11:30 - Pick a winner, create a fake brand
13:00 - Lunch
14:00 - Create a storyboard
17:00 - Home time

The purpose of the day was to review all the solutions, select one and set a direction to prototype the next day. This was done by first putting everyone’s solutions up on the wall - what the Design Sprint format calls the Art Museum. Next, each team member silently indicated their preference by way of dot voting - each member received a sheet of dot stickers, which they stick on their favourite solutions - up to three dots per solution if they felt strongly about the concept. This creates a sort of Heat Map, surfacing the most-liked solutions. The group then discussed the highlights of each solution and captured important objections. Each team member then voted for their favourite solution by sticking a single large dot on the solution. 
Solution gallery - silent observation
Finally, the Decider of the group (selected at the beginning of the sprint) selected their favourite solution, which would be prototyped the next day.
Pick a winner - dot voting (heat map), straw pole and supervote
The second half of the day was spent coming up with a fake brand which would represent the prototype, followed by storyboarding for the remainder of the afternoon. Storyboarding is a group exercise, planning in just enough detail to help the team create the prototype.
Generate and choose a fake brand. We settled on Pace Bank
Create a storyboard
Thursday - Prototype

10:00 - Pick the right tools, divide and conquer
10:30 - Prototype!
13:00 - Lunch
14:00 - Prototype!
15:00 - Trial run
15:30 - Finish the prototype
17:00 - Home time

Thursday is the pressure cooker day - a full day of speed design. We assigned our roles - Maker, Stitcher, Writer, Asset Collector, and Interviewer. For prototyping, typically tools which encourage rough, fast and flexible design should be selected, however, we opted for production tools Sketch and InVision (Figma was not yet mainstream at the time) - given I was the maker and highly efficient in Sketch and InVision, speed would not be an issue.

Running in parallel with design, the Interviewer prepared interview questions for Friday, the Sticher kept an eye on progress to make sure the prototype ties back to a coherent whole.
Friday - Testing
09:00 - Interview 1
10:00 - Break
10:30 - Interview 2
11:30 - Lunch
12:30 - Interview 3
13:30 - Break
14:00 - Interview 4
15:00 - Debrief

On the final day of the sprint, we find out what our users thought about our solutions via user testing/interviewing. We had great facilities for this at the office - an interview room kitted with screens, devices and multiple webcams recording the user’s face, their hands and the screen being viewed. Adjacent to the interview room was an observatory - a larger room fitted with monitors projecting the feed from next door where the team observed the testing. 
‍
While the recommended number of interview subjects is five people, we planned for four people, of which three pitched up. The interviewer walked each interviewee through the prepared set of questions - open-ended questions carefully phrased so as to not lead the user in a particular direction or bias. The user then navigated through the prototype, thinking out loud as they progress. Meanwhile the rest of the team compulsively took sticky notes noting quotes, observations and interpretations. 

After the interviews, in closing, all stickies were sorted and grouped into themes or patterns from which insights could be drawn. 
What we learnt
The below summarises the key learnings. A more detailed account of testing is available here.
  • Goals were well received by customers.
  • Customers are open to guidance.
  • Customers want to be able to track goal progress.
  • Simple metrics, ie. showing you that you need to save R35/day to achieve your goal would motivate a customer.
  • Saving is considered important - especially saving toward an emergency fund.
  • Goal automations required a bit of explaining before it was understood.
  • Celebrating the success of achieving a goal is important - we then need to give options.
  • Customers don’t read - keep things simple and to the point.
  • Goal recommendations can be troublesome if not handled smartly, in the sense that a customer might be tempted to save for a purchase before paying off a debt. Should a customer be over-extended we should be careful about promoting material goals.
Conclusion
22seven is owned by the Insurance and Asset Management group Old Mutual. From the outset in 2012, Old Mutual agreed to fund the development of a Personal Financial Management tool, which was 22seven’s primary focus up until 2016 when the founding team sought to pivot. Old Mutual agreed to provide limited seed funding only, to conceptualise a digital bank, with the understanding that series B funding would be secured from outside organisation to take the project forward. 
‍
Unfortunately 22seven as a digital bank never materialised. Despite the executive team’s best efforts to secure funding, the business ran out of seed capital before any agreements could be reached. 
‍
Nevertheless, this journey was immensely valuable to all involved - interpersonal relationships built, exposure to modern innovation methods and excellent, in depth exposure to Design Thinking. The knowledge and experience acquired during this time continues to serve me well.

Below are a few concepts I designed for various pitch decks:
I actually met with the card provider to discuss card concepts. They provided the tap-enabled pin-and-chip card circuitry diagrams as seen here. This thin layer is in the middle of the card encased by a layer of PVC on each side. The concept of the card was meant to represent 22seven's simple, transparent and small-print free banking philosophy.
Powered by Webflow
FacebookTwitterInstagram