HomeServe’s innovation arm, HomeServe Labs, came to 383 to work on their digital strategy, looking to define and build a new mobile customer experience. The core element of that strategy was a new mobile application where customers could view their products and services, submit claims, manage their accounts, and view handy hints and advice from engineers. We spent a lot of time mapping our the customer journey, identifying points of friction, and understanding how we could create an experience that would provide genuine utility – not just another app to be downloaded and forgotten.
Our case study looks at the process of imagining and defining the mobile experience, balancing user-centered design with business goals to determine technical and functional requirements. In this blog I want to go into a bit more detail about how we built the application.
Building the vision
Part of the new digital vision was to re-imagine how customers interacted with HomeServe and the platforms and devices that they used to manage their products. This strategy took two main forms; one was customer facing, whilst the other looked at their backend systems and platforms.
The mobile application was a key part of the vision, allowing HomeServe customers to access their accounts wherever they were, in addition to providing extra utility that could only be derived from native apps, such as video calling. To bring the vision to life, we needed to integrate the customer app with HomeServe’s backend systems – some of which had APIs, some of which had never been exposed to the outside world before. We worked closely with HomeServe to create a new set of API endpoints to enable us to embed the required functionality within the apps.
For this build, we adopted an agile approach for delivery, mapping out an ideal set of requirements and shaping these into two week product sprints, working towards an initial release of the app. The progress of each feature was tracked on a Kanban board, with additional requests and new ideas tracked in an icebox for future consideration. The board was shared with the HomeServe product team and the wider business, so everyone on the project had visibility on the progress and status of any feature, across a range of devices.
Before any code was written, the 383 engineering team met with the HomeServe team for a whiteboard session to plan out how our app was going to interface with the HomeServe systems. As this hadn’t been done before, there weren’t any existing APIs that could be opened up to us. We therefore had to map out the data we’d need against the proposed functionality and come up with a data structure to meet those needs.
We decided on a RESTful set of endpoints that would either return JSON data or HTML to be displayed within a webview. We’re big fans of GitHub at 383 and we used private repos to store our code. For documentation, we used the Wiki and Gist features to map out the expected request and response parameters.
It’s said that a picture paints a thousand words. If that’s the case, then a mock endpoint saves a thousand meetings.
Once we had agreed on a proposed structure for the data, we needed to be able to develop the app against it and set up scenarios to test how our app would be able to handle responses, both good and bad.
We used a service called Sandbox – I really can’t recommend this enough if you’re building API driven apps – to structure each route and the response. Sandbox makes it really easy to script a custom response based on the input. This was particularly useful for HomeServe as there was a set of criteria for how different types of account would be able to interact with the app, in addition to simulating an expired account. Using a few lines of Node, all of the various scenarios could be quickly scripted against a set of test user accounts, with each response serving the correct HTTP response code.
Once we had a set of endpoints built, we needed to test their integrity and turned to Runscope to set up a test for each endpoint, writing assertions to ensure that each test user would return back the correct response code and data. This formed our developer contract and meant that we had a reliable way to ensure that we were building the app against something that could easily be tested. It also meant that when the HomeServe team developed the real endpoints, we could re-test using Runscope before making any changes to the app to ensure that we didn’t waste valuable development time debugging an endpoint that was returning data in the wrong format.
Throughout the build, we upheld the agile principles of releasing often and continuously, getting feedback from users throughout. To do this, we used BuddyBuild to have continuous deployment of the app. BuddyBuild is an amazing service that allows us to ship the latest build of an app to test users each time code is pushed to a branch, automatically installing our dependencies and libraries. The app can then be distributed to various team, capturing feedback and crashes and automatically piping updates to a shared Slack channel.
One of the great things about working with HomeServe was the close proximity of our offices, which made it really easy to get together to demonstrate app progress and run through feature requests. We worked out of each other’s offices so we could easily ask questions and get immediate feedback. Even with tools like Slack and video calls, getting together for face to face meetings was invaluable.
The resulting mobil app provided an entirely new experience for HomeServe customers, giving them a new way to manage their account and look after their homes. Alongside the app, we worked with the team to develop a prioritised roadmap, with a backlog of features for future development.
Like what you see? We’ve got more where that came from.