Teeket

My work included:

• Defining and refreshing the design system.
• Redesigning the creator and attendee journeys.
• Designing analytics, reminders, and marketing messages.
• Repositioning the landing page around creator needs.
• Questioning feature requirements with the product lead and engineering team.
• Creating interactive prototypes that developers adapted to the existing codebase and APIs.
• Working in code to improve consistency between the designs and the shipped interface.

The existing product helped people create events and sell tickets, but the emerging opportunity extended beyond the transaction.

Creators wanted access to their past and present attendees so they could communicate, promote upcoming events, and maintain a relationship between events. Analytics could help them understand performance; communication tools could help them act on that understanding.

The product needed to support that relationship without becoming overloaded with features. It also needed a clearer creation experience and a consistent interface that engineering could maintain as the product grew.

Creators were an important source of traffic

More visitors entered Teeket through event pages than through the landing page. This suggested that creators' promotional activity was an important route into the platform. That finding informed the creator-focused direction. The homepage could explain Teeket's value to organisers, while event pages continued to serve the audiences they brought.

Customer requests revealed needs, but not always broad demand

Requests helped us identify opportunities, but I examined the problem behind each one before adding it to the roadmap. Some requests addressed a recurring creator need. Others were specific to one event format and would require substantial engineering work without evidence of wider demand.

Design consistency was a delivery problem

For more than nine months, the implemented interface had struggled to match the design system. New features could look noticeably different from their intended designs. Improving the product therefore required closer involvement in implementation as well as refreshed design files.

We needed to learn about the new direction while keeping development manageable.

A recurring trade-off was whether to build a flexible feature immediately or start with a narrower version that could reveal how creators actually used it.

I prioritised requirements that supported the creator-focused direction, had evidence behind them, and could be delivered without overwhelming engineering. This meant postponing some appealing ideas until we had a stronger reason to build them.

1. Make publishing possible before asking for every configuration

The previous event-creation journey required five phases. I reduced the required publishing flow to one initial step containing the essential event details.

Creators could publish after completing those details, then return to configure rules, reminders, and other settings.

This separated what was necessary to launch an event from what could be configured later, reducing the amount creators had to work through before publishing.

Required creation phases: five → one.

2. Connect performance insights with audience communication

I designed analytics to help creators understand their event performance, alongside tools for reminders and marketing messages.

Together, these capabilities supported the intended progression: create an event, understand its audience, and communicate with that audience again.

Analytics is live. Reminders and blasts have recently launched, so their effect on engagement and repeat attendance is still to be evaluated.

3. Start with predefined messages before building a template editor

The engineering lead proposed a template builder for reminders and blasts. I recommended starting with a fixed set of templates.

This gave us a smaller initial release and an opportunity to learn which messages creators used, what they wanted to change, and whether a more flexible builder was necessary.

The decision kept development focused while leaving room to expand based on actual usage.

4. Question specialised requests before committing engineering time

One customer requested an event structure with multiple workshops, each with a separate ticket connected to a parent event. I explored the requirement with the product lead. At that point, we had no clear signal that other customers needed the same structure.

I recommended keeping it out of the pipeline until broader demand emerged. The request was useful evidence of one customer's situation, but insufficient evidence for a substantial platform capability.

5. Align the landing page and shipped interface with the direction

I shifted the landing page's emphasis towards creators and experiential marketing, reflecting where the business was going.

I also worked more closely with the code and design system to address implementation inconsistencies. This helped bring the shipped experience closer to the intended design and established a stronger foundation for subsequent features.