Card 5 of 5 · 2026
Concept
Sunday League Hub
A Telegram Mini App concept for my Sunday league football team: attendance, fines, payments, community duties and match day in one place. Research findings confirmed by the team.
By Simeon Fesshaye · UX/UI design
- UX research
- Interaction design
- Design systems
- Prototyping

- Role
- Research, UX/UI design and prototyping
- Type
- Concept for my own football team
- Research
- Role mapping, confirmed by the team; heuristic review
- Design
- Figma design system, iPhone and Android, 200 screens
Overview
I researched the operational challenges of running my Sunday league football team and used the findings to design Sunday League Hub, a Telegram Mini App concept.
The team runs on goodwill and a Telegram group. Attendance, fines, payments and community duties for the Woreda (the local council that controls our pitch) are each handled by a different person, with records spread across chats, notes and memory.
Who I involved
Team organiser
- Organises matches and confirms the squad
- Communicates team decisions
- Coordinates activities
Attendance officer
- Tracks attendance and late cancellations
- Keeps participation records
Finance tracker
- Records fines, contributions and payments
- Tracks outstanding balances
Discipline officer
- Reviews rule violations and proposed fines
- Decides disputes and exceptions
4 regular players
- Confirm attendance and know their responsibilities
- See their own financial records
- Need timely updates
How I researched
I started from what I know as a member of the squad and mapped the needs, workflows and frustrations of each of these roles.
One member's view isn't enough to design on, so I shared the findings with the team. They confirmed the findings match how the team actually works, and that confirmation is what the design rests on.
Key insights
Attendance management
- Organisers need confirmed, declined and unanswered players at a glance
- Changes need timestamps
- The 24-hour cancellation rule must be built in
Financial transparency
- Every obligation and payment linked to the right player
- Outstanding balances separate from payments awaiting verification
- Proposed fines are not approved debts
Accountability and fairness
- Decisions must be traceable
- Officer responsibilities clearly defined
- One consistent process for fines, exceptions and disputes
Community participation
- Activities can be needed to keep pitch access
- Mandatory duties, deadlines and assignments must be clear
- Attendance, completion and evidence are recorded
Match day
- Who said they're in isn't who turns up
- Teams are picked at the pitch and numbered by captain
- Waiting players ref, keep score and take the photos
Today's journey: a fine
Sunday
- A player cancels late
- The attendance officer notes it at the pitch
Month end
- The list of fines is posted
- The player finds out weeks later
Dispute
- Proof is sent to the discipline officer by DM
- The decision is made from memory
Payment
- A screenshot is posted in the chat
- Someone matches it by hand, eventually
The problem to solve
“How might we make every Sunday commitment, fine, payment and community duty visible and settled, without turning teammates into debt collectors?”
From findings to design decisions
I turned the insights into product rules, so the screens follow from the research rather than being a collection of isolated ideas:
- Attendance is separate from discipline: a late cancellation is flagged for review, never fined automatically
- Proposed fines are separate from approved obligations
- Recording a payment doesn't mean it's verified; each payment shows its verification state
- Players can dispute a fine, and the resolution is recorded
- Role-based access: players see their own finances, officers manage records within their responsibilities
- Community activities are mandatory or optional, with deadlines, assignments, attendance and completion
- The home screen puts outstanding actions first: the next match, fines to answer, payments, community duties
- Important status changes keep an audit history, so records can be checked when questions come up
- It runs as a Telegram Mini App, because the team already lives in Telegram
- Teams are picked at the pitch after check-in, not in advance: no-shows and players who turn up without answering would break a list made the day before
- Match day follows the team's own rules: 10-minute matches, first to 2 goals or the leader at 10:00 stays on, a coin flip for a draw, and a number call to decide who sits out and who fills a short team
- Ref mode runs on the organiser's phone, which the waiting players hold: the score, the 05:00 keeper change, photos and late arrivals
First-version scope
Must
- Check-in with a deadline and timestamped changes
- Fines with review, exceptions and disputes
- Payment logging and verification
- Community activities and responsibilities
- Roles, permissions and audit history
Should
- Match day: check-in, teams picked at the pitch, live score and the number call
- Team of the week and photos for the group
- Reminders for players who haven't answered
Could
- Kit handover log
- Season stats
Won't (yet)
- Payments inside the app
- Automatic fines
- Skill ratings or auto-balanced teams
The design
Final screens from the Figma design, for a player, the fine officers and the organiser.










