Transfer of Ownership MFE
This project became a priority for Storable because a lot of time is wasted among our implementation and support staff as they administrate the process for buyers and sellers to transfer storage facilities among each other. The reason this was a priority was because it was extremely common at Storable for these buyers and sellers to be moving from one of our FMS (Facility Management System,) softwares to another we provide. The buyer and seller process was loosely managed through salesforce, but the primary mode of communication was email or collecting data through disparate JotForms.
From research, the released feature solves a set of user's needs. The released MVP is rooted in web standards, usability backed by user testing, and aligns with a platform level design system backed by a react library.
In brief, the transfer process looks like this:
1. Buyer contacts Storable about an upcoming purchase
2. Storable Admin selects Buyer/ Seller
3. Seller is notified and provided a unique URL and access PIN. They then confirm buyer and selects facilities
4. Buyer is notified and provided and unique URL and access PIN. They confirm the facilities and then select their implementation options.
The process for this project looked like this:
The below screenshots capture the overall aesthetic and experience of the buyer/seller service. The screenshots below are used by the Storable Admin to initiate the sale process.
For MVP, the admin must manually send the buyer and seller the unique URL and access PIN to enter the transfer process. This manual workflow in MVP2.0 would be fully automated. This page is considered the Transfer Details page and in its future state will reflect at which point in the process the buyer or seller are.
For sake of brevity, I have only included the Buyer View of the MVP. The Seller's view is similar but simpler. It allows them to select which facilities they are selling and confirm the buyer is correct. At the point shown below, the buyer is able to start the purchasing process and confirm the seller, facilities, and then select their implementation options.
.gif)
Before I was shifted onto this project, the project was delayed by multiple months do to an eroding relationship with an outside agency. For this reason, the MVP needed to be built in as little sprints as possible, and whatever code was implemented needed to be removed/ rewritten. I had created mockups for the overall user flow, but our team agreed it would be best to fine tune the small things later. The screenshots below show what was actually built.
There are obvious discrepancies between the mockup and deployed MVP. One such discrepancy are the styling of labels used to display transfer status.
A difference in the selection process is the use of a hyperlink to select the buyer rather than the use of a radio button. Across the Storable product suite and amongst us product designers, we decided that links take one somewhere else whereas buttons work as actions. In this use case, a radio button for selecting the buyer, then a button for proceeding in the process is the agreed upon interaction pattern.
Much like the previous two examples, the transfer details page can improve. However, for now it serves its purpose. As soon as MVP2.0 or MVP3.0 much of this page will be for dealing with exceptions within the process and the process will be mostly automated.
In creating the MVP, additional desired changes or new requirements were uncovered through implementation and user testing. Some of these were:
The possible status' are: New, Canceled, Sent to Buyer, Sent to Seller, Draft, Confirm Pin, and Completed
For the labels, blue is used as a neutral status color. Grey is used for drafts, red for canceled, and green for completed transfers.
.png)
A unique part of what we built is that the transfer details page is used between all three user types and can be accessed, when there are no tasks to complete, by the buyer or seller through their unique URL. For them, this page acts as a status page for where in the process the transfer is. If needed, they can manually remind the buyer/seller to complete their portion. For Storable Admins, this page acts as an area where they can manually find transfer details, if necessary override or cancel details or the transfer entirely.
.gif)
A shift in the mental model of the transfer process is the introduction of a "confirmation purchasing pin." In the past, a form called the "Release of Data" form was used to finalize the transfer. Now, a seller is provided a PIN once the buyer/seller have completed all their forms. Then when they desire, they provide that PIN to the buyer to enter at their Transfer Details page. This is a challenge because many large corporations are very familiar with the current transfer process, so introducing this new way of confirming a sale posses a risk. Introducing will make the transfer process more seamless. Instead of the Release of Data form being used as the final step, this form is then just inserted into the Seller's transfer workflow.
.gif)
Before this effort, the transfer process between buyers and sellers required a lot of manual effort. Before, the onus of work was on Storable employees. This experience is the first of many time saving efforts being introduced at Storable to provide better user experiences for our customers and streamline our internal workflows.