Sharp Type
Sharp Type is a NYC-based type foundry that has worked with Dropbox, The Hillary Clinton 2016 Presidential Campaign, Time, and Samsung. While I was with Type/Code, we were contracted to redesign their ecommerce storefront.
My Deliverables
Precedent Research
Interaction Design
Wireframing
UX Writing
Usability Testing
Handoff to UI Designers & Developers
QA
Timeline
~6 months
Problem
Sharp Type’s original storefront was constructed at a time when the foundry had a much simpler product offering. When we were brought on, they had outgrown their original site both in terms of how products were presented and organized on the storefront and how products were managed by administrators. Our primary goal was to create a new ecommerce system that helped customers better access their product offering and was more easily managed by administrators.
Project Summary
My focus within this project was split into two areas: the product browsing and purchasing experience for the end user, and the product page, orders, and customers management experience for the site administrator. For both of these areas, I performed precedent research, interaction design, wireframing, usability testing, and created extensive annotations and specs for handoff to UI designers and developers. In the weeks leading up to launch, I collaborated with the development team to create and test many QA scenarios.
Discovery
I began contributing to this project late in the discovery phase. Before I joined the team, the discovery process was nearing completion and a discovery document was being created. Here’s a summary of what we learned:
High Level Project Objectives
The shopify system used to manage Sharp Type’s previous web store was wildly inefficient. It could take hours to implement a price change across a typeface or update font files. Stakeholders needed a solution that streamlined store management to reduce time waste.
The previous customer-facing portion of the site was designed to present a handful of typefaces with simple product structures and licenses. At kickoff, the foundry had more than a dozen typefaces with 100s of different products spread across their offering along with a need for a modernized licensing structure. Stakeholders required a solution to better communicate their updated product offering to customers.
User Needs
Admins
Quickly manage/update font products
Quickly adjust prices across the store
Create and manage orders
Create custom orders for users seeking usage rights not covered under standard licenses
Manage customer accounts
Manage administrator accounts
Create and manage discount codes and sales
Reduce time spent creating/customizing EULAs
Collect data relating to customer acquisition
Storefront Users
We weren’t able to talk to these users during the discovery phase, but we formed a series of assumptions about their needs based on info from stakeholders and our collective experience shopping for fonts.
Find and purchase the correct font licenses for their use case.
Understand the costs of different font licenses
Try the font before purchasing
Download fonts after purchasing
Access past purchases to redownload fonts, EULAs, Invoices.
Ability to purchase many fonts with multiple license types simultaneously.
Share purchased font files with others.
(discovered conducting additional research) Share license/font selections with a manager or client so they can pay for the order.
Precedent Research
My first major contribution was precedent research. I looked at dozens of typography ecomm sites with the goals of (1) learning general design patterns for type stores and (2) finding specific design solutions that solved similar problems to what had been identified in discovery.
Findings - Admin
Shopify & Stripe
I used both of these products extensively to learn design patterns for ecommerce store management. These platforms informed many design decisions for customer and order management.
Findings - Customer
The ‘buy’ page displayed all typeface purchase options in a condensed and easily digestible format while providing adequate previews of each font weight & style.
F37 (click the ‘add to cart’ button on the linked page)
The font license selection / add to cart flow occurs within a modal and could allow for more specific license selections (fulfilling an identified need for buyers) along with minimizing confusion around what a user was adding to cart. This pattern wasn’t used in initial sketches, but was drawn from later in the design process.
Klim (add an item to cart to expose the cart)
When adding items to cart on desktop, the cart remained exposed on the page allowing users to see a breakdown of the licenses they had selected and adjust in real time.
Camelot (see the left portion of the screen on desktop)
When adding a font or typeface to cart, users are allowed to select multiple license types (desktop & web) to add to cart simultaneously. While this concept was implemented in an unintuitive way on Camelot, it satisfied the need for flexibility of license selection for buyers that we kept hearing from stakeholders.
Site Map
Our first activity after completing discovery was to create a site map to start thinking about how we were going to solve identified problems. Under each high level node, we identified specific features we planned on designing into the product. I didn’t have full ownership over this deliverable, but I’ve included it to set up my design solutions.
Admin Sections
Products
Within the products section, we scoped out features that would allow admins to quickly update font products that appear in the store.
Customers
Within the customers section, we included features to create and manage customer accounts and view data associated with each customer.
Orders
Within orders, we scoped out functionality that would allow admin users to create and manage orders in addition to creating custom orders for obscure licensing situations.
Discounts
This section was scoped to give admins the ability to create shareable discount codes for sales and other individual use cases. (gifting products, etc)
EULA & Pricing Settings
Within this section, we planned to introduce a dynamic markdown system allowing admins to automatically generate EULAs for each store transaction.
Additionally, we also noted a plan to include price controls by license type across the store.
Admin User Settings
This section was included to give admins account controls. The greyed out nodes represent a V2 feature that was designed but not implemented.
Customer-Facing Sections
Typeface ‘Buy’ Section
For product pages, it was decided that we would keep their previous typeface marketing content and add a new ‘buy’ module underneath.
Cart
The cart section scopes out our plans to give users cart control at a high level.
User Profiles
This section includes features that allow users to view past purchases and download fonts, EULAs, and invoices (included later). We also included basic account controls and ability to edit saved payment methods.
Checkout Flow
Within this section, we scoped out all things that would be required for the checkout process. The only big addition over a standard ecomm checkout experience was an extra form to collect licensee info for automatic EULA generation for each order.
Wireframing
I started the wireframing process by creating multiple concepts for administrative sections and moved to designing the customer-facing experience shortly after.
In each pdf below, I’ve left out a few screens covering edge cases and future features with functionality that were not included in the site at launch.
Admin Sections
Customer-Facing Sections
Usability Testing
During the wireframing process, many questions arose while designing the customer-facing experience. I conducted multiple usability tests using 2 versions that had been designed. I am unable to show these versions in their entirety, but have included a link to the script and a findings presentation which contains the most critical screens of the flows I tested.
Test Logistics
7 participants were recruited and shown 2 versions of the flow in random order. Version 1 consisted of the add to cart and edit cart views appearing over the cart on the right side of the screen. Version 2 consisted of a modal appearing when the user added an item to cart or edited an item in cart. The tests were facilitated by myself and another UX designer and were recorded. After testing had concluded, I created a research report and presented to the client.
Results
Version 2 performed best and most closely resembles the final wireframes viewable in the “wireframing” section above on this page. A few of my other design decisions across both versions had room for improvement:
In earlier versions, I had designed a system that included automatic product bundling (ex. if a user adds individual fonts to the cart that are part of a font family and the individual fonts in cart add up to be more expensive than the family, the fonts are booted and the family package is added) that was not well received by users and was removed. In hindsight, this feature was a clear violation of a few design heuristics (visibility of system status, user control & freedom) and should have been removed earlier.
When a user added an item to cart, icons signifying that item was in the cart appeared in place of the “add to cart” button. This was confusing. The display of icons was adjusted and an edit button was added when items were in the cart.
We discovered that users working on freelance design projects or projects at an agency wanted the ability to share their cart with a manager or client and have them complete the purchase. After discussing with my manager and syncing with the development team on functionality, I added a share cart feature to the product.
Much of the UX copy on both versions performed poorly and was improved (ex. “Adjust License” -> “Edit Selection” -> “Edit”).
Dev & UI Handoff
All flows were annotated as wireframing was nearing completion. These final annotated screens were compiled and uploaded to an Invision deck for internal use and shared with the UI design and development teams.
QA Testing
As development was nearing completion, I began collaborating with the development team to identify and correct bugs. Over the course of a few weeks, I created more than 100 QA scripts and resulting bug reports within JIRA and worked with the lead developer to prioritize bug fixes.
Product Launch
The site launched in September of 2019 and has been considered a success by the client. Unfortunately, I never had access metrics related to performance of the storefront pages, but the client was satisfied with the final product and reported considerable time save with admin pages delivered.
Learnings
The scope of this project was an order of magnitude greater than anything I had done previously, and because of this, I wasn’t prepared for some of the challenges faced along the way. Here are some of the things I’d do differently if I had to repeat this project:
Work through as many interaction design problems as possible before working on screens.
Before this project, I had worked primarily on informational sites with simple functionality. I learned the importance of working through flows at a high level before diving into wireframing.
Collect sufficient info on stakeholder needs and technology constraints.
As the project progressed, it became apparent that many assumptions made around stakeholder needs and technology constraints were incorrect. I ended up designing and redesigining a few sections because the needs of the client were more complex than we realized during discovery and our third-party payment tool was not as flexible as anticipated when UI went into development.
Maintain Sketch File Hygiene
If I hadn’t developed a naming schema and artboard organization strategy early on, handoff to UI designers would have been a nightmare as I the sketch file ballooned to hundreds of screens near the end of the project.