DRINKSTAR — UX Part
Back to main

DRINKSTAR — Product Case

To incentivise meaningful human relationships online and offline by becoming the primary touchpoint for hospitality, providing groundbreaking interactive tools to consumers, professionals, and businesses.

Domain
Event Management & HoReCa
Period
June – Sept 2024
Role
Product Designer, UX/UI
Market
United Kingdom

Purpose

A new tool for organizing events in bars and restaurants. It allows users to invite friends, discover new places, and expand their social circles. The system motivates users through a point system that can be exchanged for discounts at establishments.

Hangout is a feature that encourages users to participate in offline meetups and events at bars. It allows for easy organization of gatherings, inviting friends, and discovering new venues.

Tests & methodology

Quantitative Qualitative Prototype testing AI testing Double Diamond Segmentation Iterative Process

Scenarios: Creating a hangout · Joining an existing hangout

Other work

Design system: Refactoring and improving component base and approach.

Documentation: Writing documentation and describing components.

Dev communication: Collaborative work and planning improvements for components together with the team, creating processes for implementing components from the UI kit into the dev kit.


Goal

Encourage users to engage in offline interactions by creating an environment where they can easily organize meetups and events at bars. Promote venues through the platform and motivate users to organize events through a point system that can be exchanged for discounts.

🎯 Objectives

🧐 Issue

Many users remain in the online space and lack sufficient motivation to move communication offline. Bars are also not always recognized or visited by new customers due to limited visibility. We need to find a way to engage users in attending events and support venues in their promotion efforts.

Issue overview

Usage Scenarios

Scenario 01
Joining an Event
Key audience

The user searches for events in their city and joins those that align with their interests.

Scenario 02
Event Organization
Secondary audience

The user creates an event, selects a bar, invites friends, and opens it up for others to join.

Scenario 03
View Recommendations
Secondary audience

The user browses a list of bars based on recommendations from other users, ratings, and event locations.

Script Writing for Respondents

Script Writing

Our research focused on understanding what users truly want and the challenges they face. We began by creating a list of interview questions to gather in-depth feedback. All the questions were open-ended to allow participants to express their thoughts freely.

Since it was crucial for us to understand how they organize events, interact with bars, and perceive new connections, we divided our script into several topics: event organization, bar selection, social interactions, and motivation.

Interview

Interview

We used Google Meet for the interviews — it was convenient and quick for everyone. Each conversation lasted about 30–40 minutes. To streamline the process, we used tools like a 'note-taker' to capture key points.

Transcription

Transcription

After the meetings, we used automated transcription tools (such as Otter.ai and the notes recorded by our note-taker) and then manually reviewed the transcripts to ensure nothing was missed. We gathered all pieces of information, grouped them by topic, and highlighted the key points.


Persona Creation

Persona Creation

Based on the collected data, we began creating personas — fictional characters representing different types of users. We divided respondents into several groups, including those who frequently organize events and those who only join gatherings.

After that, we created a user journey for each persona, allowing us to prioritize their issues and identify the areas that needed attention first.

User Journey Map

Once we created these personas, we were able to move on to developing the first interface prototypes. This provided a foundation for designing solutions tailored to the real needs of our users.


Planning & Prototype Goals

At this stage, we also defined the key metrics for successful testing: time to complete each task, number of clicks, and task completion success rate. The main questions we asked ourselves were:

Creating Low-Fidelity Prototypes

Low-Fidelity Prototypes

The next step was creating low-fidelity mockups in Figma. Here, we focused on rapid prototyping, using only basic elements such as buttons, input fields, etc. The mockups were very simple — just grey blocks and placeholders for text — allowing us to concentrate on the core aspect: how the user navigates through the interface.

Our goal was to create:

Maze Testing

Maze Testing

In Maze, we created endpoints based on our scenarios. We linked the clickable Figma prototype with the user journey scenarios:

Maze tracks how long each action takes and the number of clicks made. We also wrote a script for testing with open-ended questions and included various question variations to ensure more objective assessments.

Maze script

Test Results & Iteration

Test results

We gathered all the test results and compiled them into a report, which we discussed as a team. During the team meeting, this report helped us identify major issues and uncover service gaps that we had missed, as well as discover interesting, non-obvious patterns. This allowed us to make informed decisions to improve the prototype.

Iteration

We were dissatisfied with the initial results, and after identifying significant mistakes, we iterated the process. After completing the testing cycles and implementing all the necessary changes in the low-fidelity prototypes, we prepared the final design version.

Thanks to the testing results, we gained confidence in the design's effectiveness and began work on creating the MVP version. We focused on the core functionality that would allow us to quickly test the product in a real environment and gather more user feedback.

MVP

Reworking the Design System

The old design system had serious issues. Each component was overly complex with an excessive number of unnecessary layers, often leading to overload. Everything was organized chaotically, without any system: styles lacked consistency, component naming was illogical, and layer structure was confusing. This made any changes challenging, as it required dealing with "chaos" in every component.

Old design system

Initially, we considered switching to ready-made component libraries such as Chakra UI or Ant Design. After presenting the pros and cons through iterative discussions with the client, it was decided that we would not transition to ready-made libraries at this time, based on business requests.

Reworking Components Gradually, Step by Step

Reworking components

Realizing that a one-time replacement of all components would not be effective, we chose a gradual, iterative approach. We started with the most problematic components, simplifying their structure by removing unnecessary layers and introducing logical organization, breaking them down into atoms and reworking them.

We applied the "baby steps" principle, making changes step by step and testing each component individually. This allowed us to maintain control over the process and avoid large-scale errors.

Implementing Design Tokens

Design tokens

While reworking the component structure, we simultaneously created variations for both light and dark themes. This made it easy to switch between themes by using different sets of color tokens for each one (e.g. primary-color-light or primary-color-dark).

Font tokens

In addition, we implemented the ability to quickly change fonts in the mockups using variables in Figma. This allowed us to easily adapt the mockups between iOS and web versions by simply replacing a few font tokens.

Font switching demo

Tokenization made our design system flexible and easy to adapt: now, changes in colours, fonts, or spacing can be implemented in just a few seconds, simplifying both the maintenance and future development of the product.

Optimization of Structure in Figma

Figma organization

Apart from component structuring, we completely reworked the organization in Figma. We built a new component structure with a minimal number of layers and a clear organization:

Communication with Developers

Developer communication

We worked closely with developers during the implementation of the new design system. Each component was documented in Confluence, including use cases, rare cases, instructions, and recommendations for its implementation.

Slack channel

For efficient communication, we created a dedicated channel in Slack where developers could get answers to their questions and make minor changes. We regularly conducted syncs to discuss the work status, gather feedback, and make adjustments to the design or documentation.


Final UI

Final UI overview

After multiple iterations and refinements, the interface has become significantly cleaner, more intuitive, and user-friendly. Through our systematic approach of testing and optimization, we successfully simplified the component structure, removed unnecessary complexity, and created a more streamlined user experience.

Screen 1 Screen 2 Screen 3 Screen 4 Screen 5 Screen 6 Screen 7 Screen 8

Plan & Product Improvements

After launching the product, our goal is continuous improvement using modern UX methodologies, analytics, and neural networks.

Plan

Integrating Metrics & Analytics