The Making of FTUE

5.29.14 to 7.28.14 —
A 60 day project

Click here to view a demo

Project Background

Redfin is a tech-based real estate brokerage start-up that offers quality agents paid on customer satisfaction, so homebuyers always get the best deal. People love to browse Redfin’s website for its accurate and comprehensive listings. The problem is, many people did not know that there were agents at all.

The goal of my main project at Redfin, FTUE (the first time user experience on Redfin’s iOS app) was to help customers understand this business model — that they can buy or sell homes with Redfin’s agents for less. Customers share whether they are “selling”, “buying”, or “both” and we in turn introduce the benefits of Redfin agents.

Most importantly, we aimed to increase sell side visibility, and success of conversion was measured by how many sellers requested a “free home value consultation” at the end of the experience. We experimented with this in two ways:

  1. “Price Your Home” + “Request Consultation” form page, where customers can choose to submit a form
  2. “Get Started” page, where we directly ask for the customer’s phone number with a single call-to-action

Which one do you think performed better? Read on to find out.

Team and Role

I loved this project not only because it gave me full ownership as the designated UX/UI designer to build the product from start to finish, but also because I got to work with really great people. I worked closely with two others — Tom, probably the most hipster PM I’ve ever met and Kshitij, the full-stack developer who through our endless bickering over pixel perfection later became one of my closest friends. I was also blessed to have Andrew as my mentor and manager, who always believed in me and provided guidance when I was stumped.

The Work

FTUE Wireframe Flow

It was Tom who came up with the idea of FTUE, and I worked very closely with Tom to transform his wireframes to life. I was given the freedom to experiment and iterate profusely, creating different types of buttons, progress bars, information layouts, backgrounds, and copy to achieve the perfect user experience. I was able to pick up Sketch and Keynote for animations and prototyping, and I greatly improved my critical thinking, communication and copywriting skills.

Several Stages FTUE Went Through

There was meaning we instilled behind each element of FTUEs’ user experience. For instance, to prevent the user from feeling trapped and forced inside FTUE, I created an “X” action for each page, inserted “just looking” on the bottom of the first page, and made all the screens pop-ups to easily escape out of. In addition, the bottom progress bar is there to assure the customer that the experience will not deprive them of much time.

Our team worked seamlessly — Tom and I regularly discussed ways to improve the copy and visuals, we held regular design reviews to seek opinions from the design team, and we conducted multiple user studies along the way to determine how to perfect the product. I then passed off documentation to Kshitij and worked closely to make sure his code matched my designs. Initially we debated over many things, and Kshitij couldn’t understand why it mattered to move just a few pixels, but in the end we gained great respect and appreciation for each other’s work.

The Challenge

I worked with a flexible timeline, but was limited by a strict established style guide. As a result, I ran into conflict with the creative director on two things: 1. the button color and 2. the background imagery. My white buttons were deeply frowned upon because it was not one of the established button colors, and the creative director strongly advocated for black instead. In addition, everyone had a different opinion about what type of background to display. Some wanted faces of agents and customers, the creative director wanted shots of exterior homes, and others wanted images of the interior. As a result I went through hundreds of images in our library and several additional iterations just to find the perfect background. In the end, Tom decided to let testing decide.

We ran three different experiments. Experiment 1 showed black buttons with exterior homes, and experiment 2 showed white buttons with interior homes. Finally, experiment 3 had a single “call to action”, while experiment 1 and 2 showed the “Price Your Home” + “Request Consultation” form page mentioned before.

Test Metrics

  • Seen by 800 new users per day
  • 50% of users are buying
  • 25% are just looking
  • 20% close the form
  • 4% are both buying and selling
  • 1.5% are selling.

These numbers looked helpful and promising, but what about conversions?

2 home-value consultations.

Two home-value consultations requested was FTUE’s final conversion result. Having seen this number gathered after weeks of testing, the answer to the initial question, “which call to action” screen would perform better”, just didn’t matter anymore.

Lessons Learned

In the end, FTUE failed. Designing FTUE was a very humbling experience. I realized that as we got so caught up in the copy and visual aspect of the product, we missed perfecting the ultimate goal of the experience: converting customers to request sell-side consultations. The danger with usability studies is that it does not always emulate a real setting. People were unwilling to sign up for the type of cold-calling experience we created, and no matter how attractive or professional the pages and copy may look, that feeling would not change.

User-centered design cannot solely rely on data when you’re not asking the right questions. We began with our own assumptions, and we did not make the effort initially to understand what home buyers and sellers really wanted to know, or through which channel of communication they would find most comfortable taking the next step with. Above all, I learned not get too attached to my designs.

My ultimate lesson: Good product puts design first, and good design is more than building pretty screens — it’s about solving the right problem, and asking the right questions.