MyHabit App (Material Design)





Personas

[/portfolio_field]

Interactions

Description

MyHabit was a flash sales site with ~12,000,000 users that offered high-end fashion at discount prices. As part of the business initiatives for 2015/2016, a redesign of the Web and Mobile experiences was in order focusing on helping customers find the products they wanted to buy via solving pain points associated with the browse, discovery, and purchasing features.

My Role

I was the lone designer on the MyHabit Android app and was one of two designers leading the redesign of the Web and iOS apps. I led efforts to update the app to a more modular, flexible design system and addressed customer pain points with a focus on the browse, discovery, and purchasing paths.

Process

I began working on this project by pairing up with one Product Manager and gathering the project’s requirements from her. After a few meetings and document exchanges, it was clear that there needed to be a large focus on the browse and discovery experience of the mobile apps. The business and marketing teams wanted to test some new concepts and ideas but had little to no flexibility inserting content into the experience, because the architecture was designed in a way that made it very difficult to add features on top of.

With this knowledge in mind, I wanted to get a better understanding of our customer, so I worked together with our PM to schedule an external usability study and also started brainstorming other ways to empathize with our customer. With the study scheduled, I began doing a series of competitive analyses on competitor sites and mobile apps and performed a series of cognitive walkthroughs on our app in order to better empathize with our customer. I was given access to one of Amazon’s internal tools for reviewing customer feedback and parsed hundreds of pieces of feedback from there, the app store reviews, and from past user interviews to start formulating a picture of the customer problems. Armed with this additional information and perspective, I was able to re-visit our Product Manager’s requirements documents and provide better feedback that helped change some of the core goals and requirements for the redesign.

We ran our preliminary usability study to get a baseline understanding of customer pain points with the existing website and mobile apps. The usability study was moderated by an external party, but I and our Product Manager were integral in planning the study and aided in writing the moderator’s guide and final findings write-up. Observing users using our product was very eye-opening to me because I instantly realized that our average customer was in the age range of 40-60 years old and had a much different set of needs than someone like myself or my team members. The items they looked for, the information they needed to complete a purchase, and their concept of the internet and mobile apps was significantly different than mine and the team’s and it helped me get a very clear picture of our customer’s needs. Some of the key customer pain points that came up specific to the Android app were: the fact that searching for items was difficult due to unpredictable and limited filtering options, limited interest in the event-based model of browsing, users found it hard to navigate to items they found appropriate, and users did not want to check out on their mobile device because they feared their credit card information would be stolen. Many of these issues, we had surface-level knowledge of, but armed with real customer data and quotes, I was now ready to begin designing a new experience for the Android app.

Immediately after the usability study, I proceeded to create a set of personas based on the types of customers we observed in the usability study. I presented these personas to our internal team and to our key stakeholders to get alignment around who our customer was because, at that point, we didn’t have a great understanding of our customers other than the fact that they were also Amazon users. Presenting the personas to the team turned out to be way more valuable than I originally imagined because, over the course of the project, I frequently witnessed developers and other team members referencing the personas by name and identifying with their problems. The personas became a beacon of empathy for the team due to the fact that the entire immediate team had witnessed the usability study and could easily pin pieces of each persona’s story back to a user they observed in the lab.

From here, I worked with our Product Manager to hold a kickoff meeting for the members of the team working specifically on the Android app where we aligned on the goals of the app, brainstormed potential concepts, and began whiteboarding a few baseline ideas to key customer pain points we observed users struggling with. From this meeting, we were able to make some quick short-term fixes to the Android app that addressed some of the low-hanging problems which put us on a path to solving the overarching problems in a more meaningful way. Unfortunately, some of these “quick fixes” became permanent solutions as the team began deeming the “quick fixes” as “good enough” as we got closer and closer to a deadline that continued to be shifted ever closer as we proceeded on the project and MyHabit fell on hard financial times.

After this kickoff meeting, the devs began developing on small iterative changes we could make to the current app and began updating the underlying architectural structure of the mobile app to make way for a more modular system. This gave me several weeks of time to myself to jumpstart the design process. I started with a series of sketches and began showing them to the lead developer on the project. He was very excited about the direction the sketches were going, so we scheduled daily design stand-ups where we would brainstorm together on the whiteboard for 30 minutes about pieces of the app. From these meetings, we were able to quickly align on designs that were technically feasible and he was able to begin architecting the framework for developing the app long before the final design was delivered. Over time, this enabled us to have a lot more freedom and flexibility in testing because once his framework was up and running, we were able to use his code as a prototype to put in front of users and get feedback.

