Boatyard is an on-demand boating services platform that connects marinas, boat owners, and service providers. Features include a responsive web admin interface for service providers and their employees, and a consumer-facing mobile app that allows boat owners to seamlessly select, schedule, and pay for services. Whether it’s fuel, maintenance, engine service, cleaning, dive services, or chartering a ship captain, Boatyard makes ordering boat services simple and easy.
I was the PM and main designer on this project and created the I/A, flows, wireframes, and pixel-perfect mockups for both the web saas platform and mobile app. Since the client had already had a mobile app, we had to add and integrate new features that flowed with their existing app, while designing a completely new web saas platform. I used Jira for the QA process and managed a client-side designer who had designed the Boatyard website.
STAKEHOLDERS & TOUCHPOINTS
The main stakeholders were the boatowners, service providers, and Boatyard, which were then broken own by level of permission access, with certain service provider employee and Boatyard employee actions requiring approval by managers.
Customer (Boatowner) - mobile app for browsing and buying services and messaging with providers, boatyard website for buying services from providers, email/sms notifications
Service Provider Managers - admin web app, admin mobile app, admin tablet app
Service Provider Employee - admin mobile app, admin web app, admin mobile app
Boatyard Managers - admin web app with database of provider info and customer info
Boatyard Employees - admin web app with database of provider info and customer info
We wanted the platform to be flexible and not confine the Users to any set of flow since different Providers and Marinas had their own processes for running and managing their business. Some even used slips of paper to keep track of orders, which were often lost! Boatyard Admins also wanted a way to view all of their Providers in a dashboard to maintain quality of service, defined by response time with a built in messaging system that connected to SMS and email, as well as customer rating, which was provided through the Customer's mobile app. Customers could also track and see the status of their Orders through their mobile app.
The services offered were also varied in nature, where some were highly quantified such as gallons of fuel and others were not, such as cleaning the outside or inside of the boat so a hourly wage was difficult to ascertain until after the job had been finished. Payment flows also varied since some Providers required payment upfront, whereas others did not depending on the type of service offered. We also had to keep track of invoices and when they were overdue or paid, and higher-tier subscription services.
The client needed levels of permission (i.e. Boatyard did not want the Service Providers to view the Customer's info until they had accepted taking on the job to prevent platform leakage) so this was a interesting challenge for me as a designer. Many of the problems I had to solve were to juggle the various flows for a Boatyard Admin who assigns jobs to Service Providers, who then communicate with Customers about services needed, scheduling and payments. Scheduling would be dependent on Employee's other jobs and their current location so that we could optimise routes as well as know what materials or tools the Employee had on hand.
The main challenge was keeping track of multiple statuses - Order, Payment and Scheduling, and flows for 5 types of Users (Boatyard Admin, Boatyard Manager, Provider Admin, Provider Staff, or Customer) and to make it visually clear when each User needed to take an action in such a complex and multi-functional platform. To my surprise, many Providers did not use a digital system for managing orders, and instead used post-its, paper or a whiteboard, which lead to forgotten or delayed orders.
For version 1, we made a scheduler where the customers could input timeslots that worked for them, and the provider could select the one that best suited their routes. We planned on developing a way for the system to automatically schedule and route the orders in a future release. The providers could also select the employee that would be fulfilling the order.
I evaluated all the ways the Users communicated with each other - SMS, Mobile App, Email, Phone Calls, In-Person conversations and Messaging within the platform in order to consolidate them. We created copy for auto-replies and quick replies, which providers could customise. The main customer touchpoint was the mobile app, but the main provider touchpoint was the web app.
Provider Dashboard & Search
We designed an analytics page for Providers to track progress and offer tips to improve their service. Other constraints included designing an interface where the Provider Admin could review and approve actions taken by Provider Employees, and to help them assign Orders to Providers since many Providers only offered certain services, which was often dependent on location and model of boat.
Boatyard had the idea of having "Preferred Providers" for each Customer because they wanted to protect Providers from stealing customers from one another. However, from the customer point of view, they generally want to have choices when choosing a Provider, so it was a fascinating project since sometimes I'd design for the Customer's needs and other times for the Provider's or Boatyard's business needs.
Ultimately, we wanted the platform to be flexible and not confine the Users to any set of flow since different Providers and Marinas had different (and often unorganised!) ways of managing their business. Boatyard Admins also wanted a way to view all of their Providers in a dashboard to maintain quality of service, defined by response time with a built in messaging system that connected to SMS and email, as well as customer rating, which was provided through the Customer's mobile app. Customers could also choose scheduled slots, track and see the status of their Orders through their mobile app.