I was one of two designers working on the website and was responsible for the experience strategy and design of the website redesign for MyHabit. I led the UX work, producing several major deliverables and presenting these to the stakeholders between September 2015 and March 2016.
As we approached Q1 of 2016, management had new business goals they wanted to achieve that included redesigning the web and mobile experiences for MyHabit to increase customer engagement, retention, and profitability.
To coincide with a Q2 release of the redesigned website, our team needed to move quickly in order to get design solutions approved and delivered to development to begin releasing updates to the website by Q2 2016.
Being under a time crunch, I decided to host a design sprint in order to align the entire team and jumpstart the design process in order to achieve our goal of hitting a Q2 initial release date for the website. The design sprint is a five-day process designed to solve large challenges by answering critical business questions through design, prototyping, and testing ideas with customers. By compressing the allotted time to just a week, the team is forced to focus and make quick decisions to stay on track. At the end of the week, prototypes are tested with customers and large questions are answered that provide invaluable information for guiding the team toward the correct final solution.
With the business goals in mind, we aimed to create a mobile first, truly responsive website optimized for all viewing screens while positioning the site for evolving business changes and form factors. Our challenge was to design a scalable, modular, and flexible series of widgets and templates to adapt to user needs, new partnerships, and allow for quick innovation integration. In addition to structural changes, the redesign was an opportunity to integrate new branding elements as well as critical feedback from usability studies held prior to the design sprint.
Before starting the sprint, I needed to build a team! In order to keep the Sprint focused, I decided to keep the team size to seven people or less and aimed to pick people who would represent a diverse background of opinions and skillsets. After a bit of deliberation, I chose a team of two SDMs, one PM, two developers, and two designers – including myself.
With the group of people involved in the Sprint, we had a diverse set of opinions and representations of the business, technology, and design side of the problem. We also had a team that was capable of building a prototype to test with customers by the end of the week. With those criteria met, I booked a conference room for the week of the Sprint in order to have a War Room where we could have our collective “brain” posted on the walls without having to take anything down. With the team selected and the room booked, it was time to decide on a few roles.<
While every member of the Sprint Team is valuable, a few additional roles are critical for making the Sprint run effectively. Every Sprint needs a facilitator (or two), a “Decider”, and people who can build the final prototype.
The Facilitator is the one responsible for making sure the Sprint stays on track. Some of the main responsibilities for the Facilitator is time-keeping, making sure everyone has a chance to share information and documenting all of the shared information on whiteboards. Since I was the only team member familiar with the Sprint process, I chose myself to be the Facilitator for this Sprint.
The Decider is the member of the Sprint team who will hold the final decision-making rights throughout the week in order to keep the team focused and aligned toward a final goal. I chose one of our SDMs who was responsible for not only managing the dev team but was also a key business partner with our business team to be our Decider due to his diverse perspective on both technical constraints and business needs.
Finally, we needed a few team members who could build the prototype we wanted to test with our customers. Since this Sprint was focused on designing a web experience, I decided to add a couple of web developers and two designers – including myself – to have a balanced perspective of user needs and what was technically possible to build within the Q2 timeline. For the final prototype, we agreed the designers would prototype the experience in Sketch and Keynote for testing.
With all of the details worked out, we were ready for our Sprint to begin…
As Monday began, the team was excited and ready to start redesigning the website. To begin the Sprint, we set our focus on first understanding the business, user, and technical goals. After discussing these goals together as a team, we focused on documenting long-term goals for the website based on our discussions and were able to settle on three high-level goals.
The current MyHabit website was architected in a way that made the site incredibly difficult to update. We aimed to design a new solution that was modular and scalable in order to make the site adaptable to future changes.
As MyHabit went on, customer acquisition had dropped off with business changes and the rise of other competitors. With profitability being a primary business goal, new user acquisition was critical in growing the business.
Over the course of 5 years, MyHabit had swung up and down with some years being profitable and others being below breaking even. As 2016 approached, it was critical to become profitable and financially stable in order to continue supporting the business.
From these goals, we were able to look to the end of our project and ask ourselves what had to be necessary in order to achieve the goals and identify any risks that stand in our way.
In a Design Sprint, the Sprint Questions are critical business questions that we are aiming to answer through building a prototype and testing with customers. Sprint Questions are generated by working backward from the long-term goals and identifying risks. Once the risks are identified, we convert them into questions and those become our Sprint Questions.
Based on the goals we set up front, the team worked together to generate six Sprint Questions we wanted to answer:
MyHabit’s original business model was built on high-end fashion in limited quantities being sold at discount prices to a group of exclusive members. Since the original site was built, several product changes had taken place on the site and not all of them supported that business model. As we looked toward the future, we needed to understand if that business model was still viable.
MyHabit was created by Amazon, but had no Amazon branding associated with it. When the site was built in the summer of 2011, Amazon had little clout in the fashion industry, so the business decision was to remove the Amazon branding that associated MyHabit with Amazon. At this point, the Amazon brand had come a long way in establishing customer trust and had a lot more clout in fashion, so we wanted to understand and measure if customers trusted the MyHabit brand and the Amazon brand when it came to selling high-end discount fashion items.
MyHabit was built on the flash sales model made popular by sites like Groupon and as our business model came into question, we wanted to understand if the event-based approach to selling items made sense for customers. A few pieces of data showed that products that were targeted toward users sold at a 400% higher rate than items discovered by customers via Events and with Groupon’s IPO under-performing, the idea that a flash sales site could continuously generate revenue and sustain profitability was coming into question.
This was a loaded question because it came with both positives and negatives. A key piece of information held within the MyHabit team was the fact that the top 1% of customers who made purchases on MyHabit were responsible for 50% of total revenue generated by the site. The goal of redesigning the site was to engage the other 99% of users in a more meaningful way while also retaining the current behavior patterns exhibited by the top 1%. Balancing the 99% with the top 1% would be critical in the short-term to avoid toppling the entire business.
Over the site’s 5 years of existence, it had evolved as more features were added to address business concerns and add additional customer value. In the year prior to this Sprint, the team had made the decision to add “Browse” and “Search” features to the site to allow users to sort through all of the items on the entire site. This allowed users to find any item in a current event using typical navigational structures instead of going through the events. This also held implications for the business model as a whole, because by adding this feature, any items that did not completely sell out during an event were still searchable and browsable via the top navigation, even though they were not in any active events. This now meant that MyHabit was holding on to inventory past the event date in order to try to sell it via the “Browse” and “Search” features. This created a site that had 2 completely different experiences based on if you were an event-based shopper or a browse-based shopper and the “Browse” experience was very cluttered, making it hard to find items you were looking for. From previous usability studies, we had observed difficulty in finding items using the “Browse” and “Search” features and wanted to improve these experiences to make a more seamless shopping experience. With this information in mind, we wanted to make sure that users could find products they were looking for in order to make a quick and timely purchase.
MyHabit had a return rate that was much higher than the average return rate observed in the rest of Amazon. Through our prior usability studies, we were able to examine that users were having a hard time getting all of the information they needed to feel confident about a purchase. We observed users struggling to get enough information in the images, descriptive text, and size charts to make a strong purchasing decision, but many users would purchase items anyway due to the highly discounted pricing. Through our return numbers and qualitative feedback through the internal customer service tool, we understood that we needed to improve our information quality, so added this Sprint Question as a potential risk factor for meeting our long-term goals.
With the Sprint Questions documented on the whiteboard and the team aligned on our goals, it was time to move onto the next portion of our Sprint.
With the Sprint Questions posted on the board, it was time to move on to “Making the Map”. The Map is a small flowchart exercise that identifies the high-level touch points between customers and the end goal. To start, we drew up our two customer types on the left (existing customers and new customers) and our goal of a user finding and completing a purchase on the right. After an hour of deliberation, we were able to finalize the map that is shown above. We focused on identifying all of the touch points that brought users into the MyHabit site, detailed out each of the potential ways users could locate an item, then wrote out the linear path to completing a purchase.
After the Map was decided on, the team broke for lunch to clear our heads and fill our bellies in order to prepare for the next half of the day.
Once lunch was over, the team gathered together to participate in a session of expert interviews. Since our team was made up of a lot of product, design, and technical people, we decided to interview our business stakeholders during this time to get a better understanding of business goals. We met with several key stakeholders on the business side, showed our whiteboard, and got their opinion on what was important to MyHabit. As we listened,
the team took notes in the “How Might We” format, identifying any key points as opportunities that the Sprint Team could discuss later in the day.
After a few hours of interviewing stakeholders and members of the Sprint Team, hundreds of HMW notes were taken and the Sprint Team needed to organize them. Together,
we organically organized them into logical groups that emerged as topics that supported other goals we had spoken about earlier in the day. Once the notes were organized, it was time to hone in on a few of the questions to focus on.
The final task of the day was picking a target for the rest of the week. To do so, we needed to identify the point on the Map the team found as the most important portion to focus on. To pick the most important spot on the map, we would use the HMW notes and assign them to corresponding pieces of the Map. In order to decide on which notes were the most important to the Sprint Team, each member was assigned 2 stickers to vote on the sticky notes they thought were the most important. The Decider (our SDM) was given special stickers with his initials on them to vote as well and any notes he voted for were prioritized above the rest. After the voting was over, the HMW notes with votes were mapped to portions of the Map and a clearer picture began to appear.
Over the course of the day, the Map had evolved and changed to a simpler model and after mapping our HMW notes to it, we saw the most important portion of the Map we wanted to focus on was the “Visit Site” portion. We also identified a key Sprint Question to focus on and had a set of key supporting questions from our HMW notes. From there, we had a good foundation of information to continue forward with for the rest of the week.
After Monday, the team was chomping at the bit to start designing solutions and Tuesday is all about solutions. We started the day doing Lightning Demos – quick 3-minute demos of other products that we have had positive experiences with or may help solve the problem at hand to serve as inspiration for the sketching sessions later in the day.
A projector and timer were setup and as team members shared, I took notes on a whiteboard, roughly sketching the core of the experiences they shared for recall during sketching sessions later in the day. Once the Lightning Demos were over, it was time to transition into finally designing solutions via sketching.
The Four-Step Sketching process is designed to get the whole team ready involved in sketching and designing solutions. The sketching process is done individually to avoid groupthink or charisma from dictating the final solution. The Four-Step Sketching process consists of:
This session is 20 minutes long and consists of team members silently walking around the room and re-observing all of the artifacts and writing on the wall, gathering important information on a sheet of paper to help inform their sketches.
This is another 20 minute session where everyone on the team privately jots down their own ideas and circles the ones they think are the most promising.
This session is 8 minutes long and requires everyone on the team to fold up a single sheet of paper into eighths. Once the timer begins, each team member sketches variations of their best idea(s) in each of the panels on their paper spending ~1 minute on each sketch.
The final session is 30-90 minutes long and requires the paper to be separated into three panels. This final sketch should be detailed enough to be self-explanatory and should also be anonymous. Once the sketch is finished, the team member that made it will give it a name that can be referenced when discussing the sketch later.
With the sketches complete, the day was finished and the team broke until the next day.
With Tuesday in the books, the team had designed several solutions to the challenge we were focused on and were ready to start making decisions in order to get our prototype ready. To begin Wednesday morning, all of the team members were asked to pass their sketches into the middle of the table so they could be anonymously posted on the wall. Once they were posted, we began the decision-making process. The Five-Step Decision process consists of:
All of the solution sketches were taped onto the wall in a long row for observation.
This is another 20 minute session where everyone on the team privately jots down their own ideas and circles the ones they think are the most promising.
With the sketches posted, each team member silently reviewed the sketches and posted small stickers on portions of each sketch they found interesting.
Similar to the Lightning Demos, each sketch was visited and given a 3-minute review. As a group, we discussed the highlights of each solution and captured questions and objections on sticky notes. After the 3 minutes, the person who sketched the solution would explain anything the group missed.
Each team member is given a single large sticker to vote on their favorite idea.
The Decider is given three stickers with his/her initials on them. Any idea that the Decider places a sticker on is included in the final prototype.
Once the decision-making process was completed, the sketches were separated by the ones that had votes and the ones that didn’t. Anything with a supervote would be built directly into the prototype, anything with team member votes, but no corresponding supervotes would be deemed as a “maybe later” idea we could come back to, and the rest of the sketches were set aside We now had clarity on the ideas we wanted to be included in our prototype, but we needed to stitch them together!
The back half of the day consisted of formulating a 15-panel storyboard that would serve as the backbone for our prototype. We took the solution sketches and copied the concepts that made sense directly into a few of the spaces on the storyboard and began to discuss the flow of the prototype starting with the beginning and the end of the process. We referenced our original Map and decided to add in some panels for how a customer would enter the site via a promotional email and rounded out the back half of the storyboard with a checkout process. From there, we detailed out the other panels through a series of discussions and referencing of all of the other pieces of information around the room. By the end of the day,
we had a clear picture of what our prototype would look like, we just needed to build it!
Thursday started with us knowing we needed to have a completed prototype by the end of the day. Since we only needed the designers for this prototype, we dismissed the rest of the Sprint Team and divided up the work needed for the prototype based on the storyboard. By splitting the storyboard in half, we were able to quickly and efficiently design mockups that reflected our storyboard.
At the end of the day, we took about an hour to merge all of the design work and clean up the styling to make sure all of the work matched the same style. With this completed, the prototype was finished and ready to share.
In a typical Design Sprint, we would test our prototype with customers to get feedback that answered our Sprint Questions, but in this particular Sprint, we were not able to do so. We were able to take the learnings from the Sprint and all of the artifacts and present them to the key stakeholders in the business as the vision for the MyHabit website. The stakeholders bought into the concept and the site had begun to be rebuilt when the MyHabit project was canceled in May of 2016.