cRM Shopping Cart

We launched the CRM desktop product in early 2019, and part of the MVP was a feature that allowed the user the ability to see open shopping carts created on the connected sales app or website. The cart page visible to most customers was for display purposes only, and had no actionable capabilities. A few customers did have the ability to create carts within the CRM product and complete those sales. However, with the adoption of the tool by high caliber customers, we needed to redesign the shopping cart and checkout feature to support more of our customer's business needs, and to ultimately facilitate the closing of more sales. 

I was responsible for working with the Product Manager to dissect and understand all requirements that needed to be satisfied, researching the industry standard, understanding the users who would be using these pages, and designing the shopping cart and checkout experience within the confines of our limited resources and timeline.

Initially, the project was scoped to use the existing design, just adding in the new functionality needed to support our customers. After diving deeper into the various areas of the existing shopping cart and checkout experience, I found the existing design and user flows did not utilize the given space well, nor would it allow for much of the new functionality that needed to be introduced. More specifically, the design pattern used had been created during a time when the product only served a limited type of customer, therefore it wouldn't serve the needs of our now expanded customer base, and would prove useless for those users. 

I first worked with the PM to understand all of the new functionality and requirements that we needed to build into the product. In addition, I also worked closely with our Senior Director of Development to understand all of the back end functionality that would be coded in, to better understand the interface that would need to be applied. I was important to understand the architecture that would be in place passing data back and forth, to know what sort of data would be coming and what would need to be displayed in the carts, as well as what sort of data would need to be collected on checkout. Once I had an understanding of what was currently in place, as well and the plan for what would be built in the coming release, I had enough technical information as a base to build upon. 

As part of the research phase, we had a screen share meeting with two of our champion customers for a gap analysis interview to understand the systems they were previously working with and what would need to be supported in our system to satisfy their business needs. Due to confidentiality agreements, I cannot disclose specifics, but we  were able to walk through common day-to-day activities their users would engage in and highlight the friction points we needed to ensure we avoided in our system. We were able to watch in real-time how the users would interact with their previous system and note both the merits of their old tool, but also identify areas where our tool could solve many of the problems they were previously facing. These meetings were invaluable when it came to understanding our target users better and served to further firm up our requirements and avoid any clumsy designs that frustrated our users with their past products. 

The next phase of research required me to firmly understand the cart and checkout UX on our other products, namely the sales app and website products. While the designs would not necessarily be exact, the experiences should not be wildly different. I needed to ensure that a user who was familiar with placing orders on the app or on the website, would have no issues placing orders on the CRM tool, and the experience would feel very familiar. I need to make sure the same functionality that existed in the other products be replicated in this product as close as technically possible, as well as any terminology and icons used.  

I first established the user flow I wanted implemented, which basically mirrored what already existed in the product, but would now incorporate a "split cart"/multi-shipment cart capability which would put users in a loop to the master cart until all shipments were closed. I kept the flow as streamlined as possible and included a one-page checkout experience to encourage completion of transactions without the need to go through a multi page process. 

Once the user flow was determined, I moved onto sketching different ideas for how the cart itself would be laid out to support the split cart functionality and need to enforce specific shipment minimums and shipment promotions. We had to shift thinking away from the idea of a cart total and focus on the individual shipments, as each shipment had to go through its own requirement checks before the order for that shipment could be submitted. There was a ton of complex code driving all of this functionality, but I need the interface to be as simple as possible and clear to the user who was trying to build carts and make purchases. 

I sketched a couple different cart and checkout options, but once I settled on the design I thought would best serve the user I moved to more formed wireframes. The wireframes were the result of the user interviews, sketches and two weeks of iterations. The iterations were results of internal design reviews with the Director of Development, the PM, key CSMs and the Senior VP of Technology. 

I was responsible for presenting the designs, back them up with key findings from our research, and take all design feedback into consideration and tweaking or re-working the designs as needed. From this process, much of the checkout design was changed from the original sketches to the final visual design. 

 During the research phase, of the key points our group of users mentioned time and time again was how important it was for them to quickly add products and build carts. They generally knew something about the products (the name or sku) and wanted a way to enter that information with as few key strokes as possible to get the products added to the cart. Taking this information I designed a tool that allowed for the user to enter partial information for 3 key data points that would work like a search bar and pull in the correct product. The additional data would be prefilled and the minimum quantity required for the product preselected as well. All the user would have to do is hit enter to add the product with the prefilled quantity, or enter the new quantity on their keypad before hitting enter. This design allowed for products to be added completely through a few key strokes, and no back and forth from mouse to keypad or between different screens. 

I created a prototype of this feature and the PM and I demoed it to a group of power users. These power users were chosen because of their use of the product and willingness to provide suggestions and feedback regularly. The prototype demoed well, and of all the users we spoke to they remarked how useful it would be and how much quicker they would be able to complete orders. It was during these demos we got feedback to add a notes column as many times when products are being added to a cart, product comments will be added for the supplier to address at the time of order fulfillment. 

We also included our popular "Add List" feature used in other products, where the user could paste in a list of SKUs and the system would add all available products from that SKU list to the cart and pre-sort them into the correct "splits" or shipments.
 

 During these design reviews a question was posed that highlighted a key blind spot in our original thinking of the product. There were certain scenarios, very rarely and only occurring for a handful of customers, that the requirements wouldn't satisfy. We needed to add a feature that would allow the flexibility for a set of defined users to be able to add products that might not exist in our systems and the ability to assign those "ghost" products key data values when adding the products to a cart. I designed a user flow that wouldn't be intrusive to those users who didn't have this functionality allowed, and for those that did, it would follow the same design patterns established in the general adding of products. Users wouldn't have to necessarily know they were adding a "ghost" product, instead the system would alert them of the special product and request additional pieces of information in the most streamlined way possible.  

Following the completion of the high fidelity wireframes, again we held several meetings with key customers to present our new designs for the cart and checkout experience. I created XD prototypes to use in the presentation to these customers. We got their notes and overall buy-in, which validated all the work we put into this project. The groups of users we spoke to were very excited to get access to the changes and continued to express how positively these changes would impact their day to day process. Hearing this feedback was affirming and just reminding me how much my designs and our products affected the lives of so many users.

One lesson that proves itself to always be useful is understanding the technology behind your products. This information was definitely helpful in making UX decisions, but also built a stronger working relationship with many members of the development team. This understanding of our data engine proved to be helpful in designs later on and gave perspective on how much is working behind the scenes every time a user interacts with the platform.

Since this project, we have started discussions around adding functionality to support completing carts synced from other products, not just those created in the CRM product.