Project kickoff
The project started with stakeholders passing on customer feedback. TurnKey clients – owners of vacation rental properties – were frustrated that they couldn’t easily assign maintenance tasks to our team of property care experts. The business was likewise frustrated that TurnKey was spending so much money answering phone calls from owners. These calls took the time of a salaried customer service agent, and many were for simple requests like a status update on a requested maintenance. Owners had no other way of knowing what was going on with their managed vacation rental property.
It was not just a financial threat to the business. Declining NPS scores showed that this was causing a decrease in NPS, a key customer sentiment indicator which TurnKey watched closely.
CompanyTurnKey Vacation RentalsYear2017Duration12 weeksRoleResearch, interviews, wireframes, high-fidelity mock-ups, design quality assurance
A product manager and I interviewed 10 owners on the phone about this issue. We used a structured interview format that allowed for wide-ranging responses and lots of follow up questions.
The beginning of projects are always messy - I use structured notes as a way of organizing stakeholder feedback, customer interviews and decisions made during meetings
In this way the problem-solving process begins in the notebook. In this case, it was getting a clear picture of the needs of the business and the needs of customers.
There were key needs customers described to us: a need to reduce ambiguity about events happening at their property; and a need for autonomy, so they could request work without needing to call and speak to their support representative, who could be busy with another customer, etc.
Stakeholders at TurnKey saw an opportunity to become more efficient, to allow a smaller cadre of support agents to represent a larger number of customers.
In this project, there were two sets of users: the customers who requested work, and the backstage staff (field operations) who went to the rentals to complete the request. More on this in a minute.
My structured notes from interviews became a jobs-to-be-done spreadsheet. There's an easy translation between hierarchical interview notes and the order imposed by the jobs-to-be-done grid.
In the above jobs-to-be-done spreadsheet, we are organizing the needs of so-called ‘backstage’ actors (the field operations staff) who actually do the maintenance on the home. In order for a system to be useful to customers, the information would need to feed into our ticketing system for field operations. Aligning the needs and contexts of customers and field operations staff was a key part of this project.
We analyzed Turnkey 'backstage' systems and created a map of important processes
The complexity in this system was understanding the kinds of work that was being requested. In general there were two kinds; the system had to support one-off tasks, for example if the propane was low and needed a refill in a rental's gas grill. The system also had to support task assignment for tasks in a series, where the completion of one task would open the next task in the series. The ticketing system needed to differentiate between task types in order to deliver clear updates.
At Turnkey, the onboarding process and maintenance for vacation rentals would span weeks and sometimes months if there was an unforeseen delay. Work also pinged between various groups and departments – increasing the chances that something could be missed or go wrong.
I created this document mainly so I could understand the process. Up to this point there had been no visualization of the onboarding process. The written documentation was inaccurate and outdated. This document provided a ‘current state’ of the arduous process of onboarding a home. It also proved useful in leading discussions in other projects, since this document could be readily understood by company insiders.
As we converged on the idea for a ticketing system, we did a competitive analysis on other well-known ticketing and customer support tools.
While we were building a custom tool, we knew that some of the functionality had been done before by such companies as Zendesk. We determined early in the process that we couldn't just use a Zendesk-like product out of the box. We could look at their UI and workflows, however, and learn valuable lessons about how to construct our system for maximum efficiency and success.
We created an informal evaluative research project to show clickable low-fidelity paper prototypes to stakeholders and a select few customers.
We were looking to see if our prototypes matched users conceptual models, and if the UI gave wayfinding clues such that someone who had never seen it before understand its purpose, and how to navigate to additional actions. We used an interactive representation of the UI and asked participants to tell us what they would do if confronted with a given screen.
The results of our informal research told us we were moving in the right direction. We revised flows and screens where users had particular trouble understanding where to go next.
I didn’t use low-fidelity mockups beyond the paper prototype. With a design system in place and a design library in Sketch, creating these high-resolution screens had two advantages: first, it was just as fast as creating a flow in lower fidelity. Second, it gave us the opportunity to put in contextual information that would be present in the end application, such as photos, names, dates and more.
Flow charts like this one helped me visualize the entire scope of the application. They also helped to find areas of the app that hadn't been well thought through.
Flow diagrams are a helpful artifact. They can lay out all screens of an application in one place; they can represent user paths through all aspects of an app; and they're helpful to give developers a good sense of how each screen relates to the other.
On this project, flow diagrams were a working document. As I built out flows, I could make sure that I had thought through each piece of functionality. In the snapshot of this document, I have yet to build out flows for 'add a photo' and 'add a file', two important functions for the product.
Staying organized with unified naming conventions helps communication during the handoff between design and engineering.
Practices like this help make small efficiencies across a design and engineering process.
Solution overview
We used TurnKey’s design system to quickly build high-resolution mockups based on the flows shown in earlier steps. These helped give the stakeholders and development team a sense of what the app would look like. Due to our earlier work wireframing, the development team could start coding without needing a complete set of high-resolution mockups. Those could be completed as the team worked on other parts of the application.
A rendering of the customer support app in desktop, laptop, tablet, and mobile views. Three breakpoints were included in the final design spec.
Not quite done...pre launch we got into a room with engineers and completed a 'Design QA' ceremony
This project kicked off a tradition at TurnKey. Rather than go back and forth in JIRA to resolve issues we saw in the product before launch, we decided it would be faster (and more fun) to all get in a room together, and to run quality assurance in person.
Most of the issues were small UI changes that we fast to execute. Doing this process had a couple of advantages: it cut way down on the overhead of creating and managing tickets; it helped engineers see the product through a designer’s eyes; and it created a strong ‘in it together’ bond for the development and design teams. It also was a good ceremony to get everyone – product managers, engineers, designers and stakeholders together – to celebrate the closing of a big piece of work.
Project outcomes
+32%
Improvement in resolution time for cases created on the project board
+9%
Increase in five-star ratings, for cases created on the project board