Supplier App - North Star
Nobody knew what to build, or why. That turned out to be the most important design problem on the project.
Mobile · Native iOS
AI · Enterprise · 0→1
Role
Sr. UX Designer
Timeline
8 weeks
team
PM, Stakeholders, Suppliers, Engineers, Me
platform
Native Mobile (iOS)
The Real Problem
The request came in simple enough: Walmart already had Supplier One on web. Stakeholders wanted to know — could we have a mobile app too? Similar to what Walmart Seller had. Same design system. Ship it.
Nobody had defined what "it" actually was.
No goals. No use cases. No answer to the most basic question: what are enterprise suppliers — people managing complex logistics, catalog data, and compliance workflows across multiple systems — actually going to do on a phone?
That question needed to be asked out loud before a single screen got designed. So I asked it.
The conversation that followed opened up two directions at once. First, an MVP built on real research — lightweight, focused, solving a specific and urgent problem for suppliers. Second, a North Star vision — showing stakeholders what a full Supplier One mobile experience could eventually become, to validate whether the investment was worth making at all.
I ran both tracks simultaneously. That's the story.
Finding the Fix
Before any design started, I went to suppliers directly. The question I wanted to answer wasn't "what features do you want on mobile?" — it was "what happens when you're away from your desk and something goes wrong?"
The answer came back fast and consistent.
Shipments. Purchase orders moving from suppliers to Walmart's distribution and fulfillment centers — PO to DC, PO to FC — were happening around the clock. Issues could surface at 2am on a Sunday. And the only way a supplier knew something had gone wrong was either logging into Supplier One on a desktop or digging through an inbox flooded with hundreds of automated emails that all looked the same.
'We don't know what's happening with our shipment until we log into the system.'
'I get over a thousand emails. Finding the one that matters is impossible.'
'By the time I see there's a problem, we've already missed the window to fix it.'
The interviews also surfaced something the brief had never mentioned: terminology. Suppliers don't search notifications by description. They search by PO number or shipment number — specific identifiers they carry in their heads. They copy FC and DC numbers directly into other systems. The mental model for how they navigate their own logistics was completely different from how a general notification feed is typically designed.
That meant the transportation notification feature wasn't just a feed — it was a hierarchy. What's urgent vs. informational. What's a blocker vs. a status update. What needs to go to a push notification vs. what can live in the center. And what search needs to understand to be useful at all.
What Actually Happened - MVP Track
I drafted wireframes for the transportation notification experience and ran them back through supplier feedback as the design evolved. The notification hierarchy went through multiple rounds — getting the right information at the right level of prominence took more iteration than expected, because what feels "obviously important" to a designer isn't always what a supplier is actually scanning for at 7am before a warehouse opens.
The search behavior was one of the most specific design decisions on the project. Standard search assumes general text. Supplier search assumes a number. Building the input and results pattern around identifiers — PO numbers, shipment numbers, FC/DC codes — made it immediately more useful without adding complexity.
The second feature in the MVP was the one I was most curious about: AI notifications.
While doing broader research on Supplier One web, I'd been trying to understand what an AI use case on mobile actually looks like for enterprise users. The pattern I kept coming back to was this: suppliers aren't going to complete a complex multi-step workflow on a phone. But they will act on a clear, confident recommendation if the decision is already made for them.
That's where the Marty agent notification came in. Instead of surfacing an alert saying "your content score dropped," the notification read: "Marty reviewed content check on [Product]. Score can improve from 70 to 90%. Would you like to review and apply?"
Clear impact. One decision. Human in the loop. No complex steps.
Suppliers loved it. The transportation notifications gave them control over something that had felt completely out of their hands when they were away from a desk. The AI notification gave them a way to act on recommendations without ever needing to open a laptop. Both together made the MVP feel genuinely useful — not just "the web, but smaller."
Finding the Fix — North Star Track
While the MVP was being built, I was running a parallel question: what could Supplier One mobile eventually become?
The Walmart Seller app existed as a reference point, but it was still early and raw in capability. Supplier One's web platform was much more complex — multiple MFEs covering catalog, maintenance hub, SQEP, supplier home, and more. The question wasn't whether to put all of that on mobile. The question was what it would look like if you designed each piece natively for mobile — not translated from web, but rethought for how someone uses a phone.
I went through Supplier One MFE by MFE. For each one, I asked: what does a supplier actually need to see on mobile vs. do, and does the web pattern even make sense here? A lot of what works in a data-heavy desktop layout falls apart on a 390-pixel screen. Icon placement, navigation hierarchy, the depth of information shown at each level — all of it had to be reconsidered from scratch.
I was also learning iOS native guidelines in depth during this phase — not to abandon Supplier One's design system, but to understand where native patterns would make the experience feel right on a phone rather than foreign. The goal was an app that used the same design language as the web platform but felt like it belonged on a phone.
The explorations went wide before they went focused. Many directions for navigation placement, many approaches to information density, many ways to handle the same MFE content at different screen sizes. That breadth was the point — the North Star wasn't about finding one answer, it was about showing the full shape of what was possible.
What Changed
The MVP transportation notification and AI notification features landed with suppliers as the most immediately useful thing the Supplier One mobile project had produced. Suppliers knew exactly what was happening with their shipments. They could act on AI recommendations without sitting down at a computer. The feedback was direct:
'Now I actually know what's happening with my PO without logging in.'
'The AI notification saved me a full workflow. I just approved it and moved on.'
'This is the first time I've felt like I have visibility into my shipments from anywhere.'
The North Star vision landed differently — and equally well. Stakeholders and design leads who had started the project with a vague "can we have an app?" now had a clear, grounded picture of what that app could look like at full capability. The vision was appreciated, believed, and added to the product roadmap for the coming year.
Two tracks. Both landed. The project that started with no defined goal ended with a shipped MVP that suppliers trusted and a vision that made the roadmap.
What I Had to Work With
No brief and no precedent. The Walmart Seller app existed but was early. There was no established pattern for what a complex enterprise supplier tool should look like on a phone. Every navigation decision, every information hierarchy choice, every native pattern was being figured out for the first time. That's exciting and disorienting in equal measure.
Running two workstreams simultaneously. The MVP needed research, user interviews, wireframes, iterations, and a shipped feature. The North Star needed MFE-by-MFE exploration, native pattern research, and a vision document compelling enough to influence a roadmap. Both were live at the same time, which meant constant context-switching and very deliberate prioritization of what needed to move forward each week.
The complexity of enterprise workflows on a small screen. This was the central design constraint of the whole project. Supplier One web is genuinely complex — it handles catalog management, compliance, logistics, performance, and more. The discipline required to decide what belongs on mobile, what doesn't, and what needs to be fundamentally reimagined rather than just resized was the hardest ongoing judgment call on the project.
Learning native guidelines mid-project. iOS native patterns don't always align with what a web-based design system does. Getting those two things to work together — same visual language, native behavior — required going deep on platform guidelines while staying consistent with what suppliers already knew from the web.
What I'd Do Differently
I'd push for at least a light goal-setting session before any design work started. The questions I asked at the beginning — why an app, what would suppliers actually do on it, what success looks like — were the right questions. But they came from me pushing back on an undefined brief rather than from the team starting in alignment. Getting that conversation to happen earlier, with the right people in the room, would have given the MVP clearer guardrails from day one.
I'd also run a quick validation round on the North Star screens with real suppliers before finalizing the vision. Stakeholders loved it — but supplier reaction to the broader vision would have added a layer of evidence that made it even harder to deprioritize in roadmap conversations.
What I Learned
"Why" is a design deliverable. The most valuable thing I did on this project was ask why before designing anything. Not as a philosophical exercise — as a practical one. The answers shaped everything: what the MVP focused on, what got cut from scope, and what the North Star was actually trying to prove.
Mobile isn't web at a smaller size. Every MFE I looked at during the North Star phase required a different conversation about what to keep, what to cut, and what to rethink entirely. Enterprise complexity doesn't compress — it gets reorganized. That reorganization is design work, not just layout work.
Specificity makes AI useful. The Marty notification worked because it was specific: this product, this score, this improvement, one decision. Vague AI suggestions get ignored. Concrete ones with clear impact get acted on immediately. That principle will shape how I approach AI feature design going forward.