Designing one screen where operations teams create requests, catch missing data, and request the right assets — without switching tools.
Redesigned Haddad's internal request tool so operations teams could create, validate, and act on production requests from one screen.
Led research and design end to end — interviews, wireframes, prototyping, and usability testing with two operators.
Splitting valid from invalid styles removed the single biggest source of confusion found in testing.
Two in-depth interviews surfaced sharper, more actionable findings than a wider, shallower survey would have.
One screen. Seven steps. From scattered request to validated, asset-ready work.
Haddad's teams were handling production requests that had no structure. Styles, assets, and missing data were all mixed together. Nobody could tell at a glance what was ready to move and what wasn't.
This project was about fixing that. Not by adding more steps, but by making the existing work readable.
{{ card.body }}
I sat with the team to see how requests really moved, then tested early designs with two people who do this work every day.
{{ m.body }}
One request could hold 40 styles. Some were fine. Some were missing a brand or a color. Some needed a specific type of photo. The old spreadsheet showed all of them the same way, so people had to check every row by hand.
Before: a row in a spreadsheet, with no owner and no status. After: a request with a clear status, a named owner, and the right actions right there.
These come from two interviews — with Joanna and Kathryn, who both handle production requests, but on different teams. Their problems were almost the same.
{{ f.body }}
To make the problem sharper, I asked:
Show ready and blocked styles in two distinct sections, always, so priority is obvious without scanning row by row.
Creating, validating, and requesting assets for a style should never require switching tools or re-entering information.
The whole request — from the title to the asset request — happens in one place. Nothing lives in a separate email or spreadsheet.
Valid and invalid styles always show separately. You can't save until you've seen and fixed the errors.
I looked at structure first, and worried about visuals later.
Tabs hid errors behind navigation. Users only discovered invalid styles if they clicked the right tab — and often missed critical issues entirely.
Invalid and valid always visible together on a single screen. Priority was instantly clear. Testing confirmed this worked best across all request sizes.
Good for first-timers. Power users handling 40+ styles found the forced step-by-step flow too rigid and slow for high-volume work.
Before opening Figma, I sketched the screens that mattered most: request creation, the valid/invalid split, and the asset request row.
I tried three versions of the form. The one with the fewest fields worked best.
Mixing errors with ready styles confused people in early testing. Separating them made the task obvious — fix what's broken, then act on what's ready.
Putting the asset request buttons on each row meant you never had to leave the screen to request something.
{{ c.body }}
{{ o.problem }}
{{ o.opportunity }}
Before, the important details lived in someone's head — name, owner, deadline, priority. Now they're captured when the request is made, and everyone can see them from that point on.
{{ z.detail }}
The screen was structured around task progress: define the request, add styles, fix errors, confirm valid styles, and submit.
Errors aren't a wall that stops you. They show up as part of the task, so you know what to fix before you save.
Once styles were checked, people could request the assets they needed right from the style row — no switching tools, no copying references, no remembering where things were.
Built to handle everything: clean requests, big batches with errors, partly done work, and overdue items — all readable without opening a single one.
{{ d.why }}
These are the intentions behind the design, not measured results. They show what a structured, visible workflow is meant to do.
{{ o.body }}
I used AI to sort through Joanna and Kathryn's interview notes and spot where their answers matched or differed. That was faster than reading both sets side by side by hand.
But every real decision — what to split, what to flag, what to cut from the step wizard — came from watching them actually use the tool, not from a summary.
A good internal tool doesn't just store work. It shows people what's ready, what needs attention, and what can move forward — without anyone sending a follow-up message. Splitting valid from invalid styles was the one change that made the rest of the screen work.
{{ r.title }}. {{ r.body }}
{{ l.body }}