Order Writing

Our Sales tool consisted of a mobile app and a web app. The web app was meant to serve Admin users as well as Sales Reps, but the Reps were expected to use the web app differently than they would their mobile app. Through research we found that Reps almost exclusively used their iPads or phones to take orders for their customers, but would sometimes be forced to or prefer to use their computers when not on the road. Many times Reps would have order requests emailed to them or a customer would request a reorder of a past order they placed. In those instances we found, through user interviews, that our reps would want to be able to easily place a reorder, or have an interface where they could type in a list of SKUs and quickly build the order that way.

I was responsible for working with the Product Manager & Business Analyst to dissect and understand all requirements that needed to be satisfied, working with the Tech Leads to understand the development &  architecture constraints, research the industry standard, understand the users & really live their problems, and finally, design the cart and checkout experience within the confines of our existing design system, approved mobile flow,  resources and timeline. 

 Sales Reps entire livelihood is based on commissions. The more they sell, the more they take home. Writing orders is the #1 most important thing to them. Of course, they want to write large orders and they want to write orders for quality customers, but at the end of the day they only survive if they are meeting their sales goals and writing orders consistently. This requires a system that is reliable, efficient, and error-free. Here-in lies the need: As a Sales Rep, I need to start, build and finalize orders in the quickest & simplest way possible, without any errors, on any device I choose, at any point in the day.

 After establishing the basic user flow, I started sketching some ideation sketches of what the application could look like when translated digitally. I went through a few different versions, before settling on the best option and moving to low & mid fidelity wireframes. We used the wireframes to do the initial rounds of usability testing with internal stakeholders, and trusted industry vets. 

The rounds of testing always resulted in various iterations. For example, we went from "complete order" to "Checkout" to "Finalize Order" after many discussions on what those words meant to the end user. We also reorganized the data shown in the product cards to be present in a more logical way, with the quantity picker moved to the right-most position. We also determined that the layout wasn't being utilized to it's fullest potential, so we introduced a right panel  to hold the order summary information, leaving the left side entirely for the cart and it's actions. Finally, we had early discussions with the Tech team, and they informed us we had to stick to the establish header designs in the design system, so we had to rework how we would display the customer & active cart information. After the various iterations, we got a place we felt the application was ready for high fidelity mockups to be taken to a larger audience.

When designing the order writing interface, we had to take into account the mobile app's design patterns and flows. We didn't want Reps to log into the web app and be completely confused. The web app had to feel like an extension of the mobile app that they were using day-to-day. In addition, we also had to stay within the design system that we used on all the other Admin-style web apps that already existed in our product suite, which the mobile app didn't have to adhere to. To accomplish this task, we used the same design system and components throughout, but adopted the green banding, the same copy, and same user flows that the mobile app was planning to use. We also created variations to some of the existing web components to match more closely with the mobile app, like the quantity picker and add to order buttons.

Unlike the mobile app, the web app was not going to have support for Bluetooth scanning to add products to an order. Instead, the web app would utilize a product search bar that would allow the user to type in the Product Name, Product ID or UPC to pull up results and add directly to the order. We also wanted to add support for those users who preferred to add product via the product catalog, or browsing state. In our research we found it was about a 50/50 split of how users generally built orders, so we knew it was important to allow for both in our interface and make them equally efficient. 

Once the basic design was set in the cart itself, we had to start considering the various actions that would be available in the cart: adding discounts/upcharges, emailing a copy of the cart, changing the shipping address, adding notes to the products, etc. Each features that was included went through their own rounds of testing. We tucked many of the actions in the more menu, in an attempt to keep the interface as clean as possible, especially once we validated that the actions weren't consistently used. For other actions, like adding notes to products and deleting a line item, we utilized hover states and colors to show enabled actions vs. disabled actions. Unless the user was directly interacting with a product card, the delete and add /edit note function was greyed out, to help minimize clutter and keep the layout from feeling busy or messy. 

Finally, we had to consider the post MVP design as there were multiple fast-follow features we would begin working on immediately. We knew from research that Sales Reps regularly had multiple orders open at any given time with a customer. They might have different orders for different seasons, or for different store locations the customer had. Either way, we needed to support the ability to have multiple carts opens at once, and a simple way for the Rep to bounce back and forth between the different carts. We designed a top bar that would allow users to quickly create a new cart for the user, as well as display the open carts in a pill form that acted like tabs, a pattern we believed would be recognizable to our users. In addition, we introduced multi-select to support line-item actions we knew the users needed to enhance their order writing experience: line-item discounts, moving items between carts, etc.

We performed extensive user research through unmoderated usability tests and user interviews. Through our usability tests we found problem areas quickly and were able to iterate until we found a solution users were able to easily grasp. We were also able to test both the web app and mobile app side by side to ensure users could easily switch between the two to accomplish tasks. We would have users start an order on the mobile app, and then find and finish that order in the web app. Our research findings were paramount to the design and development of the order writing part of the application, because that was the main feature of the Sales tool, and without a simple but powerful interface the app would have been useless.

Users consistently commented on the ease of use and attractiveness of the interface, validating our design decision with every new feature we added. A couple highlighted quotes from feedback surveys are below:

• "I want this in my [current application]!!!! Love having full ordering functions"
• "This is so far above what my [current application] can do, I'm amazed."

We of course did not only get positive feedback. Our research participants were very helpful in providing insight into areas we needed to improve the experience. Before we landed on the delete line item design we tested another version with Reps, and we found they did not like the design at all, as the actions were too close, and in their experience they had trouble with interfaces when things were too close together. We went back to the drawing board and ended up with the version seen above. 

From our testing we also found hints of learned behaviors, which we used to help plan our initial first-day tutorial screens. For example, users would initially miss the more menu button at first, but once they opened it for the first time, they would always remember where it was and the actions it contained each time we tested them on it again. We were able to use heatmaps and time-on-page variables to quantify this (first time task took an average of 29 seconds, but second time took an average of 4 seconds), as well as interviewing the users. This told us that if we highlighted the more menu during our first-day tutorials we could mitigate any friction ahead of time, and know that our users would remember it going forward.