Victor Maragioglio

Golfyr

I worked with DD COM AG, a digital design agency in Zürich, and was assigned to the Golfyr project as frontend developer.

This case study follows the delivery system around that work, then one product system built inside it: a multi-step configurator, shown as an abstraction of its logic. The original interface is not shown.

Year
2025
Role
Frontend Developer
Type
Product
Discipline
Frontend Development / Product UI
System
  • WordPress
  • WooCommerce
  • JavaScript
  • PHP
  • LazyBlocks
  • SwiperJS
  • localStorage
  • WPForms
  • HubSpot
Client
DD COM AG × Golfyr

01 The delivery system

Shipping inside an agency meant moving constantly between design, implementation, content, commerce, communication and measurement.

The tools changed. The work kept moving.

  1. 01DesignFigmaDesign file, component, interaction, specification.
  2. 02PlanJiraThe change is planned and ready.
  3. 03BuildJavaScript, PHP, WordPress, WooCommerceUI, logic, content and commerce.
  4. 04ConnectWPForms, HubSpotForm data leaves the product layer for the CRM.
  5. 05ReviewSlack, Microsoft Teams, JiraReview, comment, revision, review again.
  6. 06MeasureGoogle Analytics, Google Tag ManagerSignals come back from use.
  7. 07IterateFigma, JiraMeasurement feeds the next change.
Diagram showing a work item moving from design in Figma through Jira, implementation in JavaScript and PHP, WordPress and WooCommerce, integrations in WPForms and HubSpot, review in Slack, Microsoft Teams and Jira, and analytics in Google Analytics and Google Tag Manager, before feeding back into the next iteration. The system served the Golfyr project.
  1. Design: Figma. State: Design. Design file, component, interaction, specification.
  2. Plan: Jira. State: Ready. The change is planned and ready.
  3. Build: JavaScript, PHP, WordPress, WooCommerce. State: Building. UI, logic, content and commerce.
  4. Connect: WPForms, HubSpot. State: Building. Form data leaves the product layer for the CRM.
  5. Review: Slack, Microsoft Teams, Jira. State: Review. Review, comment, revision, review again.
  6. Measure: Google Analytics, Google Tag Manager. State: Live, then measured. Signals come back from use.
  7. Iterate: Figma, Jira. State: Iterate. Measurement feeds the next change.

02 Configuring the player

From the whole delivery system to one product system built inside it.

A multi-step configurator collected profile, measurement and performance inputs one question at a time. The challenge was not only moving through the flow, but preserving that state and carrying it into the next part of the journey.

01 The flow

A flow inside a larger flow

Three stages in the navigation. The first, captured here, holds eight steps: seven questions and a summary. Stages 2 and 3 exist in the navigation; their content is not part of this study.

02 Building the player profile

The state survives the screen

Seven inputs became one persistent player profile. Each answer leaves its screen and stays.

03 From answers to lead

The profile becomes the summary

At step 08 the collected answers are inserted into the summary, with their values and units, ahead of the contact details.

04 Under the interface

What carried the state

The interface looked sequential. Underneath, every answer had to survive navigation, validation and the handoff into the lead form.

Motion storyboard

  1. 01 Empty player profile
  2. 02 Questions begin
  3. 03 Answers move into the profile
  4. 04 7 / 7 parameters
  5. 05 Profile becomes summary
  6. 06 Summary enters the lead form
  7. 07 The system underneath
Stage 1, Choose your Set: captured, eight steps. Stage 2, Choose your Maker: in the navigation, not captured. Stage 3, Choose your Kit: in the navigation, not captured. Step 1 of 8, Gender (Profile): select input; marked required. The answer is added to the player profile. Step 2 of 8, Handicap (Profile): number input, range 0 to 54; not marked required. The answer is added to the player profile. Step 3 of 8, Height (Measurement): number and unit input, in cm or inch (default cm); marked required. The answer is added to the player profile. Step 4 of 8, Wrist-to-floor distance (Measurement): number and unit input, in cm or inch (default cm); not marked required. The answer is added to the player profile. Step 5 of 8, Glove size (Measurement): select and lookup input, with a reference table from hand length to size (S 170 to 185 mm, M 186 to 195 mm, ML 196 to 205 mm, L 206 to 215 mm, XL 216 to 225 mm); marked required. The answer is added to the player profile. Step 6 of 8, 7-iron shot distance (Performance): number and unit input, in m or yard (default m); marked required. The answer is added to the player profile. Step 7 of 8, Swing speed (Performance): select input; marked required. The answer is added to the player profile. Step 8 of 8, Summary and contact details: the configured set is pre-filled with the answers from steps 1 to 7, then First name (required), Last name (required), Mobile phone number (required), Email address (required), Additional notes, Consent to other communications, Privacy note. The submit action and the next state were not captured. Environment: WordPress, site and content blocks (LazyBlocks); WooCommerce, the wider commerce environment. 1. Question UI. 2. Step navigation: SwiperJS. 3. Validation: Client-side (Required and range logic; not observed in the captures.). 4. State: localStorage. 5. Summary generation. 6. Lead form: WPForms. 7. Form and backend integration: PHP. 8. CRM sync: HubSpot. 1. Empty player profile. 2. Questions begin. 3. Answers move into the profile. 4. 7 / 7 parameters. 5. Profile becomes summary. 6. Summary enters the lead form. 7. The system underneath.

Study notes

  • An abstraction of the configurator's logic. No original interface, copy, illustration, typography or colour is reproduced.
  • Stages 2 and 3 appear in the configurator's navigation; their content was not captured.
  • Values are illustrative, not captured test data.
  • Handicap and wrist-to-floor are not marked required; a general required-fields note appears on every step, including those two.
  • Only the required markers and the handicap range (0–54) are visible. Validation behaviour is implementation context, not observed.
  • The submit action and what follows step 08 were not captured.
  • The implementation view comes from my knowledge of the build, not from the captures.

03 Beyond the feature

The work extended well beyond the configurator.

Platform
WordPress · WooCommerce · PHP · JavaScript
Frontend
Responsive frontend development · Plugin maintenance
Measurement
Google Search Console · Google Tag Manager · Google Analytics · Analytics debugging · Tracking and debugging
Delivery
QA · Jira · Figma · Day-to-day implementation and production support

I really enjoyed working with Veera, Celin and Robin in a fast-paced, highly professional environment. It gave me a much better understanding of Swiss agency culture, and of the precision expected in high-end digital products, where small details and individual pixels genuinely matter.

WordPress and PHP are not the technologies I naturally reach for, but working with them at this level gave me a much greater appreciation for both. They have done an enormous amount to make the web accessible to businesses, publishers and developers, and working deep inside that ecosystem showed me why it has stayed so important for so long.

A fast-moving environment where implementation, communication and visual precision had to stay aligned.