Create Event flow for UNATION
Dolgo is an AI platform built for the maritime industry to help preserve and transfer mission-critical expertise before it disappears with retiring workers. Designed specifically for shipyards, maritime engineers, and technical crews, the platform captures real-world operational knowledge and makes it accessible exactly when it’s needed most.
Project details
UNATION is a Tampa Bay events platform and social media agency. Its clients — venues, restaurants, breweries, festivals, local businesses — publish events and sell tickets through UNATION.
Until this project they could only do that from a desktop dashboard: a dense, unstyled, non-responsive form built years before the current product. Clients ran their businesses from a phone. Creating an event required a laptop.
The founder's brief was direct: bring event creation into the app, without losing a single field.
That parity constraint is the whole story. I wasn't designing new capability — I was redesigning how existing capability is sequenced, grouped and rendered at 390pt wide.
Role
Senior UI designer
Team
Founder
1 Flutter dev
3 backend engineers
Deliverables
Flow architecture
Interaction design
UI & components
Handoff
Year
2025 / 2026
The problem
Three things were wrong:
Desktop only. The form wasn't responsive. On a phone it was unusable.
One long page. Every field for every event type, presented flat, with no sense of what mattered or how far along you were.
All or nothing. A client who ran out of time or was missing ticket details had no good way to stop and come back.
Event creation is a genuinely long task — dates, venue, imagery, categories, ticket tiers, add-ons. The old form treated all of it as equally urgent.
Constrains
Feature parity was non-negotiable. Nothing could be dropped or deferred to a later release.
No research budget. No analytics on the desktop funnel, no interviews, no usability sessions. Decisions had to be defensible from product logic and precedent, not data.
A single Flutter developer. Anything I specified had to be buildable by one engineer without bespoke components.
Existing backend model. The three-person backend team had a fixed event schema. I could re-sequence fields; I couldn't restructure what an event is.
The absence of research is worth being honest about rather than papering over. What I did instead was lean hard on convention: I used Luma as the primary reference for how a modern event creation flow paces itself, and Basecamp for one specific problem it solves unusually well.
Preview of the existing desktop create event builder
The problem
Three things were wrong:
Desktop only. The form wasn't responsive. On a phone it was unusable.
One long page. Every field for every event type, presented flat, with no sense of what mattered or how far along you were.
All or nothing. A client who ran out of time or was missing ticket details had no good way to stop and come back.
Event creation is a genuinely long task — dates, venue, imagery, categories, ticket tiers, add-ons. The old form treated all of it as equally urgent.
Constrains
Feature parity was non-negotiable. Nothing could be dropped or deferred to a later release.
No research budget. No analytics on the desktop funnel, no interviews, no usability sessions. Decisions had to be defensible from product logic and precedent, not data.
A single Flutter developer. Anything I specified had to be buildable by one engineer without bespoke components.
Existing backend model. The three-person backend team had a fixed event schema. I could re-sequence fields; I couldn't restructure what an event is.
The absence of research is worth being honest about rather than papering over. What I did instead was lean hard on convention: I used Luma as the primary reference for how a modern event creation flow paces itself, and Basecamp for one specific problem it solves unusually well.
The structure: 4 steps
I split creation into four sequential steps, each independently savable.
Step
Contains
Why here
1. Event details
Name, date & time, venue, description, imagery, category
Everything required for an event to exist. Nothing optional
2. Tickets
Tiers, pricing, capacity, sale windows
Only relevant once the event is real. Skippable for free events
3. Add-ons
Extras, upsells, supplementary options
Genuinely optional. Deliberately last so it never blocks
4. Publish
Review, visibility, confirm
A checkpoint, not a form
Four decisions
1. Order by commitment, not by database
The legacy form followed the data model. I reordered around how much a user has already invested.
Step 1 asks only for what makes an event an event. By the time someone reaches ticket pricing they've already named the thing, picked a date and uploaded an image — they're committed. Optional configuration sits at the end where abandoning it costs nothing.
Practically: an event can go live after step 1. Steps 2 and 3 are enhancements, not gates.
2. Save and resume as a designed state, not a fallback
Each step commits on save. A client can build the event details on Monday, add ticket tiers on Wednesday, and publish on Friday.
That meant designing for the in-between: draft events needed a visible home, a clear resume affordance, and an honest indication of what was still missing before publishing.
The event list showing a draft alongside a published event, plus the resume entry point.
3. Recurring events — the hard one
A meaningful share of UNATION clients run recurring programming: trivia every Tuesday, a monthly market, a weekly live set. Some already had recurring series created on desktop that had to remain editable in the app.
The interface problem is that recurrence is a small input with enormous consequences, and the standard mobile pattern — a modal stack of frequency, interval, end condition, exceptions — buries it.
I took the approach from Basecamp: express the rule in plain language, and let the user edit it in place rather than configure it abstractly. The user reads a sentence describing when the event repeats, and taps the parts they want to change. The complexity stays in the system, not on screen.
Editing an existing series needed one more thing: a clear, unavoidable choice between this occurrence and all occurrences. That ambiguity is where recurring-event UIs usually cause damage.
4. Closing the loop with ticket sales
UNATION already processed ticket sales through its own system, but sellers had no mobile view of them. Creating an event on a phone and then needing a laptop to see whether anyone bought a ticket would have left the job half done.
So I extended the scope: a list of the user's created events, and per-event sales visible directly in the app.
Built on the design system
This flow landed immediately after a full UI refresh of the UNATION app, which I also designed. That refresh is what made a project of this size deliverable by one designer and one developer.
Foundations overview from the Mobile 5.0.0 file: type scale, colour, spacing, core components.
Every screen in the Create Event flow is assembled from library components — inputs, selectors, sheets, buttons, list rows, step headers. Where the flow needed something new (the step progress header, the recurrence rule row, the ticket tier row) I built it as a proper component with defined states rather than a one-off, so it could be reused and so the developer had a single source of truth.
The practical result: no new visual language, no unresolved styling questions in handoff, and a flow that felt native to the app on day one.
Component work specific to this flow
Step header with progress state
Recurrence rule row default / editing / applied
Ticket tier row empty / configured / sold-out
Draft badge and resume row
Publish review summary block
The outcome
The flow shipped on iOS and Android. UNATION clients can now create, edit and publish events — including recurring series — from their phone, and see ticket sales without opening a laptop.
What I'd do differently
Shipping without research was the right call for the timeline, not the right call for the design. The four-step split is a reasoned bet borrowed from a well-tested product — it isn't validated on UNATION's actual users.
The first thing I'd do with a second pass is instrument the flow: drop-off by step, save-and-resume rate, how many events are published straight after step 1. That data would tell us whether four steps is right, or whether step 1 is still carrying too much.
The event list showing a draft alongside a published event, plus the resume entry point.
Building a design system as the lead designer on a relationship management platform for desktop and mobile browser.
case study