Share
Explore

Designing OkCollect 2.0: Case Study

A case study on designing a movie recommendation application
Introduction
OkCollect is a product of OkHi - a JavaScript and mobile SDK - that enables any business to collect accurate address.


Project Brief
As the Lead Designer of OkCollect 2.0, design an optimal product for financial services apps by focusing on an efficient and delightful address collection user experience considering new and repeat users.


Feature Set
New user can add address.
Existing user can reuse already saved address.
Existing user can add a new address.
A user of a platform whose phone number format do not conform to OkCollect format should be able to re-enter the number in the correct format.

User Story
Existing User
As an Okhi user, I want to be able to reuse my saved address on a financial institution’s platform for verification so I can get access to more services.

Requirements:
Name
Phone Number
If all requirements are met, the system should notify the financial institution that address has been saved so my account state can be changed.
System should validate that the phone number passed from the financial institution is in the correct format and exists in the dB.
If the user does not exist, see the next user story for details.
From the financial institution’s end, users do not need to select an option for okhi users. The validation should done immediately they indicate interest in verifying their addresses (i.e a click or tap of a button for address verification)
Acceptance Criteria
I know this is done when:
I can see the list of my addresses previously saved.
I can select the address I want to be reused
I get a successful feedback when i tap/click on submit button

Corner Cases
When the phone number passed from the financial institution is in the wrong format, the system throws an error message and redirects users back to a fallback form with the following input field. 1.) Full Name 2.) Phone Number.

New User
As a user, I want to be able to submit my address on a financial institution’s platform for verification so I can get access to more services.

Requirements:
Name
Phone Number
If all requirements are met, the system should notify the financial institution that address has been saved so my account state can be changed.
System should validate that the phone number passed from the financial institution is in the correct format.
System should save the record in the dB.
Acceptance Criteria
I know this is done when:
I can see a search bar requesting for details about my address and a button asking to set location on the map
I can see a form with the following details; 1.) Street information with the following details. a) House Number b.) Street Name with placeholder string guiding me on how to fill it. E.g “Polaris house, 2 obafemi awolowo, ikeja, Lagos.” 2.) Location details with a placeholder string guiding me on how to fill it. E.g “landmark, color of apartment building, gate etc”
I get successful feedback when I tap/click on the submit button.

Approach
In his book “Talking to Humans’, Gill Constable popularized a user/customer-centric approach that I adopted for this project. The fulcrum of his approach is embedded in a design thinking method of challenging assumptions made in risk hypothesis from the purview of the customer.

Riskiest Hypothesis
The belief that people would find OkHi’s OkCollect convenient for adding and reusing their addresses for KYC.

User Testing OkCollect 1.0
To keep my research as short as possible due to the timeline, I reached out to people around me to try out the current OkCollect via the demo store shared in the assessment.

The purpose was to determine the following:
Friction points.
Flow clarity.
Time it takes to complete a task (add a new address, reusing existing address).

Data Gathering
On gathering responses, I picked important insights and translated them into statements so I can establish a vision of how to handle feature implementation.


User’s Problem Statements
As a new user, it takes too many steps to add a new an address.
If my financial institution collected my phone number in a non-compatible format, there should be a flow that addresses that scenario.

User Task Flows
In the wireframe user task flows below, I prepared a routine for adding new address, re-using an existing address, incompatible phone number format.

OkCollect 2.0 user task flow.png


Tradeoffs and Key Design Decisions
Optimizing For Speed and Accuracy
On optimizing for speed and accuracy, I opted to abstract some of the complexities that might cause friction for users and may not be accurate representation of the current state of location.

Google Street View: The major constraint to using this feature is outdated data caused by rapid environmental and infrastructure change. For example, ABC street image was captured in 2016 when it was water logged and the residence partially completed but in 2021, the street and residence has taken a new shape. I decided to take out this feature for the first iteration of OkCollect 2.0 so as to focus on speed and accuracy by providing robust and clear guidance during data collection.

Current Location: Abstracted this feature largely because of the inconsistent addressing in Nigeria. An address that was “2, Financial avenue” two years ago could be “1, Allen Lane” now and the update not yet on the map. A practical example is where I currently stay had an old street name which is still on Google Map while the new details returns “location not found”. I decided to take out this feature for the first iteration of OkCollect 2.0 so as to focus on speed and accuracy by providing robust and clear guidance during data collection.

okcollect 2.0 (new address).jpg
OkCollect 2.0 (new user) - View clickable prototype


okcollect 2.0 (existing user).jpg
OkCollect 2.0 (existing user) - View clickable prototype



3. Invalid Phone Number Format: A corner case I preempted after reading the was a scenario when the phone number passed from the financial institution is in the wrong format. I took care of this by designing a flow where the phone number can be captured in the correct format and validated against the OkHi database to check if the record exist or not so as to determine the correct route for the user.

okcollect 2.0 invalid phone number (new user).jpg
OkCollect 2.0 (new user_invalid phone number format) - View clickable prototype

okcollect invalid phone number (existing user).jpeg
OkCollect 2.0 (existing user_invalid phone number format) - View clickable prototype



Conclusion
There will always be iteration for any product, because there’s no such thing as the best product, but there’s always a better product.

The plan is to always talk to customers and further iterate on the product to get a better version.

Want to print your doc?
This is not the way.
Try clicking the ⋯ next to your doc name or using a keyboard shortcut (
CtrlP
) instead.