DAD was a London based startup - backed by the insurance giant Homeserve - bringing homeowners instant access to home repair advice via chat and video calls.

The DAD mobile app allowed homeowners to connect via chat or video calls to plumbers, electricians, heating engineers and other tradesmen in seconds. It allowed them to show our tradesmen their repair issues (broken boilers, dripping taps, DIY unknowns, etc) live via video without the need for an expensive call out fee.

DAD’s experts could then explore and diagnose the problems remotely via video, and in many cases help the homeowners fix issues live while on the call with them. If a fix wasn’t possible while on a call, DAD was able to use a recording of each video call as a job briefing for tradesman who were booked to visit customers’ homes. This made home visits cheaper and more efficient as our tradesmen were able to bring the correct tools, materials and parts to every job – and they had a good idea how long it should take in advance of getting to a customer’s home.

I was initially brought in as a consultant for three days a week to help the founder develop their idea for applying technology to an as yet un-digitised market. We designed and built a proof of concept of what became the DAD service and app and unlocked additional funding from our corporate backer. I then joined DAD full-time as Head of Product Experience.

Unfortunately Homeserve stopped their funding at the end of 2016, so DAD was closed down.

1 year after launch we had:

  • Grown to 10,000 signed up customers
  • 30% m-o-m growth
  • a 25% call to job conversion

During my time with DAD:

I Helped understand the market opportunity

Photo of printed out Customer Journey map on an office wall Photo - Customer journey and emotion maps on the office wall

I helped understand the market opportunity by developing customer journey maps that showed the experiences of homeowners when things went wrong in their homes. These maps lead to the following insights that become the cornerstones of our business model:

  • poor communication was responsible for most negative experiences in the market
  • owning the end to end experience was important for a service addressing the market
  • getting an expert into a customer’s home as quickly as possible was key to giving them the best possible help.

(Read more about how developing customer journey maps helped us uncover insights that helped us develop DAD’s core product principles.)

I designed and ran proof on concept sessions to address early concerns about the feasibility of our suggested solutions

Photo of proof of concept testing session Photo - Early proof of concept testing session using FaceTime

When we first proposed the idea of using mobile video calls and chat to allow home repair experts view and diagnose customer’s problems we were met with scepticism. To test if the technology would work and, more importantly, if we could deliver a good service remotely, we ran a proof of concept workshop.

We gave an iPhone to some willing tradesmen and arranged for a number of volunteers with home repair issues to call via FaceTime to ask for help.

Our volunteers had a mixture of real issues and fake issues that we asked them to stage (such as flicking a fuse off and saying the power had gone off).

From these sessions we learnt that:

  • it was possible to provide a good service over a video call
  • tradesmen were able to see, diagnose and in some cases fix customer’s problems remotely
  • there were health and safety concerns that we needed to address (one caller was going to try climbing into their loft while holding a iPad in one hand)
  • the technology would work as long as the customer and tradesmen had decent network connections (and that people’s WIFI often doesn’t extend to the garage or utility room)
  • that being able to play back a recording of a call and see what advice was given was very useful for customers, and provided a great record of what was discussed and done which made our legal advisors happy.

I helped to define the problem we were addressing more clearly

In parallel to designing and building our product and service (see next section), I continued to question the assumptions we had made about the market, how customers dealt with the problems of home repair and the challenges tradesmen face during their working day.

To address some of the questions we had about our customer’s experiences, I designed a series of surveys that we ran UK wide to understand how they dealt with home repair issues. We looked at:

  • the frequency of home repair issues they experienced
  • the types of issues they experienced
  • how they found fixes for their issues

From these surveys we were able to report that only 10% of young people were able to change a plug. Only 6% knew how to bleed a radiator, and less than 5% can unblock a sink.

These insights helped us position our service and adapt our product features by giving us a better understanding of how our customers thought about their home repair issues.

I also attended market research workshops being run by Homeserve that were set up to explore:

  • their customer’s attitudes to non-emergency home repairs
  • independent tradesmen’s challenges with running their own businesses and finding work.

These workshops, while designed to answer questions Homeserve had about a slightly different proposition they were working on, gave me and the DAD team some great insights into customer behaviour and how we could work with independent tradesmen to help our customers.

I helped design the DAD service, powered by three different mobile apps

We designed and built three different DAD mobile apps that were the backbone of our service:

  1. our consumer iOS (and later Android) app which gave homeowners the ability to call our tradesmen, view their messages and appointments, review recordings of their calls with our tradesmen and manage their account and payment details
  2. our “expert” iPad app which allowed our tradesmen to make themselves available for customer calls, take those calls, take photos of what customers were showing them during a call and make notes about the call once it was over
  3. our “technician” iOS (and later Android) app that was given to tradesmen who were booked to visit customer’s homes. This app allowed them to see what appointments they had been assigned, to watch the associated call video and read any notes about their job, and gave them directions and times for getting to the job. It also allowed them to record pictures and video before, during, and after they completed the work to give us and DAD customers a complete record of what work was done.

I designed the Information Architectures for each of the above apps and documented their designs as annotated, low-fi wireframes which were used by our designers and developers as the specifications for each feature.

I managed the Product Roadmap, working to optimise our service

Once we had launched our MVP product, started running the service with real tradesmen and started to build our customer base, we needed to learn how to improve our products and overall service.

I helped to do this by managing our Product Roadmap, taking the feedback we were getting from our customers, tradesmen, marketing team, customer support team and everyone else across the business and translating them into sets of requirements that we reviewed on a regular basis to feed into our design and development planning sessions.

We also interviewed many of the customers that we had calls from to gauge their reaction to the service, how it worked (or didn’t work) how helpful it was.

The feedback from these interviews helped us identify elements of our products that we could improve. For example; we learnt that we needed to slow down the connection between a customer and a tradesmen when establishing a video call connection to give our customers more time to prepare themselves for being on video. Our initial design was too quick and people were a little surprised when they were connected immediately.

Over the course of the almost two years that we worked on the project in total, I produced a wide range of design artefacts that were used to explain requirements, test ideas and document designs. A selection of examples are shown below.

Example wireframes

Redacted example DAD wireframes Document – Example wireframes for the DAD apps

Example meeting output

Photos of example meeting output from DAD Photos – Example output from meetings at DAD

Example Information Architecture and process documentation

Examples of Information Architecture diagrams and process diagrams from my time at DAD Documents – Example Information Architecture and process documentation