Project Overview
Tools:
Figma · Jira · Premiere Pro · After Effects
Golf Lounge: Social network designed to connect the world of golf
From idea to product
Golf Lounge started with a simple but real problem: golfers didn’t have a modern way to connect locally outside of private clubs or local leagues. Current social platforms were oversaturated and unfocused, while most golf apps prioritized utilities like GPS and scoring rather than community and connection.
I led product design for Golf Lounge from early concept through public launch. My work covered product strategy, UX/UI design, branding, feature definition, user research, and iteration. I worked alongside two developers, translated product decisions into clear requirements, and managed features and bugs in Jira.
Outside of product design, I handled company setup, brand identity, logo design, legal documents, the public marketing site (built in Framer), early V2 explorations, and go-to-market efforts. I also created short-form product videos – filming and editing in Premiere Pro and After Effects – to help market features pre and post launch.
From the start, one core constraint became clear: the value of a social network depends heavily on having enough active users in the same geographic area. Many features only worked well once a local community reached a certain size, which made early adoption and validation difficult.
Design decisions from real constraints
Balancing familiarity without over-focusing on social
Early usage showed that the home feed was where users spent the most time. I designed it to feel familiar, inspired from older versions of Instagram to help users feel comfortable quickly. At the same time, I didn't want the feed to become the center of the app. The goal was to make social posting feel easy and familiar, not to turn Golf Lounge into another social platform competing for attention.
Over time, engagement in the feed dropped as users realized they were already sharing similar content on other platforms. Rather than doubling down on social posting, I treated this as confirmation of the original product intent. The feed was designed to support local connection, not compete with existing social networks. Design decisions stayed focused on improving local discovery and community features, ensuring the product remained centered on helping golfers connect outside of the app.
Simplifying account types to avoid misuse
Early versions of Golf Lounge included three account types: Personal, Business, and a hybrid account for users who wanted professional presence while still connecting locally. While this sounded doable, this added complexity during signup and increased the risk of users choosing the wrong account type.
I eventually reduced the accounts to two options: Personal and Business. This simplified signup and avoided situations where companies could use personal accounts to access local features. While it meant giving up some flexibility for account types, this improved clarity and was well worth it early on.
Choosing connection over control in early-stage privacy
We launched Golf Lounge with minimal privacy barriers. Users could message other accounts freely, and all profiles were discoverable. This was intentional to prioritize connection while the network was still growing, knowing at some point down the road increased privacy settings would be improved.
To avoid things getting overly messy, the Bulletin Wall included a few simple safeguards. Posting and invitations were tied to current connections, and every follow request had to be approved. This added just enough friction to keep interactions intentional while still allowing people to discover each other.
Designing profiles for trust without verification
Because Golf Lounge centered on meeting locally, trust mattered early. I required profile photos to reduce anonymity and help users feel safer meeting someone new. Personal accounts were also encouraged to complete detailed profiles, including home course and skill level.
Business accounts had a lighter signup experience since they didn’t have access to local connection features. This kept onboarding simple for businesses that were mostly there to explore or post content.
Limits of third-party data
We relied on OpenStreetMap for course and location data. While it worked in most cases, missing or inaccurate data directly affected the experience, especially when users couldn’t tag their home course. We realized early how much the product depended on data quality outside our control.
Design decisions from real constraints
Balancing familiarity without over-focusing on social
Early usage showed that the home feed was where users spent the most time. I designed it to feel familiar, inspired from older versions of Instagram to help users feel comfortable quickly. At the same time, I didn't want the feed to become the center of the app. The goal was to make social posting feel easy and familiar, not to turn Golf Lounge into another social platform competing for attention.
Over time, engagement in the feed dropped as users realized they were already sharing similar content on other platforms. Rather than doubling down on social posting, I treated this as confirmation of the original product intent. The feed was designed to support local connection, not compete with existing social networks. Design decisions stayed focused on improving local discovery and community features, ensuring the product remained centered on helping golfers connect outside of the app.
Simplifying account types to avoid misuse
Early versions of Golf Lounge included three account types: Personal, Business, and a hybrid account for users who wanted professional presence while still connecting locally. While this sounded doable, this added complexity during signup and increased the risk of users choosing the wrong account type.
I eventually reduced the accounts to two options: Personal and Business. This simplified signup and avoided situations where companies could use personal accounts to access local features. While it meant giving up some flexibility for account types, this improved clarity and was well worth it early on.
Choosing connection over control in early-stage privacy
We launched Golf Lounge with minimal privacy barriers. Users could message other accounts freely, and all profiles were discoverable. This was intentional to prioritize connection while the network was still growing, knowing at some point down the road increased privacy settings would be improved.
To avoid things getting overly messy, the Bulletin Wall included a few simple safeguards. Posting and invitations were tied to current connections, and every follow request had to be approved. This added just enough friction to keep interactions intentional while still allowing people to discover each other.
Designing profiles for trust without verification
Because Golf Lounge centered on meeting locally, trust mattered early. I required profile photos to reduce anonymity and help users feel safer meeting someone new. Personal accounts were also encouraged to complete detailed profiles, including home course and skill level.
Business accounts had a lighter signup experience since they didn’t have access to local connection features. This kept onboarding simple for businesses that were mostly there to explore or post content.
Limits of third-party data
We relied on OpenStreetMap for course and location data. While it worked in most cases, missing or inaccurate data directly affected the experience, especially when users couldn’t tag their home course. We realized early how much the product depended on data quality outside our control.
Design decisions from real constraints
Balancing familiarity without over-focusing on social
Early usage showed that the home feed was where users spent the most time. I designed it to feel familiar, inspired from older versions of Instagram to help users feel comfortable quickly. At the same time, I didn't want the feed to become the center of the app. The goal was to make social posting feel easy and familiar, not to turn Golf Lounge into another social platform competing for attention.
Over time, engagement in the feed dropped as users realized they were already sharing similar content on other platforms. Rather than doubling down on social posting, I treated this as confirmation of the original product intent. The feed was designed to support local connection, not compete with existing social networks. Design decisions stayed focused on improving local discovery and community features, ensuring the product remained centered on helping golfers connect outside of the app.
Simplifying account types to avoid misuse
Early versions of Golf Lounge included three account types: Personal, Business, and a hybrid account for users who wanted professional presence while still connecting locally. While this sounded doable, this added complexity during signup and increased the risk of users choosing the wrong account type.
I eventually reduced the accounts to two options: Personal and Business. This simplified signup and avoided situations where companies could use personal accounts to access local features. While it meant giving up some flexibility for account types, this improved clarity and was well worth it early on.
Choosing connection over control in early-stage privacy
We launched Golf Lounge with minimal privacy barriers. Users could message other accounts freely, and all profiles were discoverable. This was intentional to prioritize connection while the network was still growing, knowing at some point down the road increased privacy settings would be improved.
To avoid things getting overly messy, the Bulletin Wall included a few simple safeguards. Posting and invitations were tied to current connections, and every follow request had to be approved. This added just enough friction to keep interactions intentional while still allowing people to discover each other.
Designing profiles for trust without verification
Because Golf Lounge centered on meeting locally, trust mattered early. I required profile photos to reduce anonymity and help users feel safer meeting someone new. Personal accounts were also encouraged to complete detailed profiles, including home course and skill level.
Business accounts had a lighter signup experience since they didn’t have access to local connection features. This kept onboarding simple for businesses that were mostly there to explore or post content.
Limits of third-party data
We relied on OpenStreetMap for course and location data. While it worked in most cases, missing or inaccurate data directly affected the experience, especially when users couldn’t tag their home course. We realized early how much the product depended on data quality outside our control.
Lessons from launching a social product
Onboarding depth vs early value
The onboarding flow asked for a lot up front, including location, home course, gender, skill level, and profile details. Although this information was necessary for local features, it created friction before users had a chance to see value.
If I were rebuilding this today, I’d move parts of profile depth later in the user journey, allowing users to explore first and complete their profile once they understood why the information mattered.
Community features amplify value, they don’t create it
The Bulletin Wall was a feature designed to help golfers organize rounds and meet new people. In theory, it gave the community tools to organize without formal leagues or schedules.
One thing i realized early on was its value wasn’t obvious enough. The feature relied on users taking the initiative to post and organize, and most people weren’t naturally inclined to do that. I projected my own behavior onto the golf community and overestimated how willing users would be to lead and host without clearer incentives or structure. Without enough local golfers or built-in momentum, the Bulletin Wall felt like effort instead of value.
Late in development, I added forums to encourage more community interaction beyond local discovery. While forums are a great feature for golf and were highly requested, they were introduced before the product had a strong active user base.
This taught me a lesson I now design by: community features amplify existing value, but they rarely create it. Without a clear reason to return to the app, even beautifully designed social spaces will struggle to keep up engagement.
Execution & Collaboration
I learned that product quality lives or dies in execution. Being clear about UX flows, UI behavior, edge cases, and bugs was huge for communication. I often used detailed screenshots instead of vague feedback to cut down on back-and-forth and to help engineers ship faster with clarity.
Below is an example of how I communicated UX, UI, and edge-case changes during implementation:
What I’d do differently
If I were building Golf Lounge again, I would lead with a strong utility feature, such as stat tracking with handicap management, and layer social features on top. A good utility feature gives users a clear reason to return, while community increases over time.
I would also redesign the Bulletin Wall as more permanent, location-based groups rather than user-created events, which would better align with how people naturally connect in communities.
Reflection
Golf Lounge showed that good UX alone doesn’t guarantee adoption. Clear value and solving a problem people genuinely care about mattered more than how many features you have or how polished your screens are.
Some features did well on their own, but the product struggled to reach the density needed for strong local networks to form. That made it difficult to separate product gaps from adoption challenges early on.
This project taught me how to evaluate product risk. It changed how I think about onboarding, utility-first value, and when social features actually earn their place. These lessons helped how I approach newer work like ScoutBase, where trust, incentives, and early value are validated.
Lessons from launching a social product
Onboarding depth vs early value
The onboarding flow asked for a lot up front, including location, home course, gender, skill level, and profile details. Although this information was necessary for local features, it created friction before users had a chance to see value.
If I were rebuilding this today, I’d move parts of profile depth later in the user journey, allowing users to explore first and complete their profile once they understood why the information mattered.
Community features amplify value, they don’t create it
The Bulletin Wall was a feature designed to help golfers organize rounds and meet new people. In theory, it gave the community tools to organize without formal leagues or schedules.
One thing i realized early on was its value wasn’t obvious enough. The feature relied on users taking the initiative to post and organize, and most people weren’t naturally inclined to do that. I projected my own behavior onto the golf community and overestimated how willing users would be to lead and host without clearer incentives or structure. Without enough local golfers or built-in momentum, the Bulletin Wall felt like effort instead of value.
Late in development, I added forums to encourage more community interaction beyond local discovery. While forums are a great feature for golf and were highly requested, they were introduced before the product had a strong active user base.
This taught me a lesson I now design by: community features amplify existing value, but they rarely create it. Without a clear reason to return to the app, even beautifully designed social spaces will struggle to keep up engagement.
Execution & Collaboration
I learned that product quality lives or dies in execution. Being clear about UX flows, UI behavior, edge cases, and bugs was huge for communication. I often used detailed screenshots instead of vague feedback to cut down on back-and-forth and to help engineers ship faster with clarity.
Below is an example of how I communicated UX, UI, and edge-case changes during implementation:
What I’d do differently
If I were building Golf Lounge again, I would lead with a strong utility feature, such as stat tracking with handicap management, and layer social features on top. A good utility feature gives users a clear reason to return, while community increases over time.
I would also redesign the Bulletin Wall as more permanent, location-based groups rather than user-created events, which would better align with how people naturally connect in communities.
Reflection
Golf Lounge showed that good UX alone doesn’t guarantee adoption. Clear value and solving a problem people genuinely care about mattered more than how many features you have or how polished your screens are.
Some features did well on their own, but the product struggled to reach the density needed for strong local networks to form. That made it difficult to separate product gaps from adoption challenges early on.
This project taught me how to evaluate product risk. It changed how I think about onboarding, utility-first value, and when social features actually earn their place. These lessons helped how I approach newer work like ScoutBase, where trust, incentives, and early value are validated.
Lessons from launching a social product
Onboarding depth vs early value
The onboarding flow asked for a lot up front, including location, home course, gender, skill level, and profile details. Although this information was necessary for local features, it created friction before users had a chance to see value.
If I were rebuilding this today, I’d move parts of profile depth later in the user journey, allowing users to explore first and complete their profile once they understood why the information mattered.
Community features amplify value, they don’t create it
The Bulletin Wall was a feature designed to help golfers organize rounds and meet new people. In theory, it gave the community tools to organize without formal leagues or schedules.
One thing i realized early on was its value wasn’t obvious enough. The feature relied on users taking the initiative to post and organize, and most people weren’t naturally inclined to do that. I projected my own behavior onto the golf community and overestimated how willing users would be to lead and host without clearer incentives or structure. Without enough local golfers or built-in momentum, the Bulletin Wall felt like effort instead of value.
Late in development, I added forums to encourage more community interaction beyond local discovery. While forums are a great feature for golf and were highly requested, they were introduced before the product had a strong active user base.
This taught me a lesson I now design by: community features amplify existing value, but they rarely create it. Without a clear reason to return to the app, even beautifully designed social spaces will struggle to keep up engagement.
Execution & Collaboration
I learned that product quality lives or dies in execution. Being clear about UX flows, UI behavior, edge cases, and bugs was huge for communication. I often used detailed screenshots instead of vague feedback to cut down on back-and-forth and to help engineers ship faster with clarity.
Below is an example of how I communicated UX, UI, and edge-case changes during implementation:
What I’d do differently
If I were building Golf Lounge again, I would lead with a strong utility feature, such as stat tracking with handicap management, and layer social features on top. A good utility feature gives users a clear reason to return, while community increases over time.
I would also redesign the Bulletin Wall as more permanent, location-based groups rather than user-created events, which would better align with how people naturally connect in communities.
Reflection
Golf Lounge showed that good UX alone doesn’t guarantee adoption. Clear value and solving a problem people genuinely care about mattered more than how many features you have or how polished your screens are.
Some features did well on their own, but the product struggled to reach the density needed for strong local networks to form. That made it difficult to separate product gaps from adoption challenges early on.
This project taught me how to evaluate product risk. It changed how I think about onboarding, utility-first value, and when social features actually earn their place. These lessons helped how I approach newer work like ScoutBase, where trust, incentives, and early value are validated.