Easy Checkout responsive design

How we got from an inconclusive process of designing a core feature, to shipping Easy Checkout, increasing conversion by 30% and enabling millions of orders to happen.


Problem statement

  • Checkout was a strategic feature to Linx Commerce platform: 1) in all the purchase flow, this it the most critical moment; 2) to merchants deciding for a platform, it might be a deal breaker.

  • The checkout version at the time had flaws, but people were struggling to redesign it. There wasn't a design specialist in the company and they were having a hard time converging.

  • The main competitor already had an attention-grabbing checkout solution.


This was my first mission in the company, and I was the first designer to be hired permanently. To complete the picture, we began with a sense we were already late. Initially, we set up a 3 month time frame to have something concrete in the market. đŸ˜®

Since the design maturity was low, and expectations were high, I took a basic approach with questions like:

  • what's the fundamental structure of a checkout?

  • what people inside the company already know from previous discussions?

  • how other companies are dealing with the checkout process, are there any consolidated standards? (benchmark)

I used paper, or whatever was accessible, to have good conversations.

I used paper, or whatever was accessible, to have good conversations.


From paper to functional prototypes

Then we needed to see things taking shape, something less abstract, to keep the conversation going and maintaining a certain sense of progress. This moment, I came with a type of prototype that proved to be very handful, one built using Bootstrap (HTML + CSS). It was not too polished… a bit ugly to be honest, but it validated things like information architecture, flows and responsive layouts early on.

It wasn't so seamless for designers in general, at the time, to mirror screens they were working on smartphones, but I managed to create a smooth design environment alongside with frontend devs. Every stakeholder inside the company could run the responsive prototype on their own devices.

First functional prototypes looked like this.

First functional prototypes looked like this.


Visual design was defined direct on the prototype. Parallel to that, the implementation begun. I seated every day with one dedicated web dev, and we tweaked things and implemented then on the go, while making some major definitions.

Web dev and me pairing.

Web dev and me pairing.


While defining the feature, we did reviews with shop owners from our client base, and we did usability tests with potential users. We even encouraged people from the team (non-designers) to conduct informal tests with their relatives and friends, record it and bring to be analyzed. All they needed was a basic script and some orientations.

Before releasing what we called Easy Checkout, I advocated for us to have a multivariate test running to compare both versions. We divided users between those that got the precedent version (version A) and the redesigned one (version B).

Outcomes and results

After calibrating the experiment in Google Analytics, we saw some good results happening in stores using Easy Checkout:

An average increment of 30% in conversion rate could be verified based on a multivariate test.

Other positive effect, is that people from the team and the company begin to understand the value derived of design work.


Final product: payment (desktop) and delivery (mobile) steps.


Later, after releasing the redesigned checkout to a list of ~1000 merchants, we estimated that in following 4 years:

U$ 750.000.000 were transacted in the platform, through 10.000.000 orders, in a rough estimate.

Lessons learned

  • Defining something while developing can be a risk, worth it or not.

  • The ideal timing to think about metrics and experiments is during define and develop phases, not later when we are at the launch phase.


Mobile view.

Pickup in-store.

Shipping to adress.