Jodie Barr
Product Designer
Turning a fragmented home improvement trip into one connected project
A trip-based system that unifies planning, in-store navigation, and project completion. An experience designed to reduce failed trips, lower reliance on store associates, and increase project completion for DIY and Pro users.
Role
Product Designer
Scope
Connected feature system
Type
Concept
How I Approached This
This was concept exploration. What informed it: product knowledge from cross-functional work, along with store behavior and past user research and user intent. What I didn't have was dedicated user interviews, prototype usability testing, or metrics to size the opportunity. Ideally, those would be the first additions.
The Problem
Home improvement projects fall apart before the user gets to the register. Deterioration starts in the gaps between planning and shopping. Customers are managing materials, time, and store logistics across multiple tools, conversations and trips. Currently these are treated as separate tasks. Lack of connection between project tools and information creates friction for users. Customers end up integrating this themselves which often times leads to extra shopping trips and time lost. I focused on this experience holistically and recognized it as a layered process that starts before the user steps foot in a store.
A trip is a process comprised of multiple steps, not just an endpoint.
Fragmented planning
Materials scattered across notes, past purchases, and memory. No single place to assemble a project.
Inefficient trips
Time lost locating items and finding associates. Missing items create return trips.
Disjointed Execution
The plan doesn't follow the customer into the store. Lists stop being useful once shopping starts.
What I did
I explored two directions. The first direction was additive, I focused on creating new features on top of the existing architecture. The second was connective, realizing the existing features as steps in an overall flow rather than separate destinations with isolated intentions. The connective approach serviced the user throughout their entire journey while still being useful individually, I chose this approach. Building new features on a fragmented foundation would have maximized the problem, not solved it. I explored each phase (Plan, Prepare, Execute) with the goal of reducing friction before and during the trip. Does this problem exist because it was not addressed in a prior step? That question became the filter for the design decisions in the system
The Experience
PLAN
Planning a project
Transforms scattered ideas into a structured, actionable plan. Start from existing lists, past purchases, or from scratch.
- Start from existing lists, past purchases, or from scratch.
- Continue planning across multiple sessions.
- Surface relevant items based on project type
PREPARE
From list to project manager
Surfaces constraints before the trip so that friction is resolved at home, not at the shelf.
- Real-time availability and substitutions prevent failed trips
- Cost estimates + scheduling offered upfront, not discovered in store
- Captures questions in advance to reduce reliance on associates
EXECUTE
Live checklist & guided shopping in real time
Turns the project plan into an active, in-store companion. The list adapts to where they are in their journey.
- Item mapping reduces time spent navigating aisles
- Availability alerts prevent surprises at the shelf
- Progress tracking keeps users aligned across team trips
Tradeoffs & Decisions
DIY & Pro considerations
Rather than designing two separate experiences, I prioritized a structured but flexible system. DIY users get a clean checklist. Pro users get a project manager. Same foundation, different levels of depth. Future Pro features would be informed by DIY learnings.
In-Store Execution vs. Preparation
Instead of solely focusing on in-store navigation I opted to also strengthen pre-trip planning. This would help to eliminate friction before high-impact moments rather than solving it in store.
Scope vs. Feasibility
Constraints meant focusing on scalable solutions rather than over optimizing individual features. The goal was to create a solution that could evolve.
Concept vs. Research Timeline
This was informed by product knowledge and user behavior, not dedicated user research. Formal research investment would have painted a clearer picture and filled in
knowledge gaps.
Tradeoffs & Decisions
If I picked this up again as a scoped and fully funded project, this is what I would have done differently:
01
Start with dedicated user research
The user journey and system proposed are aligned with our user's mental models. However, there are assumptions about user behavior at each phase that need validation. Identifying exact moment where the current experience breaks down is essential.
02
Prototype testing for the planning phase
The prepare and execution phases are intuitive. However the planning phase holds the most assumptions. Prototyping would surface friction points as well as and existing gaps or opportunities for improvement with this solution.
03
An explicit handoff document
System-level solutions are risk of breaking down over time if changes are made to isolated features without consideration or understanding of the overall intent. A design brief that captures the rationale between behind the phases and users changing needs ensure that we maintain the integrity or build upon the design.
Additional Screens
