poolware by Waterco • Pool maintenance software

Making pool scheduling simple

A scheduling platform had grown into a tangle of features.
We cut it back to what technicians and dispatchers actually use.

Weekly calendar view from August 14 to 19 for technician Eugene Lewinsky, showing scheduled pool maintenance tasks including Green Pool Treatment, Pool Check-up, Filter Change, Pump Mold, Oil Change, and Pump Change with status labels like Invoice Sent, Ready for Invoice, Action Required, Completed, Cancelled, and Not Started, each with assigned technician icons.
Role
Agency
Tools
Timeline
Lead Product Designer
Bapple, later webqem
Figma, Miro, Hotjar
Mar 2023 • Jan 2024

The problem: a classic case of feature-itis

Poolware manages bookings and tasks for pool technicians and the dispatchers who schedule them. It had grown complicated and hard to use. It was packed with features, but few of them worked well for the people using them every day.

"I print out the jobs, it's rained for 3 months where I live and phones get too wet."
Poolware prototype
Tech issues on the go

Technicians didn't always have reliable internet or recent devices. Filling in long job forms from their vans was slow and frustrating.

Workarounds that lost information

Many dispatchers weren't comfortable with the technology and built their own workarounds, so details about jobs, payments and notes were often lost.

"All the jobs I book for 2 o'clock means they're recurring."
Features nobody used

There was little training on the options, so most people stuck to the calendar, the one part they understood.

Complicated permissions

A confusing system of roles and access made any redesign risky.

mobile version

How we found out what was wrong

Interviews

We interviewed 10 people: 5 technicians and 5 dispatchers. Each session used a script, exercises and follow-up questions. One dispatcher in particular gave us insights that shaped our ideas.

Miro board of analysis
Service Blueprint

We ran a workshop with key stakeholders to map how technicians complete their tasks, adding feedback from dispatchers and managers. Technicians were the people the whole system depended on, because pools don't get cleaned however good the booking system is. So we followed their day and added lanes for every other role that crossed their path, in a service blueprint.

Service Blueprint workshop
Dispatchers

Dispatchers work closest to the technicians on site, a bit like a control tower guiding pilots. We ran card sorting, user flows, pros and cons exercises and usability tests with them, and with technicians.

How might we simplify the platform without losing the value of its features?

What we changed

customer case appointment
A better calendar

The calendar was the most-used feature, so it came first. We simplified it, made it easier to navigate and connected it to other tools.

A real dashboard

People were using the calendar as a stand-in for a dashboard, so we built a proper one with the important tasks and work stats, a better way to start the day.

Clearer appointments

Many users didn't know about features that would reduce their workload, and "hacked" the platform instead. Appointment types now use icons, tailored suggestions and personalisation.

Profiles for each role

Technicians and dispatchers now see only what they need, which makes the work less confusing.

Offline use

Technicians often work in remote areas with poor or no connection, so dispatchers were handing out paper forms and printed schedules. We proposed offline synchronisation and separate user accounts.

internal appointment

Process and expectations

• 3 to 4 rounds of low-fidelity wireframes to test and refine ideas.
• Moodboards: so we and the stakeholders could agree on the look and feel.
• Light prototypes early on for complex tasks.
• Remote presentations, including a final one attended by the CFO.

Stakeholders wanted to add features. Users needed the platform simplified. I facilitated workshops to line up technical constraints with user priorities and argued for feature reduction over feature expansion.

At one point, no matter how many iterations and meetings we had, we kept adding complexity. It took a hard stop and a redirection to prioritise features and to understand why the developers needed so many of them.

Results

• Users quickly started using the new dashboard and workflows.
• The client was pleased with the improvements and planned further updates.
• Technicians and dispatchers found their work easier to do, even with limited internet.

Waterco went on to keep developing its application suite and hired our team to work on a new app for its C-suite.

Retrospective

What I learned

This project taught me about quiet leadership and handling stakeholders with grace. The clients were open to our ideas and different perspectives. It was refreshing to avoid stereotypes like "make it pop" and make decisions from the business side that offered the best outcome for users.

What I would do differently

I wish we had built a small low-fidelity prototype to test with users, so we could compare their reactions with our designs and know what to work on first.
Back to work