On a Sunday morning I get a call from my friend and mentor, Jaggi to ask if I would like to be a part of a customer-centric design transformation of a known NZ brand.
Yes—I said.
I was given the opportunity to transform the digital experience of a large Auckland-based broking form with nation-wide branches, each with a large team of financial advisors.
The processes now needed to be aligned with the new 2020 regulations from FMA—the governing body.
Knowing my abilities, Jaggi offered me the opportunity to be a part of the team as a researcher and experience designer.
Opportunity.
Build a trusted relationship between a financial advisor and customer to help the customer realise their financial dreams using a first of a kind tool that simplifies the customer’s financial journey and reduces task load for the advisor.
Research
Process.
We assembled a team* of Product Owner, Financial Advisor (SME), Experience Designer (myself), two researchers (including myself), security advisor and platform architect.
To avoid the risk of early solutionising—a trait often seen in waterfall teams,
We remain agnostic about features, platform, tech and focus solely on experience and end goals for the customer.
As strong believer in contextual research, I and the other researcher shadowed two financial advisors during their first meeting with two customers. Between us, we shared the research findings before presenting to the team. Both researchers had similar patterns surfacing in the technique they used.
Research Tool KIt.
I think all that is truly needed, the MVP toolkit, is you, a user and a screen recorder or Teams/Zoom. User research is not tool driven or expensive, but with this toolkit it makes it appear prohibitively difficult and expensive—a blocker. This evolving idea that tools replace skills and experience isn't sustainable at all and doesn't do the ambitious practitioner any favours. The best researchers I've known are comfortable with a user and a notepad knowing that the tools are only to support the core activity.
The SMEs expressed concern over the meetings being filmed. It was therefore that we decided that both researchers attend two meetings each and conduct a mock meeting with the SMEs to build team’s understanding.
I have previously used Dovetail, Enjoy HQ and Handrail to store, synthesise, and share insights in a big enterprise. For budget constraints, we decided to use google spread sheets—however I would be recommending condens.io for the next round of research.
We don’t know what we don’t know.
Each time I reinforce this statement, it opens a door for further learning and deepens my understanding of the project.
In this case there was a lot to learn—fast. We did not want to test our research hypothesis without understanding the current state journey and validating the scope of the solution.
We wanted to build the right solution—not only build it right.
Although the client knew what the problems were, the problems we were too broad to allow a practical solution or too narrow to be worth the investment.
Design Sprint gave us a shortcut to learning without any significant development.
We defined Design Sprint challenge by looking at the entire context of the business strategy and linking it to overarching business goals/metrics and actual customer problems
Get stakeholder buy-in and alignment. Since the challenge is connected to business objectives the stakeholders are directly accountable for, their support to run the Sprint is assured and, more, they will be interested in seeing the results implemented post-sprint.
One of the pushbacks to Design Sprints by management and teams was the time commitment. By reducing the program by even one day proved very valuable. We did this without removing any exercises or compromising on the quality of the program or skipping any of the time-boxed activities.
I also found Miro to be a great collaboration tool to run a 2 day sprint in the lockdown. I realise that the design of the sprint needs to be adjusted to suit the team signature. It is best to be flexible to get maximum enrolment for the process to be effective.
Roles and Personas
During the sprint, we defined the vision and developed a shared understanding. I then mapped the current state journey of the experience with the SMEs.
This surfaced the roles associated with touch-points within the journey. I dived deep in business data and leveraged SME knowledge to create light weight personas using archetypes.
Building team empathy through an artefact like a persona and using a framework like JTBD created a ‘voice of the customer’ in the team. Feel free to read my thoughts on Persona as a tool here.
This facilitated the How Might We and prototyping sessions that followed later.
A list of my current goals may communicate what I want today. However, this list can’t communicate the purpose these goals aim to serve, nor can it communicate what goals will arise in the future.
Desired Journey + Product Scope
After mapping the journey to contain the new processes complying with the regulations of FMA (governing body), the team started to explore the product scope that aligns with the desired experience.
The product scope was seen as a suitable answer to realising the desired journey.
We now had buy-in from the stakeholders.
We had decided to improve the human interaction in the strategy meeting (previously known as ‘first meeting’). The proposed solution would be an answer to the experience gaps stated by the SME and validated by research findings. We were ready to test this.
Mortgage canvas was now ready to be realised.
We took every problem as an opportunity for design. By framing every challenge as a How Might We question, we set ourselves up for an innovative solution.
We designed with them—
and for them.
By defining themes and insights, we identified problem areas that pose challenges. Next, we reframed our insight statements as How Might We questions to turn those challenges into opportunities for design.
We use the How Might We format because it suggests that a solution is possible and because they offer you the chance to answer them in a variety of ways. Through this process we did not suggest a particular feature solution, but allowed for a perfect frame for innovative thinking.
I also made sure that the How Might We’s aren’t too broad. It’ was a tricky process but having good How Might gave us, both, a narrow enough frame to let you know where to start your Brainstorm and enough breadth to give you room to explore wild ideas.
Parkinson’s Law
Work expands to fill the time available for its completion.
This means that if you give yourself a week to complete a two hour task, then (psychologically speaking) the task will increase in complexity and become more daunting so as to fill that week. It may not even fill the extra time with more work, but just stress and tension about having to get it done.
By assigning the right amount of time to a task, we gain back more time and the task will reduce in complexity to its natural state. Therefore, time-boxed activities are engaging and prove to be highly productive in a Design Sprint.
How Might We…
Below are only some of the HMWs the together-alone exercise generated. We focussed on obtaining a large quantity of cards and less over their quality.
Gather client info unfront so the face to face meeting can be more focussed on strategy.
Limit the number of devices the FA uses in the meeting.
Keep the experience scalable so that it can be used for different customers.
Provide alerts and updates to the client on their application in real time.
Make investment questionnaire easier so that we can get understanding and agreement.
Visually identify the inputs made by the client in their application for easy need analysis.
For design to succeed and thrive in an environment of rapid iteration and intense measurability, it needs to involve non-designers intensively.
Crazy Eights is a core Design Sprint. We used this technique to generate ideas quicker since we already had the insights from the HMWs to draw upon. The purpose is to generate a number of different ideas as a time-boxed activity.
Perfection is the enemy of done. I ensured that these sketches did not need to be perfect. The sketches should be rough. The purpose of the exercise is to generate a variety of ideas.
This is a great technique to get team members to work collaboratively in a cost-efficient way. I often use this technique if I have a limited amount of time and want to get all of my ideas out without filter.
Great ideas can come from anywhere, even in under 8 minutes.
(Effort
÷
Value)
x
Confidence
=
Priority
The ideas generated in the previous session needed to be prioritised. Yes, conventionally the Design Sprint requires individual voting by team members using sticky dots. Given the little time the team had had to bond and develop a sound working relationship, I followed this technic explained by Bruce McCarthy. Also read Jared Spool’s article on this technic here.
While a simple calculation of effort/value may suffice in many situations, we want to prioritise work that offers large value while taking a small amount of effort, assuming we’re confident in both our estimates of value and effort.
Besides team bonding, the team will developed a shared sense of ownership which will help to carry over the results.
(as opposed to a prototype a designer or agency built)
Here we are: all ideas from previous days will be consolidated in a prototype. One day to make what is sometimes a blurry concept look tangible and testable.
A design sprint helps remove elements of risk from projects and therefore can avoid expensive redesigns or change of directions down the road.
Anyone can come up with an idea, going through various technics, creating a prototype and then putting it in the hands of real users to test can be a very cost and time-effective practice.
Build a trusted relationship between a financial advisor and customer to help the customer realise their financial dreams using a first of a kind tool that simplifies the customer’s financial journey and reduces task load for the advisor.
The mortgage canvas is now safely in the hands of the client’s UI and Dev team—rapidly realising in a ci/cd environment, while we continue to focus on other experience gaps in the journey while staying true to our epic goal.