Updating and Improving Checkout

Tarot.com eCommerce Update

Teaching Old Pages New Tricks

Upgrading the Workflow and Layout of Checkout Pages and Refining Digital Currency Offerings

Tarot.com was working with the same code base and a small variety of different user-facing checkout pages on its library of custom divination reports and readings for many years. Too long, in the opinion of project stakeholders. With a back end upgrade to Braintree underway and an ongoing, incremental mobile rollout, the timing was right to revamp and improve the checkout experience.

Improving the Workflow

Lacking documentation from any previous iteration, work began by surveying the various report purchase processes on the site. While clearly a result of the site's longevity, some of these workflows had significant differences from one another.

In the course of my heuristic review, several trouble spots became apparent that would need to be accounted for in the new checkout workflows. Chief among these was the lack of a guest checkout option. This issue was particularly glaring during the user research that followed my audit.

Fig. 1: Proposed Tarot.com Checkout Workflow

Satisfied with what I understood about the report checkout process after my audit and bolstered by the feedback I gleaned from running a structured test (the task: starting on the Tarot.com catalog's main page, find a product you like and purchase it), I set about sketching and refining my proposed workflows.

My goal was to synthesize the various elements of the different product tee-up and checkout pages, keep track of any glaring needs once the wireframes began, and introduce improved functional elements to the purchase process. On a workflow level, these proposed improvements included such things as integrated saved user profiles, saved (and savable) credit card information, better post-purchase notifications, better email support (e.g. receipts and purchase follow-ups), and the all-important guest checkout.

On subsequent stakeholder review, most of the proposed features were improved. Some, such as the saved cards and better receipting, were now feasible as a result of using Braintree, while others, such as the post-purchase follow up emails and improved user profile support, were only a matter of ensuring it was taken care of in the UI design and front-end development stages.

The only feature that was not approved was the support for guest checkout. Simply, stakeholders decided this was not a desirable feature and preferred that purchasers by necessity create a Tarot.com account in order to view their reading or report. That decision was to affect how the product tee-up pages were to be designed as the project progressed.

Layout Considerations and Scope Restrictions

With the workflows finished and approved, work began on the design and layout of the pages. Since Tarot.com works on a 1:1 product to purchase model, there is no typical shopping cart experience to account for. Instead, the most important factor was to make the information about the readings and reports clear and the purchasing step simple and seamless.

While Tarot.com operates a separate desktop and mobile site, one of the goals maintained by both the creative director and myself was to build in responsive functionality to these new pages. The reasoning was future-proofing the work. When and if stakeholders wanted to change the direction of their content strategy and go with a single, unified site, the functionality would already be in place.

Concurrent with the ecommerce update was the ongoing visual update to a flat UI design style and a rebranded color palette. While the creative director, the marketing director, and the general manager worked out the color schemes, I was tasked with making some UI design choices such as form elements, buttons, and the like.

The Flat UI launched while the product checkout pages were in design revisions. Consequently, I went back into Photoshop to bring the designs up to date with the new visual styleguide. Examples may be compared and contrasted in the mobile designs seen on this page.

Tee-Up Pages

While going responsive was the technical goal, one of the primary design goals of the tee up pages was to find a way to highlight the substantial amount of information Tarot.com has about each reading and report: in-depth summaries, author bios, and sample readings. All of this provides compelling value-adds for the prospective buyer, but the different legacy versions of the tee up pages all hid that content away behind easily-missed links and an antiquated system of pop up windows. The second was to ensure clear branding opportunities for each reading and report, primarily in the page hero.

I began work with low-fidelity paper wireframes. Since I was providing the UI/visual design in addition to the UX and discovery work, I jumped straight from those sketches to Photoshop and code.

Several different methods of handling the big content pieces were tried, but ultimately a tab-based layout proved to work best in the responsive context (as compared to accordions or a suite of subpages). Likewise, a number of different customizable hero layouts were mocked up, but ultimately were abandoned in subsequent rounds of revisions.

Fig. 2: Tee-Up Page UI Comps

Refining the Virtual Currency Packages

In the form of its Karma Coins, Tarot.com was one of the early pioneers of using branded virtual currency. The number of different Karma Coin packages offered had grown to a point I suspected where it was causing users significant decision paralysis. This came out during the first user tests and was later verified when I worked with the the company's data analysis to look at the numbers.

Fig. 3: Cropped Screenshot of the Live KC Packages

My proposal was to radically reduce the number of Karma Coin packages offered to potential buyers, keep the math consistent between the different packages, and address the confusing language. Working again with the company's data analyst, we identified four clear price breakpoints and built a set of virtual currency packages around them.

Instead of fifteen different options between seven different radio options and a dropdown select menu, a simple jQuery-enhanced set of radio buttons would clearly show a $10 Bronze package, a $25 Silver package,a $50 Gold package, and a $100 Diamond package.

Fig. 4: Proposed New KC Packages Wireframe Snippet

The concept was met with enthusiastic and quick stakeholder approval with plans for a trial run and testing. While it was already a better solution from both a user interface design and consumer psychology standpoint, there were still significant outstanding questions regarding the language used.

Did our users select their Karma Coin package based on cash price, the number of KCs, or the discount? Did the users understand the discount better based on price paid, bonus or extra KCs, or a certain percentage off or saved? Ultimately, testing wasn't done, but I am certain the improved Karma Coin packages could have been further tweaked by such research.

Fig. 5. Proof of Concept Karma Coin Package Icons

Checkout Pages

The only thing left to design was the final step in process: the checkout page itself. But that's not to say there was only a single page to design. In fact, multiple variations on the same essential checkout page were designed, each based on a specific branch of the checkout workflow (e.g. new member, sufficient Karma Coin balance, insufficient Karma Coins, etc).

Stakeholders' project requirements retained the existing two step product checkout process: enter the personal information for the report, then select your payment method. Yet, there are still a number of individual, discrete steps the purchaser must make during that second step.

The page had to be designed to not visually overwhelm the user upon page load; this was accomplished with dynamically loading UI modules. As an example, the payment options aren't displayed until a user selects a purchase choice (Karma Coins or cash). So, although the purchaser has several decisions left when reaching this page, they are only presented with a single one to begin with.

Even though a late-project scope change throttled back some of the proposed changes in favor of a legacy checkout page refresh and update, the dynamic nature of the UI, and design and grid system continuity of the new tee-up pages was retained.

Fig. 6: Checkout Page UI Comps

Conclusion and Next Steps

The new checkout pages are certainly a step in the right direction. Mobile traffic to these pages and mobile sales are now up, but even in light of that benchmark, there are still questions to answer and clear next steps to take.

These questions chiefly revolve around the usability of the new checkout pages. Partially due to the change in scope, and partially due to lack of sufficient user testing, there are still some unanswered questions surrounding the layout of that page in particular. Certainly, it has proved to be an enduring UI pattern for the members at Tarot.com, even when informal user research brought up concerns in how and in what order the interactions there are presented (e.g. any applicable discounts, Karma Coin packages, payment methods).

With further testing and iterative designs, the report purchase process will build on this foundation and continue to become easier and more effective for Tarot.com's millions of members to use for years to come. With over a hundred unique divination readings and reports, the product tee up and checkout pages should get users from browsing, through buying, and to viewing their product as efficiently as possible. There's been good progress made thus far.

In a world cluttered by confusing websites, too-clever apps, and mountains of unnavigable content, ensuring your customer can easily, effectively, and efficiently interact with your digital product makes a very real—and financial—difference.