Event Management Platform

Suki

A full-stack event platform shaped from role-based requirements, interface design, implementation, and functional testing.

View Behance project View Figma prototype

Suki

At a glance

Role: Lead UI designer, front-end contributor
Team: 5 students
Timeline: 13 weeks, 6 iterations
Platform: Full-stack web application

Problem

Student event information, participation, promotion, and administration needed one shared system instead of disconnected channels.

My contribution

I designed most of the interface, illustrated the use-case model, built and refined front-end layouts, then designed and ran selected functional tests.

Recorded result

The team executed 44 functional cases across 12 features, found 7 defects, and closed all 7 in the recorded bug report.

01 · Context

Designing the interface meant understanding the whole system.

Suki was built for students who discover, join, create, promote, and manage events. Because the course covered an end-to-end software process, the interface could not be treated as a separate visual layer. Every screen had to respect actors, permissions, data, and system states.

Product challenge

One event changes meaning across four roles.

A guest needs enough context to decide whether an event matters. A participant joins or buys a ticket. An organizer creates and manages it. An administrator decides whether it can become public. The product had to keep that shared object understandable while actions changed by role and status.

My scope

From specification to interface and verification.

My recorded work included the use-case diagram, most Figma screens, the UI prototype document, front-end layout and CSS across guest, account, event, and admin areas, plus test design and execution for login, event creation, event management, cancellation, and promotion.

Inception01
Frame the product
A vision document and development plan defined the users, needs, constraints, team, and 13-week delivery plan.
Output: Vision and project plan
Requirements02
Model system behavior
The team translated product features into actors, relationships, and 21 use-case specifications.
Output: Use-case model
Architecture03
Connect interface and data
A browser-based client, Express routes, controllers, models, and MongoDB established how actions would travel through the system.
Output: Architecture document
Interface04
Design role-based flows
The UI prototype separated guest, participant, organizer, and administrator work while keeping the product visually coherent.
Output: Figma prototype
Construction05
Build and reconcile
Front-end screens were adapted to real data, API constraints, and implementation feedback instead of copied from Figma unchanged.
Output: Working web app
Verification06
Test system behavior
Functional scenarios compared expected and actual results, then converted failures into tracked defects.
Output: 44 test cases and report

02 · Requirements

The role model became the first design system.

Before deciding layout or color, I needed to know who could see an action, when it became available, and what happened after it was submitted. The 21 use cases gave the team a shared language for those decisions.

4
Product roles: 21
Specified use cases: 2
Event models: 18+
Organizer gate

How selected Suki requirements became interface behavior
Requirement	Interface consequence	System state
Participant and ticketed events use different commitment models.	Show Join for community events and Buy tickets for ticketed events.	Participation or ticket inventory is updated separately.
Organizer features are available only to eligible users aged 18 or above.	Keep creation and management actions outside the participant-only path.	The account role controls access to organizer routes.
New events require administrator approval before public release.	Explain pending, approved, and rejected states to the organizer.	Approval changes visibility and should trigger a notification.
Participation and ticket counts cannot exceed remaining capacity.	Display availability and validate requested quantity before confirmation.	The server must reject invalid or negative quantities.

Artifact placeholder · Use-case map

Guest · Discover

Participant · Attend

Organizer · Run

Admin · Authorize

Add the annotated use-case diagram here. The web version should highlight role boundaries and the three flows discussed below instead of reproducing every label at document scale.

03 · Product thinking

I organized 21 use cases around three stories reviewers can follow.

The complete system is broad, but the portfolio story focuses on the moments where role, event type, approval, and data most directly affect the experience.

Flow 01

Discover and attend

A guest searches and evaluates an event. After authentication, a participant either joins the event or purchases tickets, then receives a clear participation state and the option to cancel.

Flow 02

Create and publish

An organizer chooses the event model, enters the relevant capacity or ticket information, submits it, and waits for administrator review before it becomes public.

Flow 03

Manage an active event