Match day
My first version made balanced teams the day before from everyone who said they were in. Checking it against how we actually play showed why that breaks: people say they're in and don't come, others turn up without answering, so the team picks teams at the pitch.
So match day starts with check-in on the organiser's phone. Teams are numbered and named after a captain, and with three or more a number is called to decide who sits out first. Matches are 10 minutes: first to 2 goals wins, otherwise the leader at 10:00 stays on, and a draw goes to a coin flip. The waiting players hold the phone: they keep score, call the keeper change at 05:00, take the photos, and call a number to pick who joins a short team. The line-up with the most wins is team of the week.
Match day screens
From check-in to team of the week, following one Sunday: 12 turn up, so there are two full teams and two players waiting.









Design system, motion and Android
I built it in Figma on a variable-based design system: colour, spacing on an 8px grid, radius and type tokens, and about 30 components with their states. Every screen exists for iPhone and for Android, where Telegram's own header and the gesture bar change, so 200 screens in all.
The screens are linked into a clickable prototype with named flows for each person, and Figma Motion brings in sheets, toasts that leave after a few seconds, and match moments like the coin flip.
On Android
The same app inside Telegram for Android: its own header, back arrow and gesture bar.



Evaluation scenarios
I structured a task-based evaluation around realistic team scenarios. Each one can be completed in the prototype:
- Confirm attendance for an upcoming Sunday match
- Change an answer and see whether it falls inside the 24-hour cancellation window
- Review an outstanding balance and how it was calculated
- Record a payment and check its verification status
- Review a proposed fine and submit a dispute
- Find a mandatory community activity, its deadline and assigned responsibilities
- Review the history of a record to see who changed its status
- Check in at the pitch, add someone who turned up without answering, and pick teams
- Run a match as the ref: keep score, settle a draw with the coin flip and call a number for who comes on
Design iterations
Fine alerts read as accusations
- v1: "You were fined 200 birr"
- v2: who proposed it, why, and a way to respond on the card
"Out" was too easy to tap
- v1: In and Out side by side
- v2: Out asks to confirm and explains late cancellation
A minus sign is easy to misread
- v1: "Balance: -400"
- v2: "You owe 400 birr" or "You're all settled"
Verifying meant leaving the app
- v1: amount only
- v2: proof, method and reference on one card
Before and after
Version 1 next to version 2 for the screens that changed most after reviewing the first version.






Heuristic review
I also reviewed version 2 against Nielsen's 10 heuristics myself. Fixed:
- Payments now show "waiting for Dawit to verify" until they're checked
- Check-in can be changed freely until the deadline, and every change is timestamped
- An exception can't be sent without proof, and a dispute can't be sent without an explanation
- Fine reasons come from a fixed list instead of free text
- Reminders now show the message and who gets it before they're sent
- Still open: accepted fines can't be undone, and officers can fine themselves
Interactive
Try the prototype
Work through the evaluation scenarios yourself. Switch between a player, the discipline officer and the organiser, flip between version 1 and 2, move the clock past the deadline, or run match day as the ref.
Open the prototypeWhat still needs testing
The next round of evaluation focuses on these questions and edge cases:
- Do players understand the attendance and cancellation rules?
- Is the financial information transparent enough?
- Does the dispute process feel fair?
- Are mandatory community activities easy to find and manage?
- Can the ref keep score and run the number call with the phone in one hand, between matches?
- Edge cases: duplicate payment records, unverified transactions, disputed fines, unauthorised edits, attendance changes after the deadline, no-shows, late arrivals and fewer than 10 at the pitch
How success would be measured
Measures for testing with the team, and targets for a pilot. None of these have been measured yet.
- Task completion, errors and time on task for each evaluation scenario
- Whether players can explain the cancellation, fine and dispute rules after using the app
- 80% of the squad answers before the deadline by week 4
- No fine disputes because someone didn't know
- 90% of payments verified within 48 hours
What I learned and what's next
This project reinforced the importance of designing around real operational workflows, especially when one product combines attendance, money, discipline and shared responsibilities.
I learned that transparency takes more than displaying information. The system has to explain why a record exists, who can change it, what its status means and what can be done next.
Match day taught me to design for how people actually behave rather than how the plan says they will: a tidy list of teams made the day before broke the moment someone didn't turn up.
Next, I'll run task-based usability testing with the team, record their actual feedback and use it to prioritise improvements. I'll keep refining role permissions, audit history, financial record integrity and community-event tracking as the product moves toward a build.
Next story · Draw the next card
Ahun