Hamza Trabelsi · Product DesignerIndependent case study · 2026
Everyday help, within reach.
Ask for help. Find it nearby.
An independent product design and UX writing study by Hamza Trabelsi, developed in English and Arabic from the start.
Arabic experience · أحمد في الطريقProduct design & UX writing · Hamza Trabelsi
01The premise
The design brief
A simple request for nearby help.
Many everyday tasks are too small or spontaneous for a traditional service marketplace.
Sometimes the right person is a nearby individual with the time and ability to help, rather than a service company.
Wegigo connects the person making the request with someone nearby who is available to take it.
“
The service should feel as direct as asking someone nearby for help.
DesignerHamza Trabelsi
ProjectIndependent concept
LanguagesEnglish + Arabic
My contributionProduct design · UX writing
02The core experience
The core flow
Describe the task. Find nearby help. Coordinate.
01
Request
Start with the task the user already has in mind.
02
Match
Communicate active progress without inventing certainty.
03
Coordinate
Bring the person, ETA and contact actions to the front.
03Starting with intent
Starting a request
Let people describe the task first.
A person who wants to move a bed already knows what they need. Asking them to choose between furniture, carrying and home services adds work before the request has even started.
“Describe the task…” is the primary interaction. Categories remain available when someone wants a shortcut or needs help deciding what to write.
Primary promptDescribe the task…Direct · open-ended · action-oriented
04Marketplace model
Requester and helper
One account supports both roles.
A person can request help today and offer it another day. The product changes mode without assigning a permanent identity.
01Need help?
Describe the job and find someone available nearby.
02Offer help
Use your time and ability to help someone else.
05Designing the search state
Communicating activity
Show what the system knows while it searches.
Before anyone accepts, the product can confirm that the request is active and that nearby helpers are being checked. It cannot give an honest arrival time yet.
KnownThe request exists.
KnownThe search is active.
KnownNearby help is being checked.
UnknownWho will accept and when.
06Information and certainty
Matching and coordination
Change the information when the state changes.
Matching
“Can someone help me?”
The interface answersFinding help nearby
→Helper accepts
Coordinating
“Who is coming, and when?”
The interface answersAhmad · 8 min
07After acceptance
The focus moves from task to person
Ahmad is on the way.
Once a helper accepts, identity, rating, route and ETA become useful. Message and Call become immediate actions.
PrimaryHelper + arrival time
ImmediateMessage + Call
SupportingTask details + price
SecondaryCancel request
8 min
08UX writing
UX writing
The copy follows the system state.
I wrote the interface while designing the flows, so labels, status messages and warnings correspond to what the product can actually confirm.
01
Be precise
If the system is searching, say it is searching.
Finding help nearby02
Do not overpromise
Only introduce an ETA after someone accepts.
Ahmad · 8 min03
Name consequences
Meaningful actions should be unmistakable.
Cancel Request04
Respect attention
Let visual context carry information when it can.
Read only what matters
09Arabic UX writing
الكتابة للتجربة العربية
المعنى أولاً، لا الترجمة الحرفية.
Writing in Arabic
I wrote Arabic for its own sentence structure and reading rhythm.
The Arabic interface keeps the same product meaning as the English version, but the wording and information order are written to read naturally in Arabic.
Active searchFinding help nearbyالبحث عن مساعدة بالقرب منك
Describes progress without promising an outcome.
Accepted stateAhmad is on the wayأحمد في الطريق
Moves from an abstract search to a specific person.
Consequential actionCancel Requestإلغاء الطلب
Uses a direct label when the consequence matters.
10Bilingual experience
English + Arabic
Each language uses its own reading direction.
The two versions share the same tasks and hierarchy. Their layouts adapt where alignment, component order or sentence structure needs to change.
English · LTRالعربية · من اليمين إلى اليسار
11Designing for RTL
RTL design
Layout direction follows reading direction.
LTR →← RTL
01Text alignment
Copy follows the natural reading edge.
02Component order
Icons and controls maintain the correct relationship.
03Navigation
Direction changes with the user’s mental model.
04Sentence structure
Meaning wins over literal translation.
12Visual system
Visual system
Every element has a communication job.
#6C5CE7#EFECFF#17181D#FFFFFFPrimary typeAa
Clear at every scale.
Confident headings. Calm supporting text.
أب
واضح في كل حجم
Space is part of the interface.
Proximity, alignment and scale create relationships without another container.
13Across the experience
The same rules apply across the product.
The visual language, writing and directional behavior remain consistent from launch through coordination.
A case study by Hamza Trabelsi
One service, designed in two languages.
The final system supports requesting, matching and coordination in English and Arabic, with copy and layout designed for each language.
