← Back to selected work Lowe’s · Enterprise commerce
Approving purchases
Simplifying purchase requests and approvals for business customers, with clearer states and faster decisions.
- Role
- Lead Product Designer
- Focus
- UX strategy · Research · Interaction design
- Case study
- 01 of 04
Lowe’s
01 01 · Overview
Giving business teams a clearer way to approve purchases.
The Lowe’s app brings inventory, order tracking, favorites, and loyalty benefits together for home-improvement customers and professionals.
The Buyer/Admin Purchase Request Flow focused on a specific moment: a buyer exceeds their company’s purchase limit and needs an administrator to review the order. The work connected commerce, loyalty, communications, and app teams around a centralized approvals experience.
02 · Definition
Requirements & scope
Must haveA focused administrator flow
- Notify administrators when a buyer submits a purchase request.
- Open a new Purchase Approvals List from the notification.
- Show every request and its current status, with sorting and filtering.
- Offer simple approve and deny actions for pending requests.
Nice to haveFaster entry points
- Surface pending approvals on the home page.
- Take users directly from a push notification to an individual request.
- Create a focused component for acting on a single purchase request.
Out of scopeKeep the release focused
- Completing the buyer’s final purchase after approval.
- Broader exploration outside the approval and denial journey.
- Unrelated changes to commerce, loyalty, or account management.
My role
Lead the experience from problem framing through validation.
Stakeholder and user interviewsPersonas, scenarios, and journey mappingCompetitive analysis and information architectureLow- and high-fidelity prototypesUsability testing and design iteration
03 · Mapping
Building a shared view of the journey.
Mapping organized the structure, handoffs, and interactions before screens were designed.
I defined the admin and buyer roles, identified their key tasks, mapped touchpoints and emotional moments, and structured the information architecture around the decisions each person needed to make.
Experience goals
What a good experience needed to feel like.
01Transparency
Keep buyers informed about the status of every purchase request.
02Efficiency
Reduce time and effort with notifications and a centralized approvals list.
03Accessibility
Let administrators review and act wherever they are.
04Simplicity
Use clear language and focused approve or deny actions.
05Prompt action
Help administrators respond quickly to pending requests.
BuyerStay within budget and keep work moving.
The buyer needs to understand the company limit, submit an order for approval when necessary, and return to complete the purchase once it is approved.
AdministratorProtect budgets without slowing the team down.
The administrator reviews requests, checks details against organizational policy, and approves or denies spending with confidence.
04 · Sketching
Exploring both sides of the approval.
Early sketches helped the team examine entry points, onboarding, request statuses, errors, selection patterns, and the handoff back to the buyer before investing in polished UI.
Administrator flow
From notification to a confident decision.
Buyer flow
From purchase limit to order completion.
05 · Prototyping
Turning the mapped journey into something testable.
Prototypes made the complete handoff tangible and gave the team a fast way to validate assumptions.
Two connected experiences let participants embody both roles: the administrator reviewing the request and the buyer returning to finish an approved order.
Administrator prototype
Review, filter, inspect, approve.
Buyer prototype
Submit, track, return, complete.
06 · Testing
Testing the whole experience, not just individual screens.
ObjectiveEvaluate clarity and usability across both roles.
Give administrators the ability to accept or reject purchase requests in the app while helping buyers understand what happens before and after approval.
Method15 unmoderated participants
Pro Lowe’s shoppers completed the experience as both Buyer and Administrator through two connected prototypes, thinking aloud throughout the flow.
Core tasksSubmit → review → approve → complete
Participants submitted a request over a $1,000 limit, acted on the administrator notification, filtered and reviewed requests, then returned as the buyer to finish the order.
Research findings
What we learned
Feedback revealed where notification patterns, terminology, status visibility, and the route back to an approved order needed to work harder.
07 · Final design
Refining the experience around user feedback.
The final interactive prototype translated the research into a clearer system of notifications, statuses, filters, request details, and actions.
Iteration focused on helping users always understand whose action was required, what state a request was in, and where to go next.