Dean Fankhauser
Let's build the best


ITH stands for In The House and it's an app that allows landlords to do viewings, virtually.


ITH was an internal project on behalf of Santander. It was part of Venture Studios which is a team I was leading to create and spin out 2-3 Proptech startups per year.

The team consisted of designers, developers, researchers and product managers who first took part in a discovery phase which this idea passed and went on to 'deep dive' and later seed investment from the company.

Some of the core features of the app include:

  • Frictionless onboarding. No signup required.

  • Simple video creation

  • Appointment scheduling / waiting room

  • Seamless sharing on existing realestate and social platforms

  • Real-time commenting

  • Warm lead contacting from landlords

After these projects, they went so well I was promoted to Head of Product and oversaw design and tech across web, iOS and Android. I was responsible for growth, engagement and monetisation.

In this case study, I'll show you my on-boarding work.

My role

  • Product strategy

  • User research & Analysis

  • Persona creation

  • Sitemaps & user flows

  • Wireframes

  • Prototyping

  • Usability Testing


Agile, Lean UX, UCD


Sketch, Invision, Principle

The process

  • Define problems and goals
  • Competitive analysis to gain insights on what others are doing and where the standards currently are
  • Personas to help define who we're building this product for and remind the team that it's not for us
  • User flows & sitemaps taking into account our research and what's most important to the user
  • Sketches & wireframing based on the user flows that we could start to test with the user
  • Prototype to test flows and usability
  • Annotate to deliver to tech team in a clear and concise way
Defining problems & goals


We had a conversion problem. People were downloading the app, but not installingPeople's expectation of what the app was and how it can be used were worlds apart from realityMany of those who were installing dropped off and never came back


Make marketing communications and product designs flow properly from advertising to first experienceDevelop a data-based framework that would tell us what types of users were most engaged (eg users who uploaded 10 photos and made 3 connections by day 4 were most engaged) Make sure we only target the most engaged user types in our marketing and once we have them, make sure they perform the same actions that our most engaged users do the first time they use the app


In order to better understand where our competitors were potentially going right or wrong, we ran an analysis. This was a challenge because Lifecake doesn't have much direct competition, so we were broad in our scope and ran an on boarding benchmark test across most successful apps.

Benchmarking summary

There was an analysis done on roughly 15 leading companies. We noted the best and worst parts of each to help us inform the design and where we can avoid mistakes and implement some of the industries best ideas.

When doing this analysis, it was important not to look only at direct competitors. In fact, most of our direct competitors did a pretty poor job of onboarding, so we looked at industries that were often completely different to ours, yet needed to onboard in a similar way.

After looking at our own data as well as benchmarking, we quickly realised our existing iOS landing page was too vague and didn't explain what the product did and how it was valuable enough to invest the time and effort to continue with on-boarding.

To further prove this theory, we tested it with people on the streets of London to see how they reacted to our existing on-boarding. Again, based on our existing design it seemed like a vague proposition that wasn't valuable enough for our target market.



Based on the interviews/workshop we set up three personas. We referred to them throughout the entire product development process.

  • When developing the personas, we used a mixture of our user research and stakeholder insights
  • We decided we needed personas when we found ourselves referring to our own needs instead of the target customer's.
  • Once developed, it was our north star for the designers, developers and stakeholders
  • It helped give clarity to the project and remind us that we're not developing this for ourselves.

We wanted to make sure we have everything in order before we started this project. We needed to understand what the architecture of the site was and how we could optimise it.

User flows

Before jumping into sketches, it was time to explore user flows and work very closely with both front-end and back-end developers to make sure we were optimising them in a way that was user friendly but also worked with their legacy system.

This was enormously challenging. Instead of developing a fresh on-boarding system with the latest technologies, we had to accommodate for those who were already users and had signed up in completely different ways.

Sketches & wireframing

I always like to start with hand-drawn wireframes and sketches first. It's fast, easy and can be very collaborative.


We primarily used Principle for all our prototypes. This worked well as it's very high-fidelity and it can be produced fast. It doesn't require any coding, yet still has many of the benefits of software that do.



Once we had solid prototypes, we tested in the wild. This was guerrilla testing where we took notes and made adjustments to our prototypes and designs based on the feedback.

Annotations & deliverables

While prototyping was useful for the developers, it didn't tell them all the details they needed. In addition to prototypes, we delivered this very detailed PDF with full annotations and flows.

All design files were exported into Zeplin.

End results

We tried to keep Android and iOS as similar as possible. 

Increased conversions
3 million
Increased invitations
Increased photos