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

ecommerce⁠

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.

⁠

⁠

user flow tasks⁠

⁠

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 user) - View clickable prototype

here⁠

⁠

⁠

OkCollect 2.0 (existing user) - View clickable prototype

here⁠

⁠

3. Invalid Phone Number Format: A corner case I preempted after reading the

OkHi Integration Best Practices⁠

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

here⁠

⁠

okcollect invalid phone number (existing user).jpeg

⁠

OkCollect 2.0 (existing user_invalid phone number format) - View clickable prototype

here⁠

⁠

⁠
`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.

Designing OkCollect 2.0: Case Study

Introduction

Project Brief

Feature Set

User Story

Existing User

New User

Approach

Riskiest Hypothesis

User Testing OkCollect 1.0

Data Gathering

User’s Problem Statements

User Task Flows

Tradeoffs and Key Design Decisions

Optimizing For Speed and Accuracy

⁠View Clickable Prototype⁠⁠

Conclusion

⁠
`View Clickable Prototype`⁠
⁠