Fictional events, hosts, dates and prices. No research or usability testing has been conducted. Search, filters and saving below are visual examples, not working controls.
01 / The proposed experience
Discover → Details → Saved
Follow the same event across three screens. Preview links move around this portfolio only.
1. DiscoverCompare the essentials
circleUI PREVIEW
Bengaluru · central areas Sample discovery area
Your neighbourhood. Your kind of plans.
⌕ Search events or interests Visual example
All eventsOutdoorsCreative
Sample filters · not interactive
ART + OUTDOORSA little fresh air. A little inspiration.08 NOV / SUN
The same name, date, area and price preserve continuity. Explicit wording separates remembering an event from joining it.
02 / Short case study
The reasoning, not just the screens.
Problem hypothesis
Someone considering a local event may need its time, cost and area before deciding whether to attend. Circle explores making those details easy to find. This is a design assumption, not a research finding.
Audience and scope
Karanam chose “anyone nearby” and local events. The audience is intentionally broad at this early stage. A later version should identify a narrower use case through conversations with potential users. The draft contains discovery, details and saved events only, not a full social network.
Clear information order
Event titles lead, followed by date, area and price. Details add duration and what to bring. This order is intended to help comparison, but has not been validated.
Privacy with a practical limit
Discovery uses approximate public areas, not attendees’ exact locations. The trade-off is less travel certainty. A real product needs a reliable public meeting point without exposing private addresses.
Consistent visual language
Dark headings, neutral surfaces and a purple accent create hierarchy. Text labels accompany navigation and status. Colour is not the only signal, but contrast and assistive-technology behaviour still need testing.
Small, honest scope
Saving is a lighter action than booking. This version shows only an example saved state and never implies that attendance is confirmed.
What changed from the first draft
Added a more visible “meeting point not confirmed” notice, instead of relying only on location guidance.
Clarified that search, filters and the saved state are visual examples.
Added screen-by-screen reasons, trade-offs and an interview script.
Kept the original three-screen flow and the same main fictional event.
What is not done
No interviews, competitor study, user testing, accessibility audit or measured results. No Figma or Canva file, working search, actual saving, booking, moderation, host verification or location service. This presentation is a static HTML mockup, not a shipped app.
Next validation plan
Ask potential users what they need to know before attending a nearby event. Do not present assumptions as answers.
With a working prototype, ask people to find a free event, explain when and where it happens, and save it. Observe confusion without guiding them.
Check whether they understand that a save is not a booking and that the meeting point is unconfirmed.
Test large text, screen-reader order, contrast and touch targets. Add empty, cancelled, past-event and unavailable-location states.
Only record actual observations after these activities happen. There are no success metrics to report yet.
03 / Say it simply
Your interview walkthrough.
Use this as a guide, not a claim of skills you have not practised. Point to the relevant screen as you speak.
“Circle is my assisted practice concept for finding local events. I chose the topic and the audience: anyone nearby. Ira helped create the layouts, styling and case-study draft.
The idea is to make an event’s time, cost and area easy to see. Discover lets people compare events. Details adds duration, what to bring and a meeting-point warning. Saved shows how they could return to an event later. Saving is not booking.
I used approximate areas rather than showing people’s exact locations. The trade-off is that people still need a confirmed public meeting point before travelling.
This is a static concept, not a working app. I have not tested it with users yet. My next step would be to check whether people understand the event details and the difference between saving and joining. I am a beginner learning the design basics.”
If they ask…
“What did you personally do?”
“I chose a social-app concept for anyone nearby and selected local events as the focus. Ira created the screen layouts, visual styling, sample content and draft explanation. I’m using the concept to learn.” Do not claim independent layout or tool work.
“Why only three screens?”
“To keep the practice project focused on one path: find an event, understand it, and keep it for later. Payments, chat and creating events are outside this draft.”
“How do you know the design works?”
“I don’t know yet. These are assumptions. I would test whether people can identify the time, cost and meeting-point limitation, and whether saving feels different from booking.”
“Do you know Figma or Canva?”
“Not yet. I’m starting from the basics on my phone. This concept was created with Ira’s help, not built by me in Figma or Canva.”
“What would you improve next?”
“First I would validate the audience and event information. Then I would improve the meeting-point flow, add cancelled and empty states, and test readability and accessibility.”
Three words to remember
Discover: find something. Details: understand it. Saved: return later.
UI means the visible interface. UX means the experience of completing a task. A hypothesis is an idea still needing evidence.