“I believe humane design starts with understanding people.”
· Bengaluru, IndiaI turn complex workflows, data, and AI into intuitive products that help teams make better decisions.
People, systems, data, decisions, clarity.
Associates/Sourcing Managers/Merchants/Business Teams
I don't define myself by titles.
I define myself by the products I help build.
At scale, clarity isn't a visual choice.
It's how teams make better decisions.
Turning supplier data into sourcing decisions.
Product Strategy · System Design · UX Direction
I shaped the product strategy and UX direction, aligning business, data, and product teams around one decision model for supplier discovery, evaluation, and assessment.
Measured reduction in time to identify a qualified supplier.
Intended to support itSearch, filters, structured supplier information and shortlisting.
Measured search relevance among the top-five results.
Intended to support itUnified vendor linkage, Supplier ID search, business-relevant search criteria and similar-supplier discovery.
Measured share of supplier profiles meeting readiness criteria.
Intended to support itUnified supplier profiles, consistent supplier identity and foundational supplier information.
Business goal for supplier assessments initiated directly in Matrix.
Intended to support itA structured supplier evaluation experience using Performance, Risk and Capability, with explainable scores and supporting evidence.
25% faster, ≥80% and ≥90% are measured outcomes. >90% is a business goal for assessments initiated in Matrix — not yet a measured result.
From fragmented supplier data to one sourcing decision model.
I untangle workflows, turn complex data into signals, and build products that create clarity without losing depth.
Know moreSystems designed to make complex enterprise work simpler.
View case study ↗
· Enterprise AI2025–NowPerformance, risk, and capability signals lived across fragmented systems. Supplier Matrix unified them into one trusted decision layer for supplier discovery, evaluation, and monitoring.
From fragmented supplier signals → to a trusted decision layer.
6+ SBUs · 4+ Markets · Released Q1 2026 · Piloted across every SBU
View case study ↗
· Enterprise AI2026–NowTurned inventory gaps into explainable recommendations suppliers can act on inside Supplier One.
Alert → Insight → Recommendation → Action
From inventory gaps → to explainable recommendations and action.
Released Q2 2026 · Integrated with Supplier One
View case study ↗
· Ops2022–23Real-time shipment visibility across fulfillment, distribution, and last-mile operations — because teams lost visibility across every handoff.
Every handoff used to be a black box. Now it's one trackable journey, start to finish.
Live since 2022 · Powering eCommerce operations across MX
Helping small businesses access flexible working capital — from ₹3,000 up, with 15–60 day credit terms — without the friction of traditional credit.
Getting working capital used to mean weeks of paperwork. Now it's a credit line that updates itself.
Launched in 2021 · Digital Credit & Pay Later · MSME Platform
View case study ↗
Helping people find the right building entrance — not just the right address — with a unique code for every entrance, searchable and shareable in seconds.
One address, many entrances — each gets a unique Bawsala code.
Launched in 2018 · Location discovery · Navigation · Maps
View case study ↗
· Logistics2020–22Bringing fragmented delivery milestones into one planning experience—improving visibility and reducing preventable demurrage and detention costs.
Turning scattered milestones into one plan teams can act on.
Live since 2020 · Ocean logistics · Demurrage & detention
Complex workflows. Fragmented systems. Too much data. That's where the interesting problems begin.
A selection of products, systems and experiments shaped across fintech, AI, enterprise and everyday life.
Explorations where I prototype ideas before they become products.
Meet Surety — an AI concept that turns a supplier risk signal into a negotiation-ready plan.
View case study →AI-assisted visual QA — comparing Dev against Figma to speed up fidelity review.
View case study →An early-stage startup experiment — turning a broad pet-care vision into a focused MVP direction.
View case study →
I'm Saiky (Saikiran Desai), a senior product designer in Bengaluru. I design complex products and turn them into experiences people can actually use.
I've worked with Walmart, Maersk, SOLV, and Standard Chartered, designing products across enterprise, fintech, and emerging businesses.
Right now, I'm exploring how AI is changing the way we design, build, and interact with products — and what that means for the future of product design.
A practical, AI-assisted design process that turns ambiguous problems into validated product decisions and measurable outcomes.
Understand users, business constraints and opportunities.
Turn problems into concepts, flows and shared decisions.
Turn concepts into working prototypes using AI-assisted tools.
Partner with engineering, validate delivery and measure impact.
I care less about producing more screens and more about making the right thing clear enough to build, use, and scale.
10+ years of moving from interfaces to complex product systems.
Most weekends, whatever the heat.
Himalayas, Nepal — usually with one backpack and no fixed plan.
Mostly abstract. Occasionally something that actually looks intentional.
Travel, fashion, lifestyle, and whatever catches my eye.
Building the thing instead of just describing it.
South Indian filter coffee. Good music. Repeat.
Trust the next step before you can see the whole path.Saiky
“Saiky inspires me. He thinks deeply through complex problems to ensure his solutions align perfectly with both user needs and business goals. He is a phenomenal collaborator across teams who brings boundless creativity, genuine humility, and a constant willingness to learn.”
“Saiky is an exceptionally talented product designer who balances user needs with business outcomes. He excels at translating research into thoughtful, impactful solutions and has been a strong AI champion on the team—helping others adopt new tools and approaches. Collaborative, supportive, and always elevating the work and people around him.”
“Saiki is a great design partner to work with. I worked with him on several initiatives while building an Enterprise platform at Walmart supporting Supplier Quality operations. Saiki asked a lot of great questions, pushed for clarity around the core problems being solved while not settling for the seemingly obvious easy answers. His focus on user centric thinking is evident. Given a chance I would like to work with Saiki again.”
“Saiky's work speaks before he does. His portfolio is sharp, direct, and self-explanatory — you understand how he thinks within seconds of landing on it. What sets him apart is the craft behind it: every detail feels intentional, and he takes feedback seriously, refining without ego. Anyone who works with Saiky gets a designer who thinks deeply and ships beautifully.”
“Sai is a great thought partner. He takes the time to deeply understand the business context and, more importantly, the users' needs before jumping to solutions. What stands out is his curiosity and willingness to learn. I would highly recommend Sai to any team looking for a UX professional who combines user empathy, business understanding, and a continuous learning mindset.”
Turning fragmented supplier data and inconsistent evaluation into a trusted enterprise decision system.
The full screens, design process, and product rationale are available to approved reviewers. Enter your password below, or request access for the complete walkthrough.
Bring supplier information, performance and risk into a shared evaluation experience.
Connect discovery, evaluation, comparison and monitoring instead of making associates reconstruct the story.
Establish the structure for capabilities, Supplier Insights, semantic search and proactive recommendations.
ProblemSupplier signals came from many systems — onboarding (VIP), internal tools (AMA, GSE) and a legacy Informix database.
Design decisionBuild a decision layer on top of existing supplier data, not another supplier database.
Intended valueOne trusted starting point to find, understand, evaluate and monitor suppliers.
ProblemTeams applied inconsistent evaluation criteria.
Design decisionStructure evaluation around Performance, Risk and Capability, rather than one supplier-health score.
Intended valueClearer, consistent criteria for comparing and ranking suppliers.
ProblemA score alone did not create confidence.
Design decisionMake scores explainable — score → drivers → trend → calculation → context.
Intended valueAssociates can understand a score without the calculation being hidden.
Performance, risk and capability signals lived in different places. Teams applied inconsistent evaluation criteria. Supplier discovery depended heavily on manual networks, and a score alone could not provide the context needed for a confident decision.
Signals distributed across systems and teams.
A shared profile for supplier intelligence.
Different signals and criteria shaped different decisions.
Performance · Risk · Capability.
Peer networks, spreadsheets and multiple tools.
Search, filter, compare and monitor.
A number alone did not create confidence.
Score → drivers → trend → context.
I pushed for separating Performance, Risk, and Capability rather than reducing supplier health to one score.
My role was to make complex business and data logic understandable and actionable—not to define that logic alone.
Turn broad supplier-management needs into the questions associates needed the product to answer.
Organize supplier identity, Performance, Risk, Capability and deeper context into a usable hierarchy.
Discovery, profile, score details, comparison, category context, monitoring and insights.
Partner with research and product to test assumptions and turn findings into design decisions.
A companion IA kept the team aligned on how the three pieces connect — from portfolio-level triage in the Dashboard, through the Management listing, to one Unified Profile record.
The complete component-level tree — dashboard triage down to Unified Profile fields — used to keep engineering, product and design aligned on scope.
I filtered the workshop output to the needs directly relevant to Supplier Matrix: centralized supplier context, capability visibility, evidence-based assessment, faster discovery and consistent shortlisting.
"Supplier Matrix really helps reduce the grunt work here."
Explore the capabilities of existing and potential suppliers.
Use centralized assessment, readiness, capability, risk and performance context.
Rank suppliers more consistently using cost, history, reliability and business context.
Develop the supplier pool when existing options cannot meet the need.
Internal teams needed reliable supplier information in one place instead of reconstructing it across sources.
Product- and item-level capability helps teams understand supplier fit, potential and negotiation context.
Workshop notes called for reducing manual effort across long supplier lists and improving filtering.
Associates wanted clearer criteria for supplier ranking rather than inconsistent manual comparison.
Build a decision layer on top of the existing supplier systems instead of consolidating them into one more database.
A standardized view of supplier performance and the metrics driving it.
Financial and risk context to support screening and additional review.
Signals about the supplier's ability to execute, scale and support opportunity.
The Performance Score combines signals with different units, directions, levels of supplier control and business importance. The UX challenge was not to simplify the calculation—it was to simplify how associates understand it without hiding how it works.
Show the Performance Score as a starting point with its drivers, trend and calculation visible — never as a closed number.
9 participants—5 Sourcing Managers and 4 Merchants—reviewed in-progress concepts in 30-minute remote interviews across Food, General Merchandise and Health & Wellness.
Make the score an entry point into evidence, not a verdict on its own.
Finding: Most users did not value logos in long supplier lists.
Decision: Prioritize supplier identity, address/location and useful metadata.
Finding: "Risk" was the most understood label; higher risk was expected to be worse.
Decision: Keep Risk and make direction/severity explicit.
Finding: Scores supported shortlisting, but users wanted metrics, commentary and category relevance.
Decision: Treat the score as an entry point into deeper evidence.
Finding: Prior contacts and factory-visit history influenced confidence.
Decision: Preserve paths to qualitative supplier context where available.
"We have a Teams chat. I can ask, 'Does anyone know this supplier?' and it saves a whole bunch of time."
"I like the bottom metrics details — that shows where they fall on that risk and what the commentary is."
"I like to see the graph first because that shows me a timeline too of how those metrics have changed, and if I wanted to double-click into that, I can scroll down and see the actual numbers there."
Search, filter and shortlist around business-relevant criteria.
Identity, Performance, Risk, Capability and related context in one profile.
Drivers, trends, comparison and category detail support judgment.
Watchlists, alerts and Supplier Insights move the product from lookup to ongoing intelligence.
Design one continuous path — Find → Understand → Evaluate → Monitor — rather than separate tools for search, profile and monitoring.
Fourteen moments from the shipped product — discovery, explainability, monitoring and the calculations underneath every score.
Every supplier card supports pinning and adding to named watchlists — like “Top performers” or “Q2 priority fashion” — so a shortlist survives past a single session.
Filters cover D&B risk band, private label status, channel, market and country of origin, each showing a live result count before it's applied.
Every score carries its own definition, last-updated date and rating scale, so a number is never presented without the context to interpret it.
The D&B supplier rating gets the identical explainability treatment — definition, scale and freshness — reinforcing one consistent pattern across every metric.
When a score changes, the card explains why: previous vs. current value, the delta, and the top contributors behind the move.
The same change-detection pattern applies to risk. A D&B rating that moves the wrong direction is called out immediately, with the reason attached.
Capability is not one opaque score — it's manufacturing depth, product breadth and operational readiness, each independently rated and explained.
The same supplier can perform differently by category. This view breaks financial, operational and quality metrics down category by category.
When a supplier doesn't fit, the system proposes comparable options using portfolio and risk signals — with the reasoning shown alongside each match.
"Compare all" opens the suggested suppliers side by side against the same score columns as the main list, so the comparison is apples-to-apples — then the selected rows go straight to a watchlist.
Every metric can be expanded into its full definition — formula, weighting and a worked example — for teams who need to audit, not just trust, the score.
The table view supports multi-row selection, so a sourcing manager can shortlist several suppliers side by side and act on them together — pin, star or add to a watchlist in one pass.
The full supplier profile brings performance, D&B rating and capability into a single quarterly trend, with each metric's own definition available inline rather than in a separate report.
The same profile's D&B tab exposes the SSI, SER, Paydex and credit indicators feeding the rating — plus a plain-language commentary explaining why the risk classification changed.
Ship the core evaluation experience first, and treat intelligence and AI as the next layer rather than the entry point.
My contribution: I shaped the supplier decision framework, information architecture and core evaluation workflows, partnering with product, research, data and engineering to turn fragmented supplier information into a consistent decision experience.
Search, filters, structured supplier information and shortlisting.
Unified vendor linkage, Supplier ID search, business-relevant search criteria and similar-supplier discovery.
Unified supplier profiles, consistent supplier identity and foundational supplier information.
A structured supplier evaluation experience using Performance, Risk and Capability, with explainable scores and supporting evidence.
SMEs translated JTBDs into descriptive prompts so the team could explore future-state directions quickly. I used the outputs to compare possibilities, challenge assumptions and identify directions worth developing—not as final design.
A clearer supplier decision experience emerged from the work: centralized context, structured evaluation, evidence behind scores, and a path from discovery to ongoing intelligence.
"Complexity didn't disappear. It became structured enough to support a decision."
Making shipment deadlines, D&D exposure and planning priority visible in the workflow where Customer Service Agents already make delivery decisions.
The full screens, design process, and product rationale are available to approved reviewers. Enter your password below, or request access for the complete walkthrough.
Know whether D&D applies and when free time is ending.
See which shipments are at risk or already incurring cost.
Use D&D exposure as a signal to start or adjust delivery planning.
Capture Reason Code and Responsible Party for incurred cost.
Give customers the reason, number of days and applicable cost.
Carry D&D context into alerts, reporting and container visibility.
Customer Service Agents had to combine contract terms, shipment milestones and spreadsheet calculations to understand D&D exposure and decide which shipments needed attention.
Contracts, shipment milestones and cost formulas were maintained across Excel and reports.
Bring applicable D&D information into the shipment view.
Arrival, Gate Out and Empty Return determine D&D days and charges.
Show Last Free Date, days and D&D status together.
Users could calculate incurred cost but lacked a clear way to prioritize shipments before cost increased.
Surface At Risk and Incurring states so the CSA knows what needs attention first.
Reason Codes and responsibility were maintained manually after D&D was incurred.
Connect D&D cost to Reason Code, Responsible Party and Root Cause Analysis.
Synthesized CSA interviews, usability findings and business requirements to identify where D&D was affecting delivery decisions.
Prioritized Last Free Date, D&D state, cost, milestone, reason and action as the core planning signals.
Translated the requirements into list visibility, prioritization, alerts and root-cause pathways.
Used usability feedback to clarify hierarchy, reduce information hunting and strengthen the planning workflow.
4–6 systems were searched for ETA / vessel information, and some users spent up to 5 hours a week validating incoming-container ETAs. 90% of customer communication happened via homemade Excel sheets shared through SharePoint or email.
Excel had become part of the operational workflow for customer communication and D&D tracking, reinforcing the need to move the decision into the product workflow rather than create another report.
No single table layout fit everyone — reinforcing that a flexible, customizable table was a requirement, not a nice-to-have.
ETA changes → planning horizon changes → Last Free Date / D&D exposure can change → shipment priority changes. That made ETA, Last Free Date and D&D exposure a connected planning problem rather than separate data points.
Is D&D applicable, At Risk, Incurring or Incurred?
What is the current Last Free Date?
Which shipment needs attention before cost increases?
What Reason Code and Responsible Party explain the cost?
Can I move from exposure directly into planning?
Reason, number of days and applicable cost.
Move the decision, not just the data. D&D should appear where delivery priorities are being decided.
The shift was not to expose more data. It was to make the D&D consequence visible at the moment the CSA decides what to plan first. ETA, Last Free Date, D&D exposure and priority needed to be understood as one planning decision rather than separate pieces of shipment information.
Show the estimated or actual boundary for free time.
Make At Risk, Incurring and Incurred states visible with applicable cost.
Use D&D exposure to identify equipment that needs attention first.
Keep the event and expected timing that shape the decision visible.
Connect incurred cost to its operational cause and owner.
Move from a D&D signal directly into the relevant planning action.
I tested whether CSAs could move from a dense operational view to a clear D&D decision.
One operational view for equipment, BL, status, planning status, POD, ETA, ATA, final delivery, Last Free Date, priority and PO.
Customer-specific rules shape what gets surfaced first rather than forcing one fixed prioritization model.
At-risk and incurring states provide a reason to act, with direct navigation into root-cause analysis.
D&D context was difficult to connect to the planning decision.
Users needed stronger hierarchy around deadline, exposure and priority.
Strengthened hierarchy around Last Free Date, D&D status, cost and action.
Made D&D exposure easier to connect to delivery planning.
Different customers and tasks required different views, so one fixed table could not fit every workflow.
Choose visible columns, order and sort—and save the view for your workflow.
Move sorting and filtering into the column header for faster scanning.
Keep Excel part of the workflow with native import and export.
Use familiar Excel patterns—like freeze columns and sorting—to reduce the learning curve.
ETA and ATA were separated so each could be independently sorted and scanned.
Cost becomes applicable → CSA is notified → shipment opens → D&D context is visible → equipment is prioritized → delivery plan is reviewed → reason / owner is captured → customer is informed.
Notify the CSA when D&D cost becomes applicable or a container enters an Incurring state.
Take the user directly to the relevant shipment so they can review exposure and start or adjust planning.
I focused on making Last Free Date, D&D status, cost exposure, prioritization, alerts and root-cause context visible at the point of delivery planning.
Instead of requiring CSAs to reconstruct D&D exposure through separate calculations, the experience brings together ETA → Last Free Date → D&D exposure → Priority → Action at the moment the delivery plan is being made.
"The goal was not to hide the underlying rules. It was to structure them around the decisions a CSA actually needs to make."
Bawsala turns complex addresses into a searchable identity for the exact entrance people need to reach.
People need to find the right entrance, not just the right address. Bawsala creates a unique code for every entrance and makes it searchable and shareable.
Drivers and businesses need a location they can reliably identify, communicate and navigate to without depending on long or ambiguous addresses.
JDMR 8767 · JD = city code · MR = area code · 8767 = entrance code
Give each building entrance a simple, unique code that people can recognize and search.
Carry the selected destination into maps and routing without losing location context.
Give customers, drivers and businesses one location reference they can reuse and communicate.
Harder to search, remember and communicate consistently.
Every entrance gets a searchable identity.
The destination was not always the exact entrance.
The code points people toward the intended entrance.
Finding and reaching a place could require multiple steps.
Move from search to route without losing the location.
People needed a simple reference they could send to others.
A Bawsala code can be shared in seconds.
Turned the address problem into a location-identity problem, focused on the entrance people actually needed to find.
Shaped search, advanced filtering and the transition from code to place.
Carried the location context into map and routing experiences for customers and drivers.
Extended the identity into sharing and saved/favourite locations.
Started as the sole designer → team grew to 5–6. I joined as the first and only designer, owning the experience independently for the first two months as the team was forming. Leadership visited India quarterly, enabling direct discussions on product and business requirements. As the team expanded, I continued close collaboration with product and technology on the evolving product and backend address-marking workflows.
A single address can lead to multiple entrances, so the destination needs more precision.
The identity becomes useful when people can search for it quickly.
The same location reference should carry into navigation and sharing.
Identify → Search → Confirm → Navigate → Reuse. These findings shaped the interaction model end to end.
I treated the code as a persistent location identity — not just a search key — so it could carry through confirmation, navigation, sharing and reuse.
Make the entrance, not just the address, the destination.
Let people find the destination by its unique code.
Show the selected place in context before navigation.
Continue into routing without losing the destination.
Make the same code useful for sharing and saved places.
Use the unique Bawsala code to locate the intended entrance.
City, area and entrance-code filters make discovery easier to narrow.
Make the selected place understandable before moving into navigation.
Reuse the same code with other people or from a favourites list.
Carry the shared location into tracking and routing so the destination stays clear during the journey.
Give customers and delivery operations the same location identity to communicate.
Search code → confirm entrance → view destination → choose navigation → arrive → share or reuse. The key interaction decision was to keep the location identity consistent as users moved between discovery, navigation and communication.
Make each entrance identifiable.
Make the code useful for finding a place.
Carry the same identity through arrival and communication.
Bawsala turned a long address into a simple code that could identify an entrance, support search, navigation and sharing.
Saudi Arabia established its National Address in 2013, before Bawsala launched in 2018. Saudi Post | SPL also provides a Short Address using 4 letters and 4 numbers. In August 2025, the Council of Ministers adopted the National Address as the sole source for addressing in the Kingdom.
Bawsala's proposition increasingly overlapped with an addressing capability embedded in the national ecosystem. Public evidence supports that market overlap and later standardization; it does not establish that this was the only reason for Bawsala's adoption outcome.
"The UX solved a real address problem. The market increasingly standardized the underlying solution. The lesson: solving a user problem does not always create lasting product differentiation."
Designed the digital credit and Buy Now, Pay Later experience for buyers and sellers on Solv's B2B marketplace — bringing short-term revolving credit, invoice financing and repayment into a clearer working-capital journey.
Small businesses could be short on cash while still needing to finance inventory and day-to-day operations. BNPL created more time to pay without relying on traditional credit journeys.
Buyers received short-term credit against invoices, sellers could be paid upfront, and lending partners financed the underlying business transaction.
Make the financing choice, credit state and repayment journey understandable at the moments an MSME needed to act.
The full screens, design process, and product rationale are available to approved reviewers. Enter your password below, or request access for the complete walkthrough.
Make available credit and remaining capacity easy to interpret.
Bring Pay Later and invoice finance into the payment decision.
Connect verification, repayment, statements and account state.
Use credit across multiple invoices and repay on a flexible schedule.
Connect payment to the invoice rather than treating credit as a separate activity.
Extend the experience into card controls, credit utilisation and account management.
Approved, available and used limits are easy to confuse.
Make available and used credit understandable together.
The Pay Later choice needs to appear when the business is deciding how to pay.
Present financing alongside payment options.
KYC, activation and pending conditions need explicit feedback.
Explain verification, activation and exceptions.
Invoices, transactions and statements need to connect.
Return payment outcomes to the credit account.
Worked with product, business stakeholders and leadership to understand the financing model, user states and operational constraints.
Mapped Pay Later, invoice finance, onboarding, verification, repayment and card-management states.
Designed and iterated prototypes to communicate concepts, explore alternatives and support stakeholder decisions.
Collaborated with product, business, technology and stakeholders as backend conditions and requirements evolved.
Solv positioned itself as a B2B e-commerce platform and financial-services marketplace for MSMEs, working with banks, NBFCs and fintech partners. Its January 2021 announcement described BNPL as invoice financing for buyers and sellers, designed to support immediate business needs with more flexibility.
Available, utilised and approved limits must be distinguishable.
Pending, verified, activated and overdue states need explicit feedback.
Pay Later is most useful when it is visible at the payment decision.
Show approved, utilised and available amounts with a clear remaining balance.
Make repayment and transaction history explainable.
Keep the next credit action visible when the business needs it.
Pay Now, Cash on Delivery or Pay with Invoice Finance.
Show invoice and drawdown details before confirmation.
Complete OTP / required verification where applicable.
Explain successful request, amount and remaining credit.
Return users to the Pay Later account and statements.
Every step should answer three questions — what am I using, what will I owe, and what happens next?
Payment choice → invoice detail → verification → successful drawdown → updated credit view. The flow was designed so the user always understands the financing choice, the amount being used and the state of the transaction.
Guide users through registration, verification and activation states.
Support PIN, blocking, limits and international-usage decisions.
Connect card activity back to credit, transactions and repayment context.
Establish credit, KYC and activation.
Use financing directly within the B2B transaction.
Track utilisation, statements, payment and controls.
The work brought Pay Later, invoice finance, credit visibility, verification, card management and repayment into a more coherent product journey — a connected MSME credit experience rather than separate financial capabilities.
"In financial products, clarity is part of trust: users need to know what they can use, what they owe and what happens next."
Real-time shipment visibility across fulfillment, distribution and last-mile operations — because teams lost visibility across every handoff.
The full screens, design process, and product rationale are available to approved reviewers. Enter your password below, or request access for the complete walkthrough.
The initiative focused on a simple operational gap: once an order moved through the network, teams could no longer reliably see what was happening at each handoff. The opportunity was to connect fulfillment, distribution, stores, delivery stations and customer care around one trackable shipment journey.
After the truck leaves the FC, teams lose order visibility en-route, with no system to record receipt.
A single view carries the shipment across the journey.
Order details are shared through manifest files, Excel, calls and WhatsApp.
Status, route and delay context sit together in one place.
Without capacity or event data, teams struggle to protect on-time delivery.
At-risk shipments are visible before customers are affected.
Manifest files, calls, messages and WhatsApp became de facto coordination tools.
One trail supports proactive intervention instead of reactive searching.
Too many handoffs. Too little shared shipment state.
Tracks shipments in omni-channel routes, protects the SLA, and intervenes when shipments are delayed.
Coordinates the physical network across fulfillment, distribution, stores and the Brick fleet.
Needs shipment status to update customers and escalate orders requiring transportation attention.
Track shipments in omni-channel routes.
Ensure orders reach customers within SLA, without loss of shipments.
Receive notification when shipments are getting delayed.
Track shipments so customers can be updated on status.
Escalate orders that need transportation attention.
Notify customers proactively if a shipment is delayed.
No order visibility after the truck leaves the FC.
Significant manual effort to coordinate between FC / DC / Stores / DS.
Loss of visibility of orders within the DC.
DC does not ship orders in the expected / promised time, creating an OTD risk.
No capacity information at DC / trucks during promise calculation and route assignment.
The design opportunity was to make those two realities match.
No capacity feedback at promise calculation / optimized route assignment.
Orders shared by manifest / Excel; shipment events not consistently recorded.
Need visibility when orders are received by the store.
Once transport leaves the DC, downstream teams can be in the blind.
Needs shipment status and proactive delay notification.
Turn a fragmented network of handoffs into one visible shipment journey.
How might we help the Transportation Operation and Customer Operation teams get the tracking and visibility of shipment orders they need? Instead of asking teams to reconstruct status from files, calls and messages, the experience surfaces the shipment, its route, its current state and the action required.
Surface shipment state across the route.
Surface delayed and critical shipments so teams can intervene.
Give customer-facing teams reliable status they can communicate.
The dashboard turns a tracking problem into a decision-making workflow.
Search by Tracking ID or Order ID and filter the operational queue.
Use Critical, Ongoing and Historical shipment views to focus attention.
See status, route, delay and estimated delivery context.
Open the summary trail, coordinate intervention and communicate status.
Low-fidelity passes worked out where KPIs, the map and the shipments table should sit before any visual design began.
Dashboard → Routes → Trips → Order detail, mapped across four levels before any screen was built.
Filtered by All, Orders or Trips — surfaced from the dashboard's global search.
Same delayed-trip and status alerts, opened from the bell icon.
With shipment visibility across every handoff, this future-state concept explores how multi-hop optimization could compare routes across carriers and hops to improve speed, cost, and delivery performance.
Shipment visibility across omni-channel routes
Critical / ongoing / historical shipment views
Tracking ID and Order ID search
Operational filters and summary trail
Export to Excel
Multi-hop route comparison
Speed or cost optimization
Optimization rationale
Proactive shipment notifications
Visibility across every handoff
This concept explores how shipment visibility could evolve into multi-hop route optimization.
Associates can see the complete shipment journey, receive notifications at key handoffs, and understand where an order is at any point.
Once that visibility is available, the experience could compare different routes — for example:
The system could compare delivery time, cost and number of hops, and explain why one route may be better.
Illustrative future POC — not shipped functionality.
By enabling visibility, operations can avoid adding people simply to manually track and prevent lost packages.
The work connected a complex operational problem to a clear experience strategy: make shipment state visible, give teams a shared source of truth, and create a foundation for route optimization.
"Enterprise UX is often about making invisible coordination visible."
What I'd push next: measure intervention time, exception resolution and customer-notification effectiveness.
Connecting Scintilla In-stock Recommendations with Supplier One so suppliers can understand inventory risk, validate what is happening, and move directly into replenishment.
The full screens, design process, and product rationale are available to approved reviewers. Enter your password below, or request access for the complete walkthrough.
The opportunity was to connect Scintilla's inventory intelligence with the workflow suppliers already use to replenish inventory. Instead of asking suppliers to interpret a signal and then find where to act, the experience brings the recommendation into Supplier One and carries it through toward execution.
Help suppliers understand inventory risk, affected products, and the reasons behind an opportunity.
Surface the right issue early and provide enough context to decide what action is appropriate.
Bring In-stock Recommendations into Supplier One as a microfrontend within Top Tasks.
Measure whether opened recommendations lead to meaningful supplier action.
Reduce the distance between identifying an inventory risk and taking replenishment action — while helping protect in-stock performance and sales.
Inventory issues were spread across multiple applications and reports. Suppliers had to investigate manually, connect the dots themselves, and then switch into another workflow to act. The core problem was not a lack of data; it was the distance between a signal and a confident next step.
Information and signals were spread across tools.
Bring the relevant signal into Supplier One where it can be understood and acted on.
Suppliers had to determine what mattered and gather context themselves.
Use Top Tasks to surface high-priority replenishment opportunities early.
A signal alone did not explain severity, causes, or what to do next.
Show business impact, root causes, contributing factors, and supporting evidence.
Suppliers had to leave the analysis experience to create or submit an order.
Connect the recommendation to a prefilled PO and Supplier One Order Management.
From finding inventory issues to acting on the right replenishment opportunity.
The design challenge was to make intelligence useful at the moment of decision: surface the issue, explain why it matters, establish confidence in the recommendation, and provide a direct path to execution.
Surface high-priority replenishment opportunities in Top Tasks so suppliers focus on the most impactful issues first.
Explain why inventory gaps exist through root causes, contributing factors, and business impact before recommending an action.
Build confidence with transparent metrics, evaluation methodology, and supporting evidence behind every recommendation.
Enable suppliers to download prefilled Purchase Orders and continue directly to Supplier One Order Management.
I shaped the experience strategy and interaction model for connecting Scintilla's inventory recommendations with Supplier One — from discovery and recommendation comprehension through to replenishment action.
Experience strategy · interaction model · information architecture · recommendation experience · integration flow · prototype validation
The final decision was to surface the Scintilla In-stock Recommendations experience as a microfrontend (MFE) within Supplier One's Top Tasks, then connect suppliers directly to Order Management to complete replenishment.
The design had to preserve Supplier One's existing workflow while making Scintilla's intelligence feel native to the experience.
See a personalized replenishment recommendation proactively in Top Tasks.
Review business impact, inventory gaps, root causes, and contributing factors.
Validate the recommendation using supporting data and coordinate with RISM when needed.
Download a prefilled PO or continue directly to Supplier One Order Management.
Comparing this year's sales against the demand forecast shows whether the gap is a supply problem or a demand shift — informing better replenishment planning.
A state-level view of in-stock replenishable inventory helps suppliers prioritize which regions to act on first.
The key shift was moving execution into the recommendation journey rather than treating it as a separate workflow.
The experience was structured around four questions a supplier needs answered before acting: what is at stake, what changed, what needs attention, and why the recommendation can be trusted.
Retail sales impact, units affected, in-stock percentage, and weeks of supply help frame issue severity.
Compare actual sales with forecast to understand whether demand changes contributed to the inventory gap.
Drill into affected products, clusters, stores, and inventory levels to prioritize what should be investigated.
Show how calculations and recommendation logic were generated so suppliers can trust the result.
Analyze why products are unavailable at stores, such as supplier delays, low inventory, forecasting errors, or logistics issues.
Explain why the issue happened so suppliers can determine the appropriate response.
Work with the Walmart Replenishment Inventory Solutions Manager when the issue requires collaboration or validation.
Create a path to validate the recommendation and agree on the replenishment plan.
Download a pre-filled Purchase Order template containing recommendation data, then review or update it before submission.
Remove the need to create the order from scratch.
Continue to Supplier One Order Management to upload the completed PO and request inventory replenishment.
Make the primary call to action a direct move from recommendation to execution.
Top Task → Recommendation → Business impact → Root cause → Decision → PO / Order Management. The flow was designed so the supplier always understands what changed, why it matters, and what to do next.
The experience shift is not simply a UI consolidation. It changes the supplier's job from assembling evidence across systems to evaluating a recommendation with the right context and moving into the existing execution workflow.
The Supplier One experience is pre-launch, so these are success targets and measurement signals, not achieved results.
Success isn't just surfacing better insights. It's shortening the distance between insight and action.
"The value of intelligence is realized only when it is connected to the workflow where decisions become actions."
A decision-support concept for Supplier Matrix. Surety turns a quiet supplier signal into a negotiation-ready plan, so a Sourcing Manager can act in minutes instead of investigating for days. The merchant still makes the call.
AI proposes. The merchant decides. Surety surfaces the evidence and a recommended path — the final supplier decision, volume shift and negotiation stay with the merchant.
The full screens, design process, and product rationale are available to approved reviewers. Enter your password below, or request access for the complete walkthrough.
Surety watches on-time delivery, performance, cost and risk together, and raises one prioritized signal the moment the pattern looks like continuity risk — translated immediately into business terms, so a dip in a metric reads as sales exposure, units at risk and the size of the supply gap, not another number on a dashboard.
Two responses, not one verdict — mitigate the current supplier, or protect continuity with a qualified alternative. Surety never recommends abandoning Northwind; it makes the cost of each path visible and lets the merchant choose.
Seven signals that used to live in five different views, now evaluated together — so ranking an alternative is a system judgment, not a manual spreadsheet exercise.
A normalized quality measure — customer complaints per one million units sold — so supplier quality is comparable across very different sales volumes.
How long it takes to get an alternative supplier ready to actually supply — from the decision to move volume, to that supplier being able to deliver it.
Supplier B can begin supporting the shifted volume in 6 weeks.
How long it takes to restore supply continuity, or return to an acceptable operating state, following a disruption — the cost of the disruption in time, not just dollars.
Expected recovery to an acceptable continuity level: 6 weeks.
How a supplier's average cost per unit is trending — a directional, commercial signal weighed alongside performance and risk, not a locked-in price. Final cost impact and terms are always confirmed before commitment.
Ranked against the current supplier, not just listed next to it — Supplier B can cover the full 17% gap with stronger delivery, a more favorable D&B risk profile and a 6-week transition, at a directional cost premium still to be confirmed.
AI proposes the path and the concrete next actions for each — it never switches suppliers, reallocates purchase orders or commits to a negotiation on its own. The merchant reviews the plan and owns the final action.
Merchant / Operations reviews exactly what's affected, decides how much volume to move, and only then executes — Surety checks that Supplier B can actually absorb the selected volume before the shift can be confirmed.
Before anything executes, the full plan — response, volume and estimated impact — routes through the standard approval chain. Surety assembles the summary; it doesn't skip the review.
Once approved, Surety tracks the specific actions the plan requires — moving purchase orders, notifying the new supplier, updating allocation — and confirms each one instead of assuming the plan executed itself.
Tracked on both sides of the decision — Northwind's own delivery recovery if mitigating, or Supplier B's delivery, quality and PO execution if volume shifted.
The loop feeds back into step one — Surety doesn't stop watching once a decision is made; new signals reopen the same path rather than starting a fresh investigation.
"AI proposes. The merchant decides."
A small experiment to test whether AI could take the repetitive screen-by-screen comparison work out of visual QA, while keeping design judgment with the designer.
Instead of manually jumping between the implemented experience and Figma for every screen, I used Code Puppy to inspect both and produce a structured first-pass VQA report.
Open the current Supplier One experience and relevant states.
Use the actual design file as the expected source of truth.
Review components, states, charts, spacing, typography and behavior.
Generate issues with severity, UX notes and expected design.
Designer reviews the findings and removes false positives.
Three moments from the same session: reading the dev implementation, cross-checking the Figma source file, and confirming the visual match before writing up findings.
The experiment suggests a practical role for AI in everyday UX quality work: let AI search broadly, then let the designer validate, interpret and prioritize.
"AI didn't replace the designer's VQA judgment. It reduced the manual comparison work and gave me a faster first pass."
I helped turn One Paw Away's broad pet-care vision into a focused product direction — mapping the experience, defining the MVP, and prototyping what could come next.
A quick 0→1 exploration for a startup with a big idea. I worked with One Paw Away to turn an ambitious pet-care vision into a clearer product experience — exploring what the MVP could look like, how the ecosystem could connect, and where design could create the most value early on.
One Paw Away wanted to bring food, services, and community together in one place for pet parents. The vision was exciting, but broad. The founding team needed to see the product concretely before committing engineering time to an MVP.
Give the idea structure before building it — map the core experience and define the MVP first.
I helped give the idea structure — mapping the core experience, simplifying the journey, and exploring the product through early concepts and prototypes. Working directly with the CEO and CTO kept decisions fast, and the four-person dev team could react to concepts as they took shape.
Lay out the pet-care journey and where the product actually adds value.
Cut the vision down to the few things an MVP has to do well.
Turn the direction into screens the team could see and pressure-test.
Direct CEO and CTO collaboration to lock the MVP scope.
Vet-approved recipes with no preservatives, recommended per pet.
Find and book trusted grooming, vet and care services nearby.
A place for pet parents to share, learn and grow together.
One hub instead of separate apps for food, services and community.
Concept screens for the MVP — enough fidelity for the founding team and the four developers to see the product, react to it, and build against a direction rather than a brief.
The food journey carried the most product value early — a subscription model, pet-size guidance, and recipes that read like real meals, not SKUs.
Around food sat everything else a pet parent needs — a services grid, a pet forum, a photo feed (Pawgraphy), and articles surfaced from the home screen.
Everything tied back to two profiles — the pet parent and the pet — and a Missing flow for reporting and finding lost pets in the community.
A clearer product direction and a tangible starting point for turning the startup vision into an MVP. The founding team walked away with the core experience mapped, the MVP scoped, and concept screens to build against.
"The value early on wasn't polish — it was turning a broad idea into something the team could actually build."
