Facility Transfer for Storage Operators
Project Overview
A lot of time is wasted among our implementation and support staff to administrate the process for buyers and sellers to transfer storage facilities. At Storable buyers and sellers often moved between our own softwares. 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:
- Buyer contacts Storable about an upcoming purchase
- Storable Admin selects Buyer/ Seller
- Seller is notified and provided a unique URL and access PIN. They then confirm buyer and selects facilities
- Buyer is notified and provided and unique URL and access PIN. They confirm the facilities and then select their implementation options
Process
The process for this project looked like this:
- PM created rough version of a new form and process
- Misaligned mock-up created by a design agency (That did not adhere to our design standards)
- I was engaged as the agency was shifted off the project
- MVP High-Fidelity Mockup Made
- MVP Released to Select Customers
- MVP2.0 was designed for automated future state
MVP Mockup
Admin View
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.
Buyer View
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)
Released MVP
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. 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.
MVP2.0
In creating the MVP, additional desired changes or new requirements were uncovered through implementation and user testing. Some of these were:
- Status Labels align with the Storable Design System.
- Use the Transfer Details page as a place for the Buyer/ Seller/ and Admin to view more in depth details about the transfer and hide/ reveal information based upon role.
- Ability for the Buyer/Seller to remind Buyer/Seller that the form needs to be completed.
- Include useful links related to the Buyer/ Seller: Salesforce Case Link, Facility Account, Facility Asset, Parent Account, Related Contacts, and other necessary forms.
- Introduction of a new mental model for Sale Finalization.
Status Labels
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)
Transfer Details
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)
Buyer Confirmation PIN
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)
Final Thoughts
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.
