Hey there, I’m Ibra.
I craft products, interactions & stories.
I’m a Senior Product Designer at Apple. I turn complex challenges into intuitive, thoughtful experiences that make technology feel more human.
Austin, Texas
Say hello.
Message sentThank you, I’ll be in touch.
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.
01Background
Shops kept writing to Apple’s Developer Support with the same message: Apple Pay stopped working, and nobody had changed anything.
Often the cause was a digital key, made two years earlier, that had quietly expired. Support found out only after shoppers couldn’t pay, and had to piece the story together from scratch.
An internal Apple tool under NDA. Shops, names, screens and the numbers in them are illustrative. The usability testing results are real.
02Context
03User journey
Its end date goes in nobody’s calendar.
Reminders go unread, the old key is revoked too early, the website check fails quietly.
Every customer at checkout sees it fail.
A complaint arrives with no context.
04Research evidence
“We are having trouble trying to renew our Apple Pay Merchant Identity Certificate.”
“successful only when both the previous Merchant Identity and Payment Processing certificates are revoked”
“both key-pairs (private keys) remain active on their side”
“No popup errors are shown, no console developer error”
05Design challenge
Make sure every deadline has a person watching it, and make the risky step impossible to do too early.
06Design trade-off
One person first, more people only if nobody answers. Emailing everyone made each person assume someone else would deal with it.
07High-fidelity designs
1/5 · Nobody sees the deadline
Tried firstA red badge on each shop’s page. Nobody opens every shop’s page to look for a badge.
2/5 · Warnings reach nobody
3/5 · Old key revoked too early
Tried firstA warning in the support tool. The mistake happens in the shop’s account, not ours.
Key insightThe only proof a new key works is one real payment made with it.
4/5 · Website check fails silently
Tried firstShow Apple’s raw result. “Verification failed” is all shops see today.
5/5 · Support starts from zero
Tried firstA form asking the shop for details. It asks the person who knows the least.
08Usability 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 the shop revokes 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 step 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 why it is locked.
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 →09Success metrics
10Learnings
The fix was mostly visibility and ownership, not new technology.
Testers read a locked Revoke as broken until a line beside it said why.
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.
Apple’s internal platform for test cards: engineers find and request them, Ops tracks them, admins set access by region, and leads see how it all runs.
01Background
Engineers who build Apple Pay and Wallet test with real bank cards: one network, one country, one feature at a time. The cards are a small, shared supply.
Operations teams look after them. Requests came by email and Slack, the record of who had what lived in a shared spreadsheet that was never quite right, and reports were counted by hand.
Avalon is the internal platform that brought it all into one place: tracking, assigning, access by region, reporting and changes to many cards at once. I designed it, in a team of 7.
An internal Apple tool under NDA. Banks, cards, people, screens and the numbers in them are illustrative.
Who uses it
Find, request and hold the test cards their work needs.
Track every card, hand it out, take it back, and change many at once.
Decide who can use what, person by person and region by region.
See how cards are used, and where requests wait.
02The old way
Ask Ops for the spreadsheet, then search it, with each country written several ways.
An email that leaves out the project, the dates and the pickup.
The sheet names someone who moved teams, so chat goes looking.
At a desk, with nothing written down. At month end, someone counts by hand.
03Design challenge
Three goals, for both sides.
04Information architecture
Engineers and Ops used to share a spreadsheet and an inbox, and leads got a count by hand. Now everyone shares the card itself: one status, changed by what each of them does.
05Design trade-off
Both. The engineer is who has the card; the project is why, and when it goes back to the shared inventory.
06Design system
A top bar, a sidebar, large titles, inset lists and sheets, so Avalon reads like the rest of Apple’s web tools. Every status has one name and one colour, wherever it appears.
Colour
07High-fidelity designs
1/8 · Nobody knows what exists
2/8 · Requests miss what Ops needs
3/8 · Cards follow people, not projects
4/8 · Requests land in an inbox
5/8 · The spreadsheet is always behind
Key insightThe record went wrong at the handover, so the handover is where Avalon writes it.
6/8 · No record of who had what
7/8 · Access by asking around
8/8 · Nobody sees the whole picture
08Success criteria
09Learnings
The record broke at the desk, so recording the card ID at the desk is what keeps it right.
Engineers, Ops, admins and leads read the same status, so there is nothing to reconcile between them.
Watch Ops count every card, and see which part of the history they lean on.
A web portal where Apple Pay merchants see their conversion next to a benchmark, find where shoppers drop off, and open cases that land in Salesforce.
01Background
Apple Pay merchants could see what their payment provider charged and declined. They couldn’t see how many shoppers opened the Apple Pay sheet and gave up, or whether their numbers were any good.
When sales fell, they emailed the Apple Pay team. The team worked each case in Salesforce, which merchants never saw, so the next email was often “any update?”.
The Merchant Portal gives merchants their own Apple Pay numbers, next to a fair benchmark, and connects every case to Salesforce, where Apple’s merchant support and operations teams work them. I designed it, in a team of 12: a product manager, engineers, QA and business analysts.
An Apple tool under NDA. Shops, people, rates and case numbers are illustrative.
Three numbers that matter
Checkouts that end in a successful payment: the blue check on the sheet.
Shoppers who confirm with Face ID, Touch ID or their passcode.
Confirmed payments that the payment provider approves.
02The old way
Each store’s payments report shows fewer Apple Pay payments, not why.
Apple can’t share other merchants’ numbers, so there’s nothing to compare with.
Nobody can see the shoppers who opened the sheet and left.
Screenshots and exports by email, then “any update?” for weeks.
03Design challenge
Three goals for the portal.
04Information architecture
Merchants used to have a payments report and an inbox, and the case that fixed things lived in Salesforce, out of sight. Now the portal sits between them: numbers in, cases out, status back.
05Design trade-off
As a band: above average, average, 0–10% below, or more than 10% below. Merchants see where they stand without other merchants’ numbers ever showing.
06High-fidelity designs
1/7 · No number for Apple Pay conversion
2/7 · Nothing to compare with
3/7 · Drop-offs nobody sees
Key insightA number only helps if it says what to do next, so every drop links to a fix or a case.
4/7 · A case starts with screenshots
5/7 · No one knows where a fix stands
6/7 · Help is a list of links
7/7 · Every store on its own
07Success criteria
08Learnings
A range tells merchants where they stand without exposing anyone else.
Opening a case from the drop means the data travels with it.
Shops without a payments team may need “What to try” before the numbers.
A pickup football app for Türkiye: 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
Our WhatsApp group 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 FootballAbout 20 members
Halı saha: small artificial pitches rented by the hour, for five- and seven-a-side games. The same group books the same slot every week.
02User journey
And ends up holding the squad and the plan.
The organiser posts in every group they’re in.
How much each owes, worked out in messages.
The match starts with thirteen, or is called off.
03Concept
Finding, joining and organising a match should take as few steps as possible.
It started one Thursday evening. We were setting up a match, and again we were one short. 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.
04User feedback
Feedback and the design changes it led to
“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 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 pitch now leads, with the day and time just above it. The repeated location is gone, and the open 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.
05Low-fidelity wireframes
One wireframe per step: find, join, joined, share, host and plan. They settled the layout and the order of information before any visual design.
FindMatches grouped by day.
JoinSquad, price, one button.
JoinedThe moment you’re in.
ShareBack to the group chat, as one link.
HostPitch, hour, fee. Done.
PlanOne pitch everyone can draw on.
Iteration: the match screen
Earlier, a large kick-off time and the organiser’s star rating led the screen. Now the pitch leads, and the rating is gone.
06Visual identity
The logo changed three times before launch, from a runner to a lowercase mk.
First appA runner, mid-stride.
July 2026On green, with the ball.
12 Oct 2026In lime, the runner shaped into an mk.
TodayA lowercase mk. The runner’s head is the dot.Every colour has one job
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 · The plan lives in one person’s head
What’s next: tournaments
Drawn, not built yet. An organiser publishes a tournament; teams or single players enter, pick a squad and follow the fixtures.
08Outcomes
09Learnings
The live app never fills a quiet city with sample matches; it says plainly that nothing is on yet.
The idea, the test and the feedback all came from the people we play with every week.
Now that it’s live, feedback should come from inside the app, not only our group chat.
A Mac app that turns the MacBook notch into a Dynamic Island: meetings, messages, batteries and files, right where you’re already looking.
Visit tilora.io01Background
At Apple my days were full of meetings, and I kept joining them late.
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 where small things happen.
03Low-fidelity wireframes
Before any visual design, I sketched each need to settle the layout and how much room the notch takes.
MeetingsThe closed notch, widened for a meeting.
JoiningAt start time, Join is right there.
MessagesA message, answered from the notch.
TranslationRead it without leaving the page.
BatteriesSeveral devices, one card.
FilesThe notch, opened as a place to drop.
HomeThe notch, grown into a panel of cards.
04Visual identity
The first icon was a dark screen with a glowing notch. Before redrawing it, I put eight directions side by side, each at full size and at Dock size, on light and on dark. The new mark joins two of them: the notch as the bar of a T, and the dot, now a drop of orange.
Directions
BeforeThe first icon, for comparison.
A · The notch as a TThe top edge and the notch make a T, on a dark body.
B · The same T, lightThe same idea on a light body.
C · A lit notchOne coloured notch on a black body.
D · Screen and notchA light screen with a black notch.
E · The notch, openedThe open notch’s outline on one colour.
F · A bar and a dotThe notch, and what comes from it.
G · Bar and dot, lightThe same idea the other way round.The new mark
App iconThe bar of the notch, and a drop of orange.
MarkIn ink, on light.
Two coloursThe drop in orange.
On darkIn cream, with the orange drop.Colour
05High-fidelity designs
1/7 · Meetings
2/7 · Joining
3/7 · Messages
4/7 · Translation
5/7 · Batteries
6/7 · Files
7/7 · Home
06User feedback
“The design feels like something Apple should have built into macOS.”
“Such a simple idea, but it makes a huge difference in my daily workflow.”
“The notch feature is surprisingly useful. Nice attention to detail.”
“Finally, something that helps me focus instead of adding more clutter.”
“I was skeptical at first, but now I use it pretty much every morning.”
“One of those apps you don’t realize you need until you start using it.”
From emails customers sent me.
07Development
I designed it, and Claude Code was my engineering partner: I decided how each screen looks and behaves, and it wrote the Swift with me.
Each change was a short loop: describe it, review the code, try it on my Mac, adjust. The same loop built the website.
08Outcomes
09Learnings
Being my own first user 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.
CONNECT, CPS Energy’s employee intranet, redesigned around everyday tasks, with news and updates that are quick to scan.
01Background
CONNECT is where CPS Energy’s employees go for pay, benefits, tools and company news. The old one ran on a legacy tool and was showing its age.
I redesigned it page by page, along with the components every page is built from.
02The old CONNECT
Two banners and an eight-slide slider come before anything else.
Nine menus across the top, ten departments and a dozen banners down the side.
A big photo, then a list of links to read through.
Long posts, with the deadline somewhere in the text.
03Design challenge
Three goals for the new CONNECT.
04Information architecture
I sorted everything again by what people come to do. Switch between Before and After to see where each old link went.
The menus, open
Each menu opens on five groups, with every link in view: no second level to dig through.
05Low-fidelity wireframes
What comes first on each page, settled before any visual design.
Home
Latest updates
Events
News hub
06Design system
Tags for topics, date tiles, buttons, cards and rows: each part does one job and looks the same wherever it appears.
Colour
Tokens
One type family, Roboto, in seven sizes. Spacing runs 2 to 32, corners 4 to 12, and focus is always a visible ring.
States
Every part has the same four states: default, hover, focus and disabled, plus the states that matter to it, like read and unread, or registered.
07High-fidelity designs
1/7 · Sorted by department
2/7 · The slider comes first
3/7 · News you have to read
4/7 · No place for dates
5/7 · Pages of links
6/7 · Finding things
7/7 · Moving everyone over
08On the phone
Many people at CPS Energy work in the field, so the home page had to work one-handed. The tasks stay on top, and two tabs split the rest: Discover for stories, Resources for everything else.
HomeSwitch the tabs to see both.
MenuThe same two menus as on the desktop.
09Development
We moved from Adobe Experience Manager to Edge Delivery Services for faster pages, easier publishing, fewer technical dependencies and simpler upkeep.
Each component became a block in the editor. Here is the Career page, built in three steps.
10Success criteria
11Learnings
With one set of components, a new page is mostly the right blocks in the right order.
Track the Yes answers on each page and fix the pages people leave with a No.