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.
A lot of the time, the cause was a digital key made two years earlier that had simply expired. Support only heard about it once shoppers couldn’t pay.
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. Someone revokes the old key too early, or the website check fails without saying anything.
Every customer at checkout sees it fail.
A complaint comes in with nothing to go on.
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
We wanted a real person watching every deadline, and no way to do the risky step too early.
06Design trade-off
We went with one person first, because when everyone got the email, each of them assumed someone else would handle 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 own account, so a warning on our side wouldn’t reach them.
Key insightIt turned out the only real proof a new key works is a payment going through with it.
4/5 · Website check fails silently
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.
The contact list sat below the fold, away from the alert it related 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.
They could see the lock but not why it was there.
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 →09What we’ll measure
10Learnings
Mostly the fix was making deadlines visible and giving each one an owner. We didn’t need new technology.
Testers read a locked Revoke as broken until a line beside it said why.
Support could find their way around it like any other Apple app.
All our sessions were with support people. But the locked Revoke lives in the shop’s account, so next time I’d get it in front of 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
The engineers who build Apple Pay and Wallet test with real bank cards, often for a specific network, country or feature. There aren’t many of these cards, and everyone shares them.
Operations teams look after the cards. Requests came in over email and Slack. Who had what was tracked in a shared spreadsheet that was never quite up to date, and any report meant counting by hand.
Avalon brings all of that into one web app. I was the UX/UI designer on 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. The same country is written several different ways.
Send Ops an email that leaves out the project, the dates and how you’ll pick it up.
The sheet says someone has it, but they’ve moved teams, so you start asking around in chat.
The card changes hands at a desk and nothing gets written down. At the end of the month, someone counts them by hand.
03Design challenge
What we wanted for engineers and Ops.
04Information architecture
Engineers and Ops used to share a spreadsheet and an inbox. Now everyone looks at the same card, with one status that updates as each of them does their part.
05Design trade-off
We went with both. The engineer is the person holding the card. The project explains why they have it and sets when it goes back to the shared inventory.
06Design system
I used the same building blocks as Apple’s other web tools: a top bar, a sidebar, large titles, inset lists and sheets. Each status has one name and one colour, and they stay the same on every screen.
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
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 down at the desk. Recording the card ID right there is what keeps it accurate.
Engineers, Ops, admins and leads all look at the same status, so nobody reconciles versions.
I’d like to watch Ops count every card and see which parts of the history they actually rely 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 numbers next to a fair benchmark, and sends their cases to Apple’s merchant support and operations teams in Salesforce. I designed it as the UX/UI designer on a team of 12, with a product manager, engineers, QA and business analysts.
An Apple tool under NDA. Shops, people, rates and case numbers are illustrative.
The three numbers we track
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, but nothing about 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.
They send screenshots and exports by email, then spend weeks asking “any update?”.
03Design challenge
What we wanted the portal to do.
04Information architecture
Before, merchants had a payments report and an inbox. Now the portal sits in the middle: numbers come in, cases go out to Salesforce, and their status comes back.
05Design trade-off
We went with a band: above average, average, 0–10% below, or more than 10% below.
06High-fidelity designs
1/7 · No number for Apple Pay conversion
2/7 · Nothing to compare with
3/7 · Drop-offs nobody sees
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.
When merchants open a case right from the drop, the data comes along with it.
Shops without a payments team may need “What to try” before the numbers.
The app USAA employees use to look people up, buy and sell things, register visitors, get IT help and read the news. It replaced six separate apps.
01Background
When I joined the project, a USAA employee who wanted to look up a coworker, register a guest and check on an IT ticket needed three different apps. There were six in all.
They were built at different times by different teams, so no two looked or worked the same. People told us they often didn’t know which one to open.
Our job was to fold all six into one app for more than 80,000 employees. I was the UX/UI designer on a cross-functional Scrum team of 12, from the first survey to the final screens.
The research and results are real. The screens are redrawn, so names, items and numbers in them are made up; the old ones follow the original apps.
What went into Maven
Look up a coworker, see their team and where they sit, and message or call them.
Employees sell cars, furniture and electronics to each other. It was one of the most loved apps.
Register a guest, a delivery or a ride share so security knows they’re coming.
Ask IT for help, follow your tickets, read company news and watch videos.
02The old way
First you had to remember which of the six apps did what you needed, and whether you’d installed it.
Every app had its own menus and its own idea of where things go.
Registering one visitor meant going through screen after screen of fields.
Profiles were filled in differently from person to person, and many were missing details.
03Design challenge
What we were going for.
04Information architecture
In Maven, everything sits under one tab bar and one search, and the tools you use most are on Home.
05User feedback
Feedback and the design changes it led to
“Directory and Visitor Request are what I open most.”
People got its own tab, and Visitors sits on Home.
“One app is fine, as long as I don’t lose anything.”
We mapped every feature in the old apps before moving any of them.
“Show me what matters for my job.”
You pick the tiles on your own Home screen.
“Half the profiles are missing information.”
Every profile now has the same three tabs: Info, Bio and Org chart.
“The visitor form takes forever.”
We cut the request down to the fields security actually needs.
“It’s hard to find anything in the marketplace.”
We added categories and filters.
06High-fidelity designs
Redrawn with made-up people and data.
1/7 · Six apps to install
2/7 · Hard to find anything
3/7 · Inconsistent profiles
4/7 · Inconsistent profiles
5/7 · Every app looked different
6/7 · Long visitor forms
7/7 · Hard to find anything
07Outcomes
08Learnings
That list is what let us retire the old apps without anyone losing something.
With 6,000 people in one channel, we heard back in hours instead of waiting for the next review.
I’d want to know how often people find what they’re looking for on the first try.
09Prototype
Tap the tabs, the Quick access tiles, the search bar or a person in People to move around.
Tap around the phone. Tap anywhere else and it shows what you can tap.
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
Now the squad and the plan are their problem too.
The organiser posts in every group they’re in.
Everyone works out what they owe over messages.
The match starts with thirteen, or is called off.
03Concept
I wanted finding a match, joining it or organising one to take as few steps as possible.
It started one Thursday evening, one player short again. I thought: why does something this simple need so much talking?
People still loved playing, but the back-and-forth around it wore them out. Players just wanted to find a match and join.
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 insightNobody asked for another social app.
05Low-fidelity wireframes
I drew one wireframe for each step, so the layout and the order of information were settled before any visual design.
FindMatches grouped by day.
JoinSquad, price, one button.
JoinedThe moment you’re in.
ShareOne link to post in the group chat.
HostPick the pitch, the hour and the fee.
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. The rating is now 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.How we use colour
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
We’ve designed this but haven’t built it yet. An organiser publishes a tournament, and teams or single players enter, pick a squad and follow the fixtures.
08Outcomes
09Learnings
If nothing is on in a city yet, the live app just says so. It doesn’t fill the gap with sample matches.
The idea, the test and the feedback all came from the people we play with every week.
Now that it’s live, I want feedback from inside the app too, not just 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 told me about a Mac app that put meetings in the notch. I wanted it to do more, so I started building my own.
02Concept
I wanted the notch to be where the small stuff shows up.
03Low-fidelity wireframes
I sketched each one first, to work out the layout and how much space the notch should take up.
MeetingsThe closed notch gets a bit wider for a meeting.
JoiningAt start time, Join is right there.
MessagesA message, answered from the notch.
TranslationRead it without leaving the page.
BatteriesAll your devices on one card.
FilesThe notch opens up so you can drop files in.
HomeThe notch expands into a panel of cards.
04Visual identity
The first icon was a dark screen with a glowing notch. Before redrawing it, I laid out eight directions side by side, at full size and at Dock size, on light and dark backgrounds. The new mark combines two of them. The notch is the bar of a T, and the dot turned into 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 dotA bar for the notch, and a dot coming out of 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 decided how every screen looked and behaved, and Claude Code was basically my engineer. We wrote the Swift together.
For every change I’d describe it, review the code, try it on my Mac and adjust. I built the website like that too.
08Outcomes
09Learnings
Being my own first user made trade-offs easier to call.
Every feature started from something I actually needed.
I want to watch new people set it up and see where they get stuck.
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.
I redesigned it page by page, along with the components every page is built from.
02The old CONNECT
Before anything else, you scroll past two banners and an eight-slide slider.
There are nine menus across the top, and ten departments and a dozen banners down the side.
You get a big photo, then a list of links to read through.
Updates are long posts, and the deadline is buried somewhere in the text.
03Design challenge
What we wanted the new CONNECT to do.
04Information architecture
The old lists were sorted by who owned each page. I re-sorted everything by what people come to do. Switch between Before and After to see where each old link went.
The menus, open
Each menu opens to five groups with every link visible, so there’s no second level to dig through.
05Low-fidelity wireframes
I used these to settle what goes first on each page before starting any visual design.
Home
Latest updates
Events
News hub
06Design system
Topic tags, date tiles, buttons, cards and rows. Each part does one job and looks the same wherever it shows up.
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 any it needs on its own, 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
Partway through, we moved from Adobe Experience Manager to Edge Delivery Services. We wanted faster pages, easier publishing, fewer technical dependencies and less upkeep.
Each component became a block in the editor. Here is the Career page, built in three steps.
10Success criteria
11Learnings
Once the components exist, a new page is mostly a matter of picking blocks and putting them in order.
Track the Yes answers on each page and fix the pages people leave with a No.