Max—R

Launching an App for a Retail Giant


Working with my design team, I helped design and launch Academy Sports + Outdoor's first app, helping increase AOV by 25% in the first week over the web experience.


Timeline: Jan 2021 - Apr 2021

Role: Product Designer

Team: Myself, Gopika S. (Product Designer), Aurelio A. (Design Lead)

TL;DR

The onset of the pandemic saw a surge in e-commerce sales across many businesses, including Academy Sports + Outdoors; in 2020, the company’s revenue exceeded $5.6B. Despite having this large influx of sales, the company lacked a way to easily reach their customers through a mobile channel.


Alongside my team at Publicis Sapient, I worked to design and help launch Academy’s first mobile app, all within 12 weeks. I contributed to all aspects of the design of the app, but I solely owned the research strategy and execution, and the designs of the product details pages.


Within the first week of launch on the App Store, we had a 4.8 rating from over 8,000 reviewers, today this sits at a 4.9 rating from over 85,000 reviews! And also in the first week, we saw a 25% increase in AOV over web orders. This was all achieved with $0 marketing spend for the launch.

Academy is one of the world’s largest sports retailers and along with my team, I helped them launch their first mobile app. I contributed to the designs of the Homepage, Browse experience, PDP, Cart, Checkout, BOPIS, and I owned the evaluative research strategy and execution for the app.

What is Academy Sports + Outdoors?

Academy (for short) is one of the largest sporting goods retailers in the US; they currently operate over 280 stores from the midwest to the south and southeast states. Their product assortment covers everything someone might need for hunting, fishing, barbecuing, or sports. When we engaged with our clients at Academy, they just finished off 2020 with revenue exceeding $5.6B.


Our strategy team at Publicis Sapient worked with Academy to define ways to increase engagement (our primary success metric) and provide additional revenue streams — one of the outcomes was releasing a mobile app. This is when I was brought in.

A screenshot from Academy's website in 2024.

Visit Academy →

Defining the scope of the app

Academy had never had a mobile app before, and the teams at Publicis Sapient were going to be the ones to build it first.


We were given an aggressive timeline to launch in under 6 months, so the easiest path forward for design was to start by replicating web functionality and features. However, we learned from Academy that their customer segments had specific needs, so we’d need to provide additional functionality in the app to add enough value for these customers to download the app. These features were defined later to be BOPIS, in-store barcode scanning, push notifications.

Academy’s customer behavioural segments

Academy's customer segments differed, and thus each had different needs that had to be met. The way that we planned to use this information in our design process, is to understand how each customer type would benefit from a feature, or react to a way we’ve adapted the designs from the web experience to app.


Despite being different behavioural segments, each would benefit from their own goals. All segments would benefit from: convenience and details about fulfillment options, easy to access details about products and testimonials, and clear pricing and details on sales.

Convenience Chaser

They shop for what’s most convenient. Convenience Chasers prioritize faster shipping, local stores, and easy access to things they need.


Passion Pursuer

They want the newest, best, and hottest products. Passion Pursuers need details about the products, testimonials, and to be notified about new launches.


Value Verifier

They look at the price and its value. Value Verifiers try to get the most bang-for-my-buck by looking at what’s cheapest, and what’s best in that category.

Our guiding principle for design

Maintaining parity with the web experience was our guiding principle for design throughout this engagement, alongside the needs of our specific behavioural segments. To make sure we followed this throughout the engagement, we worked closely with the lead designer at Academy to understand his design process and current state functionality.


Soon into our process of working with the lead, we faced a challenge: their team was in the process of redesigning their entire web experience — primarily visually, but some functional aspects too. Our focus was to maintain parity, but we soon realized we didn't fully know what parity was. More on this later…

How might we maintain parity with the web experience, while also creating a more convenient purchasing experience to increase engagement?

Gathering research on the Product Details Page (PDP)

Best practices say to expose all details on the PDP

I took on the work for the PDP, while my team tackled other areas of the experience. Through resources such as Baymard and Nielsen Norman Group (NNG), I learned that customers are used to scrolling and swiping up, so I should avoid hiding information behind a drop down. The concept of “above the fold” doesn’t exist for app, and so content should be laid out that reduces friction from the main action, scrolling.


I also noticed that the biggest retailer in the world, Amazon, does this really well, and typically exposes all the information for customers to scroll through.

Target had an experience our clients wanted to mirror

We also worked with our clients to understand who they feel are their competitors in the space. Though Dick’s Sporting Goods was their biggest direct competitor (and still is), their app was a webview of their website experience. At the same time, Target’s iOS app was consistently used as a reference for a best-in-class experience.


For the PDP, I took note of Target’s approach to expose all options and information and their extensive related products carousels towards the bottom of the page. I liked that Target never made the PDP for an item a dead-end, and hyperfocused on (what I assume to be) either their primary customer base, or the primary customer action they want to encourage, in-store pickup. The biggest negative of the PDP experience was that the reviews section was at the very bottom of the page, and hidden.

Target's app experience on Android did a lot of things really well.

Designing the PDP

Academy supports five different product types on their website, all of which had different PDPs, and thus all needed their own designs: “Regular” products, gift cards, e-gift cards, bundles, and firearms and ammunition. I started with designs for the regular PDP as this covered most of the products. Throughout this engagement, the lead designer at Academy had provided us with a style guide that we should follow for the designs.


