UX Design · Service Design · Community platform · Sailing
Cruising Club Platform
A digital platform for a sailing cruising club, replacing paper-based processes with a member-facing system for trip planning, crew management, and club governance. Built to the same standard as commercial products, without a commercial budget.
The problem
Most small clubs run on spreadsheets, email chains and institutional memory. The result is a system that works fine when the right people are in the room and breaks quietly when they are not. This project asks what it would look like to design that infrastructure properly, a coherent, member-facing platform that handles the operational reality of running a cruising programme while remaining simple enough that volunteers can maintain it.
The approach
Good software begins with good thinking, and good thinking has to be written down before a line of code is written. This project follows that discipline rigorously. The Business Requirements Document establishes why the platform needs to exist and what problem it is solving. The Functional Specification translates those requirements into a precise description of what the system must do. The prototype begins only once both documents are complete, reviewed, challenged and agreed.
That order is not procedural caution. It is professional practice. Organisations that skip the specification stage routinely build the wrong thing correctly: software that functions as designed but solves the wrong problem, or solves the right problem for the wrong people. A well-constructed BRD and FSD do not slow a project down. They prevent the far more expensive work of undoing decisions that were never explicitly made.
The outcome
The documentation here is intended to demonstrate that approach, and to serve as a model for any small organisation considering a digital product. The prototype and service design that follow are only as good as the specification they were built from.
Section 1
Committee Preview
The documentation package prepared for the club committee. These documents exist before any prototype, any design decision, any line of code. The BRD defines the problem in terms the whole organisation can agree on. The FSD describes the solution in terms precise enough to build from. Together they form the contract between what the project is trying to do and how it intends to do it, and the basis on which any future development can be evaluated, costed, or handed to a third party.
Section 2
Prototype
A working prototype of the platform, covering the member-facing surfaces: trip listings, crew sign-up, skipper dashboards, and club news. Built in code rather than Figma so that the committee can interact with real flows, not static screens. The rationale and design decisions are documented at the prototype site itself.
Section 3
Service Design & User Journey
The full end-to-end service design maps every touchpoint across the member lifecycle: from first discovery through active participation to the point where members take on organiser or skipper roles. The plan below outlines the delivery stages.