GetSociable helps people find social events and meet others nearby. My Design Engineer placement covered the work from reviewing the existing app to designing changes, building interactive prototypes and documenting decisions for developer handoff.
I worked with the product and engineering team on onboarding, discovery and search, using an AI-assisted playground to try multiple versions of the designs.
Scope and research
I reviewed onboarding, the home feed, discovery, maps, itinerary planning and social features. I compared the live app with the design documentation and findings from two rounds of user testing completed before I joined.
The review identified three areas to address:
- Onboarding: people had to provide personal details and choose multiple interests before they could explore events.
- Content hierarchy: similar types of content were presented differently across sections.
- Location: the interface did not clearly distinguish a person's home city from a city they wanted to browse.
The design system audit also identified consistency gaps in the existing Figma components.
Design changes
Onboarding: separate the setup decisions
The existing flow asked for a city, gender, date of birth and preferences before showing events. Selecting multiple interests was required to continue.
The audit and earlier testing highlighted people leaving before understanding why the app needed this information. This raised two separate questions: how to present each step, and what to ask before someone could explore.
I restructured the flow around one question per screen to give each decision a clear focus. That addressed the presentation of the questions; it did not, by itself, reduce the amount of information required. I also reviewed when to request location and notification permissions and explored Google, Apple and email sign-in options.
For location, I made the distinction between home city and browsing city explicit. Someone planning a trip should be able to look for events at their destination without mistaking that choice for a change to where they live.
Discovery: revise the layout after team feedback
My first proposal used the same layout across discovery sections to address inconsistencies in the feed. The product team pointed out that some sections used carousels deliberately and that the proposed layout made their content harder to scan.
I revised the designs to retain those carousels and used a more structured layout in sections where comparing items was the priority. The feedback helped me distinguish which differences needed fixing and which supported the content.
Search: balance detail and comparison
I compared search layouts around one question: how much information does someone need to distinguish one event from another? The tradeoff was between showing more detail for each event and keeping the results easy to scan together.
Building a prototyping playground
I built a playground using AI-assisted prototyping to shorten the process of turning a design idea into something I could interact with. I used it to try multiple iterations, test how the interactions behaved and compare alternatives before choosing a direction.
The playground supported my own design checks: I could work through a prototype, revise it and try the interaction again. The earlier user-testing findings and product team feedback informed what I explored.
Documenting decisions for handoff
I paired the prototypes with a developer handoff covering the design decisions and their rationale. The aim was to explain the intended behaviour as well as the screens.
The distinction between home city and browsing city, for example, matters beyond the wording of a field: browsing another destination should not imply changing where someone lives. Similarly, the discovery revisions needed to preserve the carousels chosen for particular sections. These were the kinds of decisions the handoff needed to carry through into implementation.
What I took from the work
My first discovery proposal treated a shared layout as the answer to inconsistent presentation. Team feedback showed why that was too broad: the sections held different content and did not all benefit from the same treatment. I revised the recommendation to account for how each section was used.
That decision also shaped the handoff. Recording why a pattern should stay was as useful as explaining what should change.