As I moved on in the design process, a large business challenged reared its head. MyHabit’s business model was based on the fact that it was an event-based flash sales site and the limited inventory and a limited amount of time to purchase it was a key factor in driving users to purchase items quickly. Unfortunately, over the course of 5 years, users had started to understand how MyHabit truly operated and the urgency of the events was lost. MyHabit added the ability to browse and search for items in the spring of 2014 and instead of just being able to discover items within events users could find and purchase items that weren’t in these limited time events either. What was happening was that after an event ended, the product stayed on the MyHabit site and the price would be reduced each week to help the item sell out. Customers began to understand this and even if they were interested in purchasing an item within an event, they would leave it in their cart and come back to it once the event ended to see if the price had dropped. This was a key observation in the usability study and it helped us understand that we had trained our customers that it was more advantageous to not use events to purchase items, even though our business model was built on it. The Event portion of the site and the Browse portion of the site were significantly different experiences and as users traversed between the two, they had a hard time understanding what was happening or where they were on the site.

I began the initial design pass and after 4 weeks, I was ready for usability testing. Since we were highly focused on the browse experience, I prototyped several versions of what that experience could be in Framer (CoffeeScript) and deployed it to user’s phones so that they could experience the app in a natural setting. With the business goals in mind of not detracting from the event experience, I also prototyped several versions of how the user would get back and forth between the browse and event experiences. With a mixture of guerilla usability testing and internal lab studies, we were able to make swift incremental changes to the browse experience over the course of 2 weeks of RITE (Rapid Iterative Testing and Evaluation) testing.

From our usability studies, we learned that users were still struggling with the concept of events versus buying items in the browse experience. Our current app highlighted events and many users didn’t even know the browse experience existed, but based on our personas, we knew that we had both an event-based shopper and a browse shopper and our current iteration of the app only served the event-based shopper. Based on the findings from our prototype testing, I came to the conclusion that the best customer experience for browsing would be to introduce it directly on the landing view (home page) of the app in order to allow people to discover the ability to browse. We had observed in each of our usability studies that when the browse experience was buried in the menu, users skimmed over it or didn’t even think to look there. They’d instead look at a few top events that caught their eye and leave the app immediately. This posed a challenge for me because, from our gathered customer data, I needed to intercept the browse-oriented users early enough in the app for them to discover that browse existed, but I also couldn’t detract from the event-based experience, because of how valuable that customer constituency was.

Knowing the business goals and customer pain points, I proposed the concept of placing the browse experience directly onto the home page of the app and was met with great resistance from the business team since they believed it would detract from us being an event-based site. The original design hosted a very large browse experience integrated directly into the top of the app. After discussions with the business team about what their concerns were, it became clear to me that they wanted the ability to advertise to users and focus on events and by using prime real estate to introduce the browse experience, they were concerned it would promote MyHabit as a browse-based app and not an event-based one.

With that feedback in mind, I went back o the drawing board and iterated on different navigation and browse structures that would compliment the event-based experience. I finally landed on a concept that allowed users the ability to navigate by department using a tabbed layout at the top and to enter into the browse experience by using a very small widget attached to the bottom of the home page. I also added some thoughtful interactions to the navigation to help demote its focus whenever the user decided to focus on events. If a user began scrolling through the events on the home page, the navigation and browse widget would hide altogether, allowing the user to focus on the event imagery. If the user stopped scrolling and waited for more than 3 seconds, the navigation would come back to prompt them to head to another portion of the app. We tested this experience in another series of RITE tests and it tested positively with both our browse-based and event-based customers. Armed with this new usability testing data and a set of design updates, I presented my findings and new designs to the business steam once again. They were still somewhat concerned with having the browse experience directly on the homepage, but after seeing the animation that it would hide once a user decided to focus on events, they compromised with us and approved the design.

From there, detailed designs and interaction guidelines were handed off to the lead developer and I continued on designing other supporting portions of the app. Just as we began getting traction toward building the new app, MyHabit was shut down due to financial issues.

Deliverables

View Design Doc
View Wiki (Amazon Internal Only)
View Interactive Prototype

Many other deliverables available upon request