Singtel Dash Mobile Wallet
The Project
Singtel Dash is an all-in-one mobile wallet that lets customers pay, remit, save and insure in one app. It covers a spectrum of offerings and the product is segmented into different business functions.
My role at Singtel Dash involves:
- Driving design process improvements of Singtel Dash and cross-team collaboration.
- Influence and cultivate design thinking culture at different project teams.
- Manage and direct the design of Singtel Dash across all business verticals.
In order to drive process improvements, I started with Dash PET as the first project to identify gaps within the project function. Dash PET stands for ‘Protect’, ‘Earn’, ‘Transact’ and is an insurance savings plan that lets customers save and protect themselves.
Problem 1: Designers were focused on churning out the design within timeline and missed out on deeper questioning of the product requirements, causing ambiguities and design rework.
Empowering designers to think deeperI started with encouraging designers to clarify and build up their questioning skills on the product requirements. For example, Dash PET logics was broadly discussed with the team and deeper questions was laid out to brainstorm with stakeholders to derive the Dash PET transformation logics and experiences:
- What happens when user enters the Dash PET dashboard on Day 1 and subsequently?
- What happens if the user withdraw amount from Dash PET account?
- What happens if first timer deposits S$30,000 at once?
Understanding the customer's pain points and the product requirements are important before starting any design. This is how the product requirements was improved after I spoke to different stakeholders to understand the current state and information that is required to build the product.
Before: product requirements were verbalised by product managers or reused business presentation deck for communicating requirements to designers. This lacked details that designers were looking for such as user stories and flow. After:
- Phase 1 – A product requirements framework was built to address key information to help in design activities (e.g. business and product objectives, target audiences, user stories, user flow)
- Phase 2 – Product requirements was evolved to give wider audiences knowledge about the purpose of a feature and how success looks like. This is also related to designing with purpose and that design adds value to the business (e.g. sections added in the requirements includes measure of success, customer proposition, unique selling proposition)
- Phase 3 – As there was a separate technical specification that has similar needs as Phase 1 and 2, I wanted to include aspects that development team were also looking for so that only one source of truth is used. After speaking to development team, I added another section to include non-functional requirements, finance or legal requirements.
- To designers: Get clarity of the objectives, goals and customer's problems.
- To project teams: Aligns the team with a single source of truth and helped them to think deeper about the customer's pain points and get clarity before working on the solution and experience.
Problem 2: Changes were ad-hoc and designers were unable to focus on their design task.
Setting up design workflowI set up the design boundaries on what activities to be done on each stage.
Benefits
- To designers: This helped them focus on their design tasks, relieving their burden of making changes every now and then.
- To other stakeholders: They were assured of the review and approval stages and know when changes will get done.
Problem 3: The waterfall lifecycle approach was not efficient in taking the product to market and iteratively get feedback from customers.
Transiting Dash PET into agile practiceWith Dash PET moving in waterfall at the beginning, it was tedious to revisit a development bug or design issue when feedback was provided at a later project stage. Adopting the agile practice helped the team to identify problems earlier and respond them faster.
Credit: Adam Fard
I collaborated with other stakeholders to co-pilot the agile practice and encouraged designers to exercise their own discretion to be part of the scrum meetings (e.g. backlog grooming, sprint planning, daily standups). Given that there are so many alignment meetings, I set up the expectations that designer plays at each of these meetings to help them plan when is a right time to join.
As the agile practice was later adopted by other project teams, each team have their expectations on when designers need to be present for meetings. The key to being agile is to keep ongoing communications amongst project team members, hence, designers also must take initiative to find their way around for project updates.
Benefits- To project teams: Everyone was clear on their tasks, managed timeline risks promptly and encourages continuous improvements at each sprint.
Problem 4: Product validations were done in different channels which caused miscommunications and delay in product release.
Getting buy-ins for a more streamlined validation processDuring design validation, design bugs were previously filed in Powerpoint and Product Manager act as the middleman to communicate bugs to development team. I saw the problem with inefficiencies and proposed a new framework to allow designers to communicate with project team in a single channel.
This is an example of the justifications that I made for improving design validation:
Often, design bugs were also deprioritised as a lower priority bug over functional bugs. This was due to the lack of understanding of what constitutes as a 'design bug' and was mistaken as just aesthetic changes. I came up with a design QC benchmarking framework, along with examples to help the project team understand what is classified as Critical, Major and Minor severity.
Benefits
- To designers: Ensures that design bugs are communicated promptly to developers.
- To other stakeholders: Bugs raised by key sign-off parties are addressed, better planning of development fixes and speed up the UAT process for product readiness.
Outcomes
- With clarity on the product requirements, designers were able to focus on addressing customer's pain points and reduce customer churn abandonment.
- Improved team collaboration process helped to bring product to market with speed.