Hi, I’m Ibrahim. A product designer at Apple, on Apple Pay.
I make complicated systems feel simple: the parts nobody notices until they break. Most of my work is the quiet side of payments, the tools that keep checkout working.
Austin, Texas
Say hello.
Happy to talk about payments, internal tools and design systems.
An internal tool that warns Apple’s support team before a shop’s Apple Pay breaks: what is about to expire, who can fix it, and exactly what is wrong.
01Scenario
Merchant Health · Atlas TicketsTuesday
Apple Pay payments failed
02Context
03User journey
Its end date goes in nobody’s calendar.
Reminders go unread, the old key is turned off early, the website check fails quietly.
Every customer at checkout sees it fail.
A complaint arrives with no context.
04Research evidence
05Design challenge
Make sure every deadline has a person watching it, and make the risky step impossible to do too early.
06High-fidelity designs
1/5 · Nobody sees the deadline
2/5 · Warnings reach nobody
3/5 · Old key turned off too early
Key insightThe only proof a new key works is one real payment made with it.
4/5 · Website check fails silently
5/5 · Support starts from zero
07Usability testing
Time per task
What they said Paraphrased
“I can see what’s about to expire without checking multiple places. It makes prioritising much easier.”Support specialist
“Knowing the new certificate is working before I revoke the old one gives me much more confidence.”Senior support advisor
“Instead of just seeing a failure, I can understand what went wrong.”Technical escalation lead
“Having the shop’s history and certificate status together would save a lot of back and forth.”Support specialist
From feedback to change
Read an expiring key as one that had already expired.
Expiring and expired used colours that were too close.
Sharper severity colours and expiry labels, so urgent rows stand out.
See fix 1 →Scrolled past the alert looking for a name to call.
Who to contact sat below the fold, apart from the risk it belonged to.
The main contact and who is next in line moved up, right next to the risk alert.
See fix 2 →Paused at the locked Revoke button and asked whether it was broken.
The lock showed, but not the reason. Disabled with no explanation reads as an error.
Clearer key status labels, and a line beside Revoke that says it opens after one real payment.
See fix 3 →Found the failed step quickly, then asked what to tell the shop.
The first version named the failed step, but not what to do about it.
Each failure now gives its reason and the fix to send, in plain words.
See fix 4 →08Design trade-off
09Before and after
Tuesday, 08:00. Nothing happens.
10Success metrics
11Learnings
The fix was mostly visibility and ownership, not new technology.
A warning gets dismissed. A button that waits for proof cannot be misused.
Using Apple’s own patterns let support read the tool like any other Apple app.
Every session was with support. The locked Revoke lives in the shop’s account, and next time I would test it with shop developers early.
A five-a-side football app: find an open match near you by day, join in one tap, host your own and fill the empty spots.
View on the App Store01Problem
Five-a-side matches are organised in WhatsApp groups. Ours had about 20 people, and confirming the 14 who would actually play took almost two days.
Messages got lost, people pulled out at the last minute, and some never saw the chat at all.
Thursday Five-a-sideAbout 20 members
Small artificial-turf pitches, rented by the hour, usually six or seven a side. Friends, colleagues and neighbours book the same slot every week.
Every team has a group. The booking, the squad, who is coming and who owes what are all messages in it.
Fourteen people have to turn up at the same hour. When one can’t, the only tool is a message: “one short”.
02Current user journey
And becomes the organiser, the treasurer and the one who chases everyone.
The only fix is “one short” in every group you’re in.
Who paid, who owes, and how much each, worked out in messages.
A team plays with thirteen, or the match is called off.
03Concept
It started with a simple problem. One Thursday evening we were trying to set up a match, and again we were one short. Everyone was messaging everyone; some pulled out at the last minute, some never saw the messages. I thought: why does something this simple need so much talking?
People weren’t tired of football. They were tired of the coordination around it. Players just wanted to find a match and join. Organisers were stuck writing to people, confirming who was in and filling last-minute gaps. Maça Katıl brings both sides into one experience.
Finding, joining and organising a match should take as few steps as possible.
04Design principles
A match is decided in seconds, on a phone, often while walking. So every screen follows the same few rules.
The pitch seen from above, with when as the biggest thing on it, so a match reads at a glance.
People decide by the day first. “Tomorrow” or “Saturday” leads; the time sits below it.
Evening matches are lit gold, night matches deep green. No other decorative colour.
Only the create button, the joined state and live moments are lime, so the eye goes straight to them.
Design trade-off: show ratings and levels, or keep it plain?
05User feedback
Feedback and the design changes it led to Representative of the closed test
“There’s too much on the home page. I just want to see matches I can play today or tomorrow.”
A simpler home page: popular matches easier to see, upcoming match cards reorganised, repeated filters removed.
“I joined a match, but I can’t tell from the card. I have to open it again.”
Joined matches get their own green state, so you can tell them apart right in the list.
“Finding matches on the map is nice, but switching between list and map should be easier.”
The map moved to a central, easy-to-reach spot on the main screen, and the day filters now match in list and map.
“There’s too much on the match screen. I want the time, how many are missing and the price.”
The date and time are bigger, the repeated location is gone, and the empty spots are easier to see.
Key insightPeople didn’t want a new social platform. They wanted to organise something they already loved, with less effort.
06Low-fidelity wireframes
Low-fidelity wireframes for the four core tasks, before any visual design: find, join, host and plan. They settled the layout and the information hierarchy, nothing else.
FindMatches grouped by day.
JoinSquad, price, one button.
HostPitch, hour, fee. Done.
PlanOne pitch everyone can draw on.
Iteration: the match screen
In the earlier version the time was the headline and the organiser had a star rating. Now the day leads, and nobody is rated.
07High-fidelity designs
1/4 · Open matches can’t be found
2/4 · Filling a spot means chasing people
3/4 · Splitting the fee by hand
4/4 · Organising sits on one person
08Before and after
Thursday, 21:00. Everyone is there.
09Outcomes
10Learnings
The interface is neutral. Lime only ever means “do this” or “live”, so the eye goes straight to it.
No ratings, levels or counts for their own sake. Every line on a match is there because people choose by it.
No sample matches or made-up numbers in the app. A quiet city shows an empty state, not a fake one.
Most of the design was shaped around players. The organiser’s side, hosting and filling a match, is where I would put people in front of it next.
A Mac app that turns the MacBook notch into a Dynamic Island: music, meetings, files and a toolbox, right where you’re already looking.
Visit tilora.io01Background
At Apple my days were full of meetings, and I kept joining them late. The reminder slid past while I was focused, and the link was buried.
My manager mentioned a Mac app that put meetings in the notch. The idea clicked: the notch is right where you look. But I wanted more from it, so I started on my own.
02Concept
Make the notch the place small things happen, one need at a time.
03Design principles
Would it feel at home next to the Dynamic Island?
Never a separate window.
It shows up, then steps aside.
Black and grey; the content brings colour.
04Low-fidelity wireframes
Before any visual design, each need got a low-fidelity wireframe. They decided what the notch shows, where, and how much room it takes.
MeetingsThe closed notch, widened for a meeting.Tap a number to read it.
JoinAt start time, Join is right there.Tap a number to read it.
ReplyA message, answered from the notch.Tap a number to read it.
TranslateHighlight words, read them in your language.Tap a number to read it.
BatteriesSeveral devices, one card.Tap a number to read it.
ShelfDrag a file up, and the notch opens.Tap a number to read it.
HomeEvery need, as a card.Tap a number to read it.
05Need by need
1/7 · Meetings
2/7 · Joining
3/7 · Messages
4/7 · Translate
5/7 · Batteries
6/7 · Files
7/7 · Everything
06Development
I designed Tilora and built it with Claude Code as my engineering partner. I decided how each screen looks and behaves; Claude Code wrote the Swift with me, one change at a time.
Every change was a short loop: describe it, review the code and try it on my Mac, then adjust. The same loop built the website.
07Outcomes
08Learnings
Missing meetings made every trade-off easier to judge.
Each feature began as one real need, not a list.
Watch people set it up and see where they stall.