An organizer edits event details, tracks participants or ticket orders, promotes the event, and handles cancellation without losing sight of its public status.

Artifact placeholder · Create and authorize flow

Draft
Validate
Pending review
Decision
Publish / revise

Use a compact flow diagram here: Organizer draft, validation, admin review, approved or rejected, public event, notification. Each state should include the interface owner and the backend response.

04 · Design

The visual language supported a dense product without making it feel administrative.

Suki combined indigo and coral with glass-like surfaces, abstract forms, and a flatter information layer. The goal was to keep student events energetic while preserving a reliable hierarchy for forms, statuses, and management views.

Evidence

The same event appears as marketing content, a commitment, an organizer workspace, and an approval item depending on the viewer.

Insight

Consistency could not mean showing identical cards and actions everywhere. It had to mean preserving identity while changing the available decision.

Design response

Use shared event information and status patterns, then adapt actions and supporting data by role instead of designing four unrelated products.

Artifact placeholder · Guest to participant

Replace this frame with an annotated WebP, video, or SVG artifact.

Show the landing, search, event detail, and join or ticket path. Annotate what changes after authentication.

Artifact placeholder · Organizer workspace

Replace this frame with an annotated WebP, video, or SVG artifact.

Show creation and management screens with event state, capacity, participant data, and the actions an organizer needs most often.

05 · Collaboration

Implementation exposed decisions that static screens could hide.

The interface was connected to a React and Vite client, Express routes and controllers, Mongoose models, and MongoDB. That made error handling, validation, permissions, and asynchronous status changes part of the design work.

01
A user commits an action
Join, buy, create, approve, or cancel begins in a role-specific interface with required input and confirmation.
02
The client sends intent
The front end validates what it can, calls the matching Express route, and keeps a visible loading or pending state.
03
The server applies rules
Controllers and models check permission, capacity, data validity, and the current event state before updating MongoDB.
04
The interface closes the loop
Success, rejection, and failure need distinct feedback. Testing later showed that missing notifications broke this loop even when the database action completed.

A successful database update is not a successful experience until the person knows what happened.

06 · Verification

Testing connected documented intent to actual system behavior.

The team recorded expected and actual results for 44 functional scenarios across 12 features. The report is useful precisely because it does not claim the product was flawless: 7 cases failed, each became a defect, and all 7 were later marked closed.

12
Features tested: 44
Functional cases: 37
Passed in recorded run: 7
Defects found and closed

Selected Suki defects and their product implications
Observed failure	Severity	Why it mattered	Recorded status
Organizers were not notified after an admin approved or rejected an event.	Moderate	The organizer could not tell whether the event was public or needed revision.	Closed
A correct username with a wrong password produced no visible error.	High	The system blocked progress without explaining how to recover.	Closed
Creation failed when an optional rules field was left empty.	Moderate	The implementation contradicted the documented form requirement.	Closed
The system accepted a quantity above availability and a negative quantity.	Low in report	Invalid inputs could corrupt the remaining ticket count, so I would rank this higher in a production system.	Closed

07 · Learning

The strongest lesson was traceability, not visual polish.

Suki taught me to follow a decision from user need, to requirement, to interface state, to server behavior, and finally to a test result. That chain is what made design conversations concrete across a mixed front-end and back-end team.

What worked

Role-based thinking kept a broad product coherent.

The use-case model gave the team a shared view of permissions and helped me avoid treating guest, participant, organizer, and admin pages as isolated screens.

What I would change

Test the risky flows earlier with people.

Functional testing caught broken behavior near the end. I would add paper tests and moderated task sessions for event creation, approval, ticket quantity, and cancellation before construction.

Next measure

Separate system correctness from experience quality.

A future round should track task completion, error recovery, time on task, and comprehension of event states alongside API and data integrity tests.

Designing the interface meant understanding the whole system.

One event changes meaning across four roles.

From specification to interface and verification.

Frame the product

Model system behavior

Connect interface and data

Design role-based flows

Build and reconcile

Test system behavior