Converting

users

to

creators

@

I

streamlined

Clyx's

event

creation

flow

to

broaden

the

context

of

what

an

event

can

be,

increase

UGC

volume

&

empower

more

users

to

become

creators.

Role:

UX Lead

Duration:

4 weeks

Skills:

UX:UI

design,

quant

methods,

qual

methods,

prototyping

Languages:

HTML

Tools:

Figma,

Figjam,

Mixpanel,

Zoom,

Typeform,

OneSignal

Clyx creation flow
My Role

As UX Lead, I led the end-to-end process from identifying the conversion problem through to designing, and testing. This included analyzing behavioral data, conducting user interviews, designing solutions, and working closely with growth and engineering to ship and iterate quickly. My focus was on linking user behavior to measurable content growth outcomes.

Context

Clyx has two event content sources: partners, and users. While partner events bring in revenue, user events build culture. We wanted users to land on the home page and see a buzzing network full of social proof.

Question

The majority of users open the creation flow during their lifecycle but only a minority complete the process and organize an in-person event.

How do we encourage more users to post without degrading event quality?

Defining Success
01

+20% Conversion

% of active users that have created an event

02

+30%
Completion

% of creation flow starts that end in completion

02

0% change in avg. event engagement

% difference in avg. engagement per UGC event

Research

To understand why users dropped off in the creation flow, I combined qualitative insight with behavioral analytics. This focused on identifying where friction occurred, how users interpreted the creation process, and what prevented them from taking action.

Process
Prototype evaluation framework
Time on task

Quantitative

How long do users take in each phase and overall?

Error patterns

Qualitative

Where in the flow are users getting stuck?

Comprehension

Qualitative

How confident do users feel while using it?

Desirability

Qualitative

Which flows do user prefer using?

Prototype variations

Number of mandatory fields

Order and grouping of information

Default options

Flow structure (linear vs hub-based)

Interview topics

Willingness to join events at different levels of event finalization

Perceived event quality at different levels of event finalization

Willingness to post with pending event details

Key insights
01

From usability testing

Users struggled with too many detail options

Users frequently slowed down or got stuck while filling in event details that may be unconfirmed, slow to source, or irrelevant to their event.

02

From usability testing & interviews

The previous linear flow increased perceived effort

Having users go page to page filling in details increased perceived effort even if they could skip fields.

03

From interviews

Users overestimated formality

Having too many required inputs produced overestimations of formality, unnecessarily raising the bar for what a Clyx 'event' could be.

04

From usage analytics & interviews

The benefit of finalizing at posting was negligible

Users were happy to join events and help finalize the details based on what worked for them

Ideation & synthesis
01

Insight-driven brainstorming

After researching, we developed a pool of possible solutions backed by our insights.

02

Affinity
Mapping

To synthesise our potential solutions, we thematically grouped them to combine overlapping options.

03

Development cost analysis

Finally, we compared expected dev costs to find the right balance of cost and potential benefit.

User flow & wireframing

The solution focused on reducing both actual and perceived friction while expanding the definition of what an event could be. We began the design process by creating wireframes - focusing on information architecture while minimising development cost.

The primary distinction against the original flow was switching from a linear flow to a hub with subsidiary details pages.

Further, rather than requiring users to fully define an event upfront, the flow was redesigned to allow users to post quickly and refine details later using existing event detail management flows.

Designs

Primary event details

Straight to the point

The only required detail is the event title which is prominently displayed at the top.

Secondary event details

Simple by default

Time & place are given defaults, enabling users to decide now or later.

Tertiary event details

Easy access

All the extra detail options are out of the way but easily accessible.

Impact

Conversion

75%

Higher conversion from user to content-creator

9.07% baseline, 6.8ppt uplift

Completion

24%

Higher completion rate from opening to posting

58% baseline, 13.9ppt uplift

Downstream minimization

~0%

Decrease in avg. joins per UGC event

No statistically significant difference

01

Step-by-step flow changed to a central hub with sub pages

To reduce the number of potential drop off points.

02

All detail fields are made optional except the title

To reduce the number of barriers to posting.

04

Detail options are grouped by importance

To incrementally encourage users to add optional details without overwhelming them.

05

A bottom sheet is used instead of a full page

To clarify the connection between the creation flow and the home feed.

Solution
01

Step-by-step flow changed to a central hub with sub pages

To reduce the number of potential drop off points

02

All detail fields except the title are given defaults with optional editing

To reduce the number of barriers to posting

Wireframes
01

Detail options are grouped by importance

To incrementally encourage users to add detail optional without overwhelming them

02

A bottom sheet is used instead of a full page

To clarify the connection between the creation process and the home feed.

03

Most assets from the previous iteration are reused

To reduce development
cost and maintain our release cycle.

Solution
01

Step-by-step flow changed to a central hub with sub pages

To reduce the number of potential drop off points

02

All detail fields except the title are given defaults with optional editing

To reduce the number of barriers to posting

03

Detail options are grouped by importance

To incrementally encourage users to add detail optional without overwhelming them

04

Most assets from the previous iteration are reused

To reduce development
cost and maintain our release cycle.

Designs

Straight to the point

The only required detail is the event title which is prominently displayed at the top

Simple defaults

Time & place are given defaults, enabling users to decide now or later

Easy access

All the extra detail options are out of the way but easily accessible