Stitch Fix is a women’s fashion subscription service built around a custom recommendation algorithm and trained in-house stylists. It’s what people within the company call a “mullet app” – that is, neat and simple in the front with a complex mess in the back.

How it works sketches

Navigation diagram

I joined just after the launch of their new consumer-facing site as lead designer. We spent a month or so cleaning up small parts of the site, including the landing page, sign up flow, site navigation, visual branding, and the company blog. I worked with the Marketing Director to help develop an A/B testing strategy for the site that she could run while we shifted our focus to internal tools.

A Faster Experience

Based on company priorities and the bottlenecks in the user journey – new customers generally had to wait 4–6 weeks after signing up to actually use the service – we decided to turn our focus towards replacing the internal tool that the stylists used to research customers and choose the clothing and accessories we sent them.

The current tool was essentially a series of tables displaying the database. We knew about a lot of low-hanging fruit, but I decided to do some user research before landing on any one direction.

Research

The first week, I ran testing sessions with four stylists. The sessions began with an open-ended contextual inquiry and lead into shadowing each participant as they went through their normal workflow. After transcribing highlights and taking notes, I shared the results with the rest of the development team and we discussed the findings.

The second week, I facilitated a post-it note sketching session with the entire team of stylists. Coming from non-product-development jobs before, they really enjoyed the session, and a lot of great ideas came out of it. After documenting the session, the development team met again to discuss.

Post-it note ideation session

The next two weeks, we focused on sketching ideas and building rapid prototypes to test with. We came up with a lot of different ideas, including a binary image-based wizard flow, a keyboard command based app, a social-network like conversation view, and one that followed patterns from traditional e-commerce apps. In an effort to release an MVP soon, we decided to focus on the e-commerce-influenced direction.

I continued our research by testing the new prototype with four different stylists. We iterated on the prototype throughout the testing in an attempt to make the transition to the new app as easy as possible for the stylists.

Prototype to Rapid Prototype

I’d made plenty of prototypes in the past, using HTML & CSS and tools like Ratchet, Keynote, and Blueprint, but I knew next to nothing about Javascript and didn’t think my CSS was good enough to be production-ready. We originally planned to have the front-end developer build the actual app and to keep the prototypes on separate branches. At the time, the developer was busy working on other tools for our warehouse operations.

After several code reviews and some coaching, we decided that we should just clean up the prototype that I'd built and ship it, with the intent of consolidating components and better organizing the code as we went along. During that time, the front-end developer taught me a lot about CSS and front-end architecture, and I took it upon myself to learn more about Javascript and front-end MVCs.

Although the team of stylists wasn't large enough to get signficant data from, we wanted to be sure that the new app wouldn’t negatively affect their workflows. We decided to split the team into two groups: one continuing to use the old app and another using the new one. After about a week of use, the stylists more than doubled their output using the new app. We knew we had a clear winner, and switched the entire team over.

During this time, we continued to shadow and monitor the stylists to make sure we addressed any of their concerns. The development team and I also discussed the use of a front-end MVC framework instead of forcing jQuery to work in ways it wasn’t intended to. In my own time, I began teaching myself Angular JS and built soundrad.com to vet the framework.