Embedded Files
This site is best viewed in Desktop mode.
DESIGN
Follow our 13-Week thought process in
Discovering, Defining, Developing, and Delivering.
1. DISCOVER
1. DISCOVER
With the theme "Reduce hawkers' susceptibility to fraud" originally provided by DBS, we embarked on a journey to understand the issue in depth. Our research was conducted in two parts:
Primary Research
Primary Research
We conducted ground interviews with hawkers and customers to gain first-hand insights and understand the problem from their perspectives.
Secondary Research
Secondary Research
Concurrently, we explored existing online resources to see what others were saying have about this issue.
Summary of our Key Findings
Our preliminary research revealed that many hawkers place a high value on time efficiency—after all, time is money. While e-payment systems offer convenience, they also introduce more possibilities for errors, such as incorrect inputs and difficulties in verifying transactions, leading many hawkers to prefer cash. Additionally, the refund process for e-payments is often tedious and slow to resolve, adding to their reluctance. In some hawker centres, the demographic skews older, with many hawkers being less familiar with technology, making them more vulnerable to scams and fraud.
2. DEFINE
2. DEFINE
From our research, we identified our 2 main stakeholders: hawker and customers.
Hawkers
Hawkers
As a hawker, currently I have to identify customer fraud amidst usual stresses in order to avoid getting scammed by customers.
How might we make the payment process both efficient and trustworthy?
Customers
Customers
As a customer, currently I have to deal with long waiting times from other uncooperative customers and latency in payment transfers in order to complete my purchases.
How might we make the payment process more time-efficient?
Problem Statement
Problem Statement
How might we reduce DBS e-payment discrepancies (i.e. incorrect payments, fake screenshots) at hawker stalls cost-effectively with minimal disruption to the hawkers’ operations, and provide an easier method to deal with discrepancies in the event that it happens?
User Personas
User Personas
Background
Adopted cashless payments 2 years ago as a participant in the Hawker Go Digital programme due to various benefits
Mdm Lee Mei Ling
Mdm Lee Mei Ling
Pain Points
Hard to check digital payments
Hard to read small fonts
Transaction fees cut into small margins
Unfamiliar with digital payment services
Wants
Does not want to reduce slim margins
Streamline digital payment processes
Reach a wider target audience through digital payments
Background
Previously paid $150 instead of $1.50 at a stall and had to go through a tedious process to get her refund
Nur Aisyah Binti Ahmad
Nur Aisyah Binti Ahmad
Pain Points
Queues are too long due to difficulty in verifying payments
Does not carry cash and cant eat at stalls that only take cash
Worried about keying in the wrong amount again
Wants
Continue to use cashless payment
Minimise unnecessary waiting time
Reduce probability of wrong payments
Problem Storyboard
Problem Storyboard
Hawkers
Main pain-point is the difficulty in verifying digital payments.
Sub pain-point is the cost of alternative solutions.
Customers
Main pain-point is the lack of adoption of digital payment services.
Sub pain-point is the long waiting times from troubles with e-payments.
3. DEVELOP
3. DEVELOP
Following this, we adopted AGILE software principles to guide our development process. We organised our work into bi-weekly sprints, allowing us to iteratively develop and refine our solutions. Each sprint involved planning, executing, and reviewing our progress. This approach ensured continuous improvement, with feedback from our professors and DBS mentors helping us make necessary adjustments along the way.
Overview of our Sprints
Overview of our Sprints
Sprint 1: Reviewing daily income.
An interface showing the hawker’s most recent transactions, daily earnings, and transaction history, which can be filtered by date range, day & month
Sprint 2: Reducing payment discrepancies.
A QR code generation system where the hawker inputs the required payment amount, and customers scan the QR code to pay the specified amount.
Sprint 3: Dealing with discrepancies.
A refund system to allow customers and hawkers to raise and rectify disputes, such as sudden changes in amount after payment has already been made.
Sprint 4: Streamlining the workflow.
A built-in calculator that helps hawkers to select menu items or manually input prices to output the correct payment. Includes an AI-powered feature that can auto generate the menu items based on pictures.
SPRINT 1
SPRINT 1
An interface showing the hawker’s most recent transactions, daily earnings, and transaction history, which can be filtered by date range, day & month
User Stories
User Stories
Scenario 1
As a hawker who needs to track earnings regularly
I want a quick and easy way to filter all of my past transactions by a date range, day, and month,
So that I can efficiently view my tabulated earnings.
Scenario 2
As a hawker, who needs to juggle between serving customers and ensuring correct payments,
I want a quick and convenient method to view my recent transactions at a glance,
So that I can efficiently verify new incoming transactions.
Design Iterations
Design Iterations
Iteration 1
Basic application showcasing recent transactions, daily earnings and transaction history, which can be filtered by date.Iteration 1
Iteration 2
Added a filter sub-feature and other QOL sub-featuresIteration 2
SPRINT 2
SPRINT 2
A QR code generation system where the hawker inputs the required payment amount, and customers scan the QR code to pay the specified amount.
User Stories
User Stories
Scenario 1
As a hawker, who manages multiple transactions and wants to minimize incorrect payments,
I want to generate a QR code for the specific amount a customer needs to pay,
So that I can ensure accurate, contactless payments directly from the customer's mobile banking app.
Scenario 2
As a customer, who always key in the wrong amount to pay to hawkers by accident
I want an easier method of payment that does not need me to manually key in the amount to be paid,
So that the automation will leave no room for errors compared to when I give a manual input.
DBSBiz
(Hawker App)
DBSPay
(Customer App)
Design Iterations
Design Iterations
Iteration 1
A QR payment system where the hawker keys in the payment amount and generates a personalised QR code Iteration 1
Iteration 2
Added menu sub-feature and its related QOL settingsIteration 2
Iteration 3
Reference views of how the customer app will interact with DBSBiz (hawker app) when the customer scans to pay the specified amountIteration 3
SPRINT 3
SPRINT 3
A refund system to allow customers and hawkers to raise and rectify disputes, such as sudden changes in amount after payment has already been made.
User Stories
User Stories
Scenario
As a hawker, who must maintain customer satisfaction while managing financial transactions,
I want a system that allows both customers and myself to easily raise and resolve payment disputes,
So that any discrepancies, like sudden changes in payment amounts, can be swiftly corrected, ensuring transparency and trust in my business dealings.
Design Iterations
Design Iterations
Iteration 1 (Hawker App - DBSBiz)
Iteration 1 (Hawker App - DBSBiz)
Sub-feature 1: Refund Request
Hawkers can select and respond to any erroneous transaction through the Main History View. They can submit a refund to the customer through the Refund Customer View.Sub-feature 1: Refund Request
Once the refund is submitted, the hawker and customer can view approved refunds in a separate “Refunded” tab.
Sub-feature 2: Receive Request
In contrast, the hawkers can receive refund requests from the customers in a similar fashion. They have to approve of refund requests in order for the refund to be submitted.Sub-feature 2: Receive Request
Colour Schemes for History View
where hawkers can see their new submitted requests and new updates to their previous requests.
Colour Schemes for Requested Refunds tab
where hawkers can click in from the main History view to view the status of their refund requests.
Iteration 2 (Hawker App - DBSBiz)
Iteration 2 (Hawker App - DBSBiz)
Refinement of Colour Schemes
Refinement of Colour Schemes
We have design queries with regards to the colour schemes of some views on the hawker app. As such, we consulted our client DBS for their design preferences.
These were their preferences.
Iteration 3 (Customer App - DBSPay)
Iteration 3 (Customer App - DBSPay)
Simplifed Userflow based on DBS Feedback
Simplifed Userflow based on DBS Feedback
After discussions with our client DBS, we adjusted the overall user flow accordingly:
For Hawkers: They can now raise refund requests that get approved instantly, without requiring customer approval.
For Customers: On the customer app, users can submit refund requests, but these requests must first be verified and approved by the hawkers.
SPRINT 4
SPRINT 4
A built-in calculator that helps hawkers to select menu items or manually input prices to output the correct payment. Includes an AI-powered feature that can auto generate the menu items based on pictures.
User Stories
User Stories
Scenario
As a hawker, who frequently deals with diverse orders and occasionally modifies menu offerings,
I want a calculator that allows me to quickly select menu items or enter prices manually
So that I can efficiently compute the correct amount for customer orders and update my offerings without hassle
Design Iterations
Design Iterations
Iteration 1
Added in more tabs in Settings to provide better support for usersIteration 1
Sub-feature 1: Manually Adding of Menu Item
Users can add new menu items to be used in the built-in calculator and even edit if there are mistakes with any menu item detailsSub-feature 1: Manually Adding of Menu Item
Sub-feature 2: AI Auto Generation
AI auto-generation of menu items from a physical menu into the built-in calculator to aid the onboarding processSub-feature 2: AI Auto Generation
Iteration 2
Iteration 2
More QOL features
Added in:More QOL features
- Option to view menu items in grid or row layout
- Search box and favourites were added to help hawkers find menu items faster
4. DELIVER
4. DELIVER
Our design journey spanned a fulfilling 13 weeks. After countless hours of dedication and numerous sleepless nights, we proudly showcased what DBSBiz is capable of. Here are some highlights of what we delivered.
One of the Sleepless Sprint Nights
One of the Sleepless Sprint Nights
21st June, 12th July, 26th July, 07th August 2024 | Online
In every sprint, we dedicated countless hours to refining our app based on our client's feedback and then presented the polished version to our professors. We're proud to say that we consistently scored well in each sprint.
Final Sprint Presentation
Final Sprint Presentation
7th August 2024 | Google Developer Space Singapore
We presented our final prototype at the Google office to our professors and Google mentors. The applause that followed reassured us that our hard work had truly paid off.
SDS Showcase
SDS Showcase
8th August 2024 | SUTD Library
We showcased DBSBiz to our DBS mentors and other senior DBS officers. The feedback was overwhelmingly positive, and we’re proud of how far we’ve come.
DBS All-Hands Meeting
DBS All-Hands Meeting
25 September 2024 | DBS @ ESR BizPark Changi
We shared DBSBiz to over 50 DBS personnel. Majority of the questions asked were tough but we were happy that we managed to answer them confidently.
Page updated
Google Sites
Report abuse