Though Academy was already doing a great job servicing their customer segments, I took it a step further and exposed product details and the reviews to let Passion Pursuers, as well as the other segments, review everything easily.

I designed the PDP, with the focus of exposing information to the customers.

Facing a challenge with firearms

Firearms are prohibited from being sold on the App Store

After hearing that firearms were being sold on Academy’s site, I had an assumption that this wouldn’t be allowed through a mobile app, considering Apple’s strict guidelines. I did some digging in the App Store Review guidelines and found that this was true.

Rather than taking this at face value and giving up, I listed out scenarios where I thought we could get away with showing firearms, and ideally make an easier purchasing experience for the 3 segments. Some examples being: What if we allowed customers to add firearms to cart, but let them continue their purchase on web? What if we let customers add firearms to a wishlist? What if we said this was all Apple's fault? I took these examples and called Apple support to review and decide on a path forward. Unfortunately for us, every idea was shut down. In addition to the scenarios I outlined, we also weren’t allowed to advertise firearms to customers.


Directing customers to the web experience

I raised the findings to the Design and Product teams as a risk to our strategy. Working with the Product team, we ideated and defined generic messaging to say firearms can't be sold in the app, and to re-route these customers to the web experience.


Going back to our customer segments, specifically the Convenience Chaser, I proposed to include store availability on the PDP to let them see these details before sending them to the web experience.

Facing another challenge with rework

Academy was redesigning their web experience

We learned during our engagement that Academy was redesigning their entire web experience, the issue was that we learned this after a lot of our work was complete. For the PDP, this impacted the add-to-cart interactions and the fulfillment options as the strategy was different.


They requested to use just one sticky Add to Cart button, with Apple Pay (PayPal on Web), and to use a radio button that defaults to Free Store Pick Up. I brought this up as a concern, as customers wouldn’t be able to see what fulfillment option was selected before they chose to Add to Cart. The biggest risk was if they chose to use Apple Pay and place the order right away.

Academy updated their PDP experience to have selectable fulfillment options with a generic, sticky Add to Cart button.

Customers found this interaction "awkward" in testing

I had an assumption that this didn’t follow customers’ mental models, so I ran this specific experience through testing, asking customers about the Add to Cart, and if they knew how they would receive their items. Most participants found it awkward, so I tried to redesign the experience and propose a different approach.



"It’s not what I’m used to. I can’t see associated costs with shipping or pick up, so I don't really know."



I designed alternatives, but we ended up with parity

For my first proposal, I placed the add to cart button below the fulfillment options, so customers would be forced to scroll past them. Since we know our customer segments scroll and want more information, this would make a lot of sense. The second proposal kept the buttons as sticky, but placed a callout in the add to cart for what fulfillment option was selected. We know Convenience Chasers want, well, convenience, so letting them know what fulfillment option was selected would also make a lot of sense.


Unfortunately, both proposals were rejected, so we proceeded with web parity.

I proposed 2 alternatives to improve the user experience, but we ended up with web parity.

Defining all the states for the fulfillment selector

In addition to the radio buttons, I worked with our client to define every possible state that could appear, and then I designed out the component and it’s variants. This would help our development partners to ensure we’ve designed a scalable solution and accounted for all edge-cases.

Finalizing the PDP

Designing out the rest of the PDPs

Throughout the process I facilitated design reviews with the client, and we reviewed designs again once the PDP was finalized to get their sign off. I continued with designing the rest of the PDPs, the rest of which followed closer to parity and faced less push-back. This entire process, from research to working with devs, only took 2 weeks!


Though the PDP is what I focused on for this case study, I continued to work through other aspects of the experience, including taking on the entire checkout flow.

The results

If you've read the TL;DR, you might already know this.


Within the first week of launch on the App Store, we had a 4.8 rating from over 8,000 reviewers, today this sits at a 4.9 rating from over 85,000 reviews! And also in the first week, we saw a 25% increase in AOV over web orders. This was all achieved with $0 marketing spend for the launch.

Project challenges and learnings

We had a lot of challenges throughout the engagement, no engagement is perfect.


The tight timeline was probably the biggest challenge. 12 weeks is what we had to design the entire app from scratch. This cascaded to miscommunications, and it didn’t help that we had to go through rework since the client was redesigning their web experience.


Collaboration with the dev team was a challenge because of timezone differences. As the dev team was located in India, design decisions were communicated asynchronously, and often led to miscommunications.


Lastly, at the time, I had an Android phone, in Canada. I lacked access to many of the competitor iOS apps (Dick’s, Target) as they aren’t available in my device (though I was able to sideload the APK files). I also wasn’t able to test the QA test the Academy iOS app.

What I learned and would’ve done differently

Baymard was a lifesaver in this project. It was helpful to quickly search for specific interactions, rather than always referring to a set of competitors to see what they did.


But, looking back, there’s definitely ways I could’ve handled myself better and been more proactive.


Using Figma would’ve saved our team a lot of headaches. We used Adobe XD because our client’s design files were in XD, but we didn’t need to use it. Component issues, connectivity, and collaboration were all things that affected the way we worked.


I would have proactively held meetings with the Designer at Academy to better understand what they were designing, to avoid re-work. We started doing this a bit after the PDP debacle, but I still don’t think it was enough because I faced challenges when designing checkout.


And lastly, I would’ve said “Yes” to my team offering to help with my workload. They were fantastic and super supportive, but I think I tried to take on too much at once and began to get burnt out.



Last updated [05/05/24]