Scotiabank MVP
This project was a part of a special section of the CSC209 System Design course as part of the Technology Leadership Initiative (TLI) cohort at the University of Toronto. Working in conjunction with coaches and industry professionals from Scotiabank, we were tasked to develop an MVP that challenged the traditional Buyer-Seller-Delivery relationship by the inclusion of a Request-To-Pay API – an instant payment system.
Task
Develop an MVP that challenged the traditional Buyer-Seller-Delivery relationship by the inclusion of a Request-To-Pay API – an instant payment system.
The brief was for a request-to-pay system to facilitate the transactions between three user types – a Buyer, a Seller, and a Driver. I developed three personas reflecting these user types, each requiring different types of information and interaction with the app will need to be considered uniquely in the app.
Brenda is a Buyer.
She runs a small convenience store near campus. Brenda has many suppliers for the various goods she sells, including CocaCola. She is not always at the store, but she manages the inventory by making regular orders and signing off on payments to each supplier.
CocaCola is a Seller.
This is a large business that supplies small businesses with supplies of their product. CocaCola has an online vendor website that takes in orders, accountants to take care of the financial transactions, and a fleet of drivers to deliver the goods. This is not a single person, but a corporation.
Dan is a Driver.
He works for CocaCola, delivering goods from one of several CocaCola warehouses to the customers. He doesn’t have an office – his truck is his workspace. He checks in at the warehouses as necessary.
Traditionally, this would involve a Brenda placing an order through CocaCola’s online vendor platform, CocaCola processing this order and returning an invoice, and then assigning Dan to deliver with the goods from one of the CocaCola’s warehouses to Brenda. Upon receipt, Brenda would then give a payment (cash or check) to Dan, who would then return to the CocaCola warehouse to drop off the payments. An accountant at CocaCola would then process the payments and balance the books.
There are a lot of moving pieces between the users – a lot of things being delivered back and forth, and a lot of checks and balances to make sure the process is going smoothly.
In our MVP, we developed a system where the Request-to-Pay system would incorporate the invoicing and payment, simplifying the entire flow. Less checks and balances are needed.
With less points of friction, the Scotiabank RTP can simplify the process of fulfilling an order. With electronic banking standards and accessibility of technology (this mobile app), each user has significantly fewer things to handle.
To translate the simplifications of the User Flow to design of the software, I proposed a system of three statuses: Accepted, Paid, and Delivered. These then define the four states of any order, and can define what each user type needs to address.
- Accepted
- Paid
- Delivered
This LoFi prototype allowed for a clear delineation of the User types, as well as a clear flow through each order status. This informed the subsequent development of the app in React by provided a document of the views and transitions needed between users and statuses, but also a reference for developing a backend schema appropriate to track and modify statuses
For example, both CocaCola and Brenda will need to know all three states. Brenda might need to consider all four states, since she may need to track open orders, unpaid orders, or undelivered orders.
CocaCola needs only to consider if the order is Accepted and Delivered, since an order won’t be delivered unless it is paid for.
On the other hand, since Dan is no longer delivering payments, he is only concerned with Delivered.
As my role was focused on the UI/UX design and its implementation in code, I chose to first develop HiFi prototypes in Figma to really understand the user experience in an interactive form. This allowed for an easier iterative approach to shaping the design. Testing these prototypes with the group also allowed for impromptu Usability tests, and rough edges were more easily refined.
As the prototype illustrates, the flow of users begins at a login view, whereby the user is transitioned into the appropriate homepage based on their credentials. Our app allows for a user to be any number of personas, so additional sections are populated as needed.
Following Scotiabank’s Design Guide, I decided to go for a simple and bold aesthetic. A strong image fills the screen. The Scotia branding remains fixed at the top left in white. Each view has a single accent color, utilized for headers and menus. Any background (without images), would be a gradient off of the main accent.
To distinguish the set of views for each persona, each user type employs a distinct (and bright!) colorway. All child views retain this identity, utilizing a similar swatches and gradients to mark the usage.
The Buyer views in orange show the Options available, and an example of the Order invoice. At the bottom, a row of icons provides a visual representation of the order statuses.
The Deliverer view illustrates information pertinent to a delivery – the address and an interactive map to guide the driver.
The frontend was developed in React.js to create the interactions, transitions, and necessary database calls. We chose a responsive web app rather than a native app for its flexibility.
With my background in design, I lead this part of the project, working extensively in Javascript and CSS to create the desired views. To populate the views, I worked with Dakota to develop the database calls, and means to parse the JSON data returned into viewable information for the User.
We laid out the architecture and design-patterns for the project – we would implement a Model-View-Presenter structure, whereby we could interact with the database and manage the appropriate views based on the active (logged in) Persona.
The final product tracked an order’s status from placing an order to its completion. This corresponded with visual cues in the front end design, as well as mobile notifications added by the back-end team utilizing Twilio.
The MVP was presented to a panel from Scotiabank, and was well received. Notably, we received great feedback highlighting our carefully thought-out architecture, a strong backend with an adaptable API, and a stunning user experience.