My Work At Shapeways

In summer 2015, I worked at Shapeways, a Manhattan-based 3D printing manufacturer and marketplace. I was a member of Shapeways's front-end engineering team. During my time there, I built features in the order / purchase experience, and worked on a mobile responsive redesign of the checkout experience. In addition, I participated in several front-end architecture refactor projects and contributed to Shapeways tech documentation.

You can read more about the architecture initiatives I helped implement in my Medium post here.

I also worked closely with the UX team and was lucky enough to be able to participate in the design process of every feature I implemented. My time at Shapeways was a great opportunity to learn and grow in a variety of areas, and to try new things. I was also able to pick up and implement side projects, and work on them end-to-end. One such project, chronicled below, was a redesign of the order history page.

Redesigning "My Orders"


My onboarding project during my internship was to build an “order again” feature that would allow a user to place the entire contents of an order back into their cart. The “My Orders” page on Shapeways (one of the pages where I was placing the new feature) was one that hadn’t received a lot of attention as Shapeways continued to move forward with modern, cross-platform web development. When I implemented that feature, “My Orders” looked like this:

Although the page contained a great deal of information, it was difficult to parse and understand. The only real action call on the page was the “order again” feature I had just added. Furthermore, the page was not mobile responsive. The underlying code was also somewhat outdated, and did not make use of the new architectural patterns the front-end team was using. Since Shapeways offers monthly “lab days” where the software team can work on whatever projects they want to, I decided to try to make some improvements to the “My Orders” user experience.

The Problem


Shapeways is unique as online marketplaces go in that it caters both to 3D makers and large businesses, who tend to order in bulk or order the same items hundreds of times, and marketplace shoppers, who tend to buy individual items just once. Many parts of the site must therefore strike a delicate balance to maximize usability for both groups. “My Orders” is one such place  — useful information for both shoppers and makers needed to be surfaced on the page. While makers and business owners tend to have many orders, keep track of them by information like order number and invoice number, and need to scroll through orders quickly, most shoppers organize order by placement date and items purchased, and tend to want quick access to shipping information. We collected this information on needs and behavior through a combination of forum comments, feedback from strategic accounts, and direct conversations with Shapeways users.

Brainstorming


I began my design process by asking myself one simple question: “Why are our users visiting this page?” I wanted to know what our users needed from “My Orders” and what obstacles were currently in their way. Based on the information I received, I compiled the following list of reasons why users visited the “My Orders” page:

While the first and second items are relevant for all Shapeways customers, the third and fourth are primarily important behaviors for makers and business owners. As a result, the most common marketplace order history model, which surfaces individual item details directly on the order history, would not be a good solution for Shapeways. While this method is great for individual shoppers, for shop owners, who make up a large portion of Shapeways customers, order information presented this way would be repetitive and inefficient. The problem I needed to solve, then, was to surface appropriate action calls for individual shoppers, while simultaneously maintaining useful and easily navigable order information for makers and business owners.

Implementation


Now, having decided that I needed to present both action calls and order information, the next question I asked myself was “what elements does each order summary on the page need?” Both shoppers and makers need distinctive information to differentiate between orders, and the old “My Orders” format with all its labels at the top and its plethora of dates and ID numbers didn’t seem to present that information in a useful or easily navigable way. Furthermore, though each order summary contained many clickable elements, none of them were genuine calls to action, nor did any present useful information about what the link would lead the user to. I thus divided necessary elements into two sections:

I then created my first wireframe. I decided to use a mobile-first approach, and arrived at this:

I decided to identify orders chronologically by placement date, while keeping shipping information and action calls grouped and surfacing “order details” as the primary action call closest to the user’s thumb. For the desktop view, I tried not to depart too radically from the original table view:

Iteration


After receiving feedback I realized, however, that this iteration left a great deal to be desired in its desktop view. Though there was some increase in clarity and actionable items, the desktop view suffered from the same lack of information hierarchy that plagued the original design. Order information was nowhere near the associated action calls. Furthermore, I realized that shipping information, which I had listed as a primary use case for the page, had limited emphasis, and was squished confusingly between information and information-related action items. I decided to return to my initial statement of intent, and reevaluate what I was emphasizing. The result was this:

I decided to drastically increase emphasis on those actions and pieces of information that are important for all customers, namely shipping information and order details. I significantly increased the emphasis on shipping information, choosing to identify orders by their shipping and processing status, rather than their placement date. I also increased the emphasis on the “track shipment” call to action, and scrapped the table format in favor of modules with orders still in processing visually distinguished. I felt that these additions would make it easier for all Shapeways customers to find the information they were mostly likely to want / needed as rapidly as possible. I also grouped order information with information-related action calls, so that makers and business owners would be able to find all the tools they needed neatly in one place. On mobile, my new view looks like this:

My second design solidified and emphasized important information and actionable items for marketplace shoppers, while still keeping information and actions for makers and business owners easily accessible and navigable. It also clarified visual structure by arranging orders into modules, rather than visually confusing table rows and columns.