Internap Shopping Cart

Brief

Stakeholders

Needs

• Increase autonomous sales completed through cart;
• Drive sales with a low monthly recurring revenue to self-service experience;
• Facilitate rollout of campaigns and promotions;
• Improve overall user experience of checkout process.

Constraints

• The new shopping cart needs to fit the current ordering processes;
• The engineering team needs to re-use a portion of the previously designed checkout process (2014) in order to respect the timeline approved by the CEO;
• Respect the visual identity of Internap’s website;
• Time (6 weeks for design)

Core Team

My Role

You must know that the UX team had already designed a new checkout process experience the year before but it had never been released. Although, the members of the team were different and the business needs had changed since, so the stakeholders decided to start (almost) from scratch.

The UX Lead Designer had more experience than me with e-commerce websites, but, being the oldest member of the UX team, my knowledge of the products, the industry and the internal systems was going crucial to respect the deadlines; We had to keep a lean process, so I took most of the primary tasks and she helped me refine the deliverables.

Deliverables

Competitor Analysis

We wanted to do a very high-level analysis of what the competition was offering in terms of experience because we thought users usually start to create expectations when they shop and go from a website to another. We also looked at well known e-commerce websites because we assumed they have been testing and optimizing their process a lot. In total, 25 companies were benchmarked.

Screenshots of competitors’ processes

User Flows

After interviewing the stakeholders and discussing with the development team, we felt we needed to illustrate all the possible flows the user could go through. Once done, the development team could already start working and we (the UX team) would know what wireframes and use cases we needed to design.

Here’s an overview of the flowchart that I made using Gliffy in Confluence:

A part of the flowchart

Wireframes & Prototype

We could have decided to do a basic black-and-white wireframe, but knowing that Internap had a minimalist style and used Helvetica, we chose to design “high-fidelity” wireframes. That permitted us to have something to show the stakeholders more quickly and avoid comments regarding the UI during presentations.

Before starting on the wireframes in Axure RP, I looked at Internap’s websites to identify visual patterns and gather UI elements in order to keep consistency between interfaces. It would also allow the other designer and me to have wireframes that would have the same look. This step would have been a lot easier if the company had already have a style guide; Visual identity guidelines is not enough in this kind of projects that involves multiple designers and developers (more on that further).

Here are a few screenshots of the prototype that was made out of the wireframes that I mainly designed myself, but in collaboration with the UX Lead Designer:

Server Configuration: A page used by the customer to select configuration options of his server. The Cart: This is the place where the customer could get an overview of the items he added in the cart. Furthermore, it’s at this step that Internap would try to present him cross-selling items. Modal Box: An exemple of an attempt to do item cross-selling. Payment (New Customer) with notes: The step where a returning customer would choose his method of payment. This also a good example of how I would add short notes that explain the possible interactions in the page.

At the end, the Axure file had over 50 pages, becoming the main conversation tool across the core team and the engineering team. It included:

• Wireframes (prototype of the “happy path”)
• Use cases (types of coupon codes, option dependencies, cross-selling possibilites, etc.)
• Interaction design and technical notes
• Error messages
• Tooltips & contextual help

Style Guide

In my opinion, every organization should have a style guide because it simplifies the development process. It also keeps the UI, the Interaction Design and the front-end code clean and consistent. It’s especially useful for large teams and could be a good time saver for future projects.

With the help of the UI Developer of the team, we went through all the wireframes and built the list of elements, components and patterns that would form the style guide. Once I had designed all these in Photoshop, the UI Developer integrated them and published the style guide on the internal Git with instructions on how to use the system.

Here’s a glimpse of what I delivered:

Results

We released a MVP (minimum viable product) at the beginning of 2016, but, while I'm writing these lines, it's still too soon to have a clear idea of its impact.

From another point of view, I think that everyone involved in the project appreciated the work the UX team did; User flows, detailed wireframes of all use cases and the style guide were among the most liked deliverables.

Furthermore, I learned a few good things in this project; It got me more confortable in Axure RP, especially with Masters, Dynamic Panels and Interactions. It also gave me an opportunity to work on more complex user flows.