Creating a more efficient path for users to purchase on arrow.com
The challenge was to bring Arrow.com into a typical eCommerce buying experience. From the initial glance the project seemed simple. As a new designer hired to a global billion-dollar company, how naive could I be? Well… The answer is quite a bit.
After meeting with my PO in a kick-off meeting, I began to setup one-on-ones with people who managed backend data feeds, inventory feeds and management, and frontend developers, to better understand the complexity and of how these departments contribute to the user’s experience on the Product Detail Page. A key takeaway from the conversations was around how Arrow.com leveraged certain technology, processes, and framework from Arrow Core (B2B platform) to get the website up and running. This made the time to market much faster but came along with many pain points and issues that the teams would have to fix later working cross-functionally with the Arrow Core teams.
A behavioral tendency I found interesting was around half of the tested users rendered their attention to the product details/spec table to find answers regarding part specific purchasing information. This could be due to prior expectations, learned behavior from our competitors, and/or unfamiliarity with Arrow.com. Though, the biggest caveat to the user making a purchasing decision relies heavily on if the part is in stock with the desired amount and immediacy. After the second phase of single buying options was deployed we saw an increase in add to cart, higher conversion rate, and lower abandonment rate and time on page.
In this particular example, three different buying journeys are presented to the user: In-stock (Buy), No-Stock (backorder), and Request Quote (call for price), all of which are separate inventories displaying their own data, individual experiences, and design hierarchy. Currently, arrow.com presents all potential buying options, and SKU’s to the frontend based on the data coming from the inventory feeds, which is creating confusion, large abandonment rate, and an overall bad experience.
To further confusion, “backorder,” and “call for price” CTA's are the same experience, a form sent to customer service. The process is lengthy and convoluted.
The research phase began with a competitive analysis of other eCommerce component distribution sites. The eCommerce sites that were analyzed (Digi-Key, Mouser, Avnet, Octopart, Newark Element 14 and Premier Farnell ) were all similar in theme and content, so it was essential to understand any differences in user experience when purchasing and sourcing components. Analyzing, then synthesizing the data helped me understand the ideal approach that Arrow.com should work towards in a lean Agile iterative process.
With the requirements defined, I was able to establish a clear visual hierarchy throughout the buying journey and keep all content and user interactions consistent across the board for web to mobile. While this analysis helped me create an experience that would make the platform stand out from our competitors, diving deeper into best practices for e-commerce web design led me to conclude the following:
Being tasked to update a purchasing journey can be complicated. As part of my process, I like to diagram all use cases in order to drive a proper strategy and approach under the constraints of the current system and data being fed to the user on the frontend. After validating all use cases, I pulled GA data to provide weight to each use case. This provides the team and stakeholders opportunity for prioritization if time and/or money becomes an issue.
Below are the various purchasing scenarios, along with the various types (request/call & limited stock/potential) of a-typical buying experiences and data supported, which can be due to legacy systems, bad data or business rules. Working with various stakeholders created an understanding of knowledge and paths forward to limit confusing and friction on the frontend.
Below is an example of all the message codes that Aegis and Unity, arrow.com’s inventory management system, housed for part and pricing information. Some of which were presented to the frontend and some weren’t. One of the biggest challenges I faced was trying to align the data being fed to the user to create a consistent journey.
With the preliminary research complete, I took the findings to help define requirements then proceeded to sketch out concepts. I enjoy this particular step in the design process because it allows me to work through complex journeys & experiences by putting down ideas rapidly, document questions & experiences I need to get feedback on, and drive a baseline experience from the user’s vantage point in order to user test.
Below visualizes me working through what can be considered primary and secondary purchasing information, how to organize the pricing info, purchasing scenarios, how will the user engage with the other inventories, what is the least amount of information needed in the journey to add a part to cart, arrangement of package types and displaying availability message codes.
Bringing together business goals and proper UX strategy shaped the iterative MVP approach by creating primary and secondary purchasing experiences. In a 3-phase approach, below is an example of phase 2 of the product detail page implementation on Arrow.com.
100% of user found the new Single Buying Options (SBO) purchasing process more intuitive, efficient and effective when purchasing parts.
30% of users were confused whether to click on the packing type checkbox first or enter a quantity in, especially when two packing types were present. Though, once the users were familiar with the purchasing process it became a natural experience.
When user's landed on a PDP that has both package types, cut strips and reels, 60% of user's do not see reels. Therefore, the user would not see the interactions happening below when adding that package type (reel) to cart in the single buying options section.
Another behavioral tendency I found interesting was around 50% of our users rendered their attention to the product details/spec table to find answers regarding part specific purchasing information. This could be due to prior expectations, learned behavior from our competitors, and/or unfamiliarity with Arrow.com.
Bringing together business goals and proper UX strategy shaped the iterative MVP approach by creating primary and secondary purchasing experiences. In a 3-phase approach, below is an example of phase 2 of the product detail page implementation on Arrow.com.
