Password
Case study • Relex solutions • Enterprise SAAS
Merchandise
Financial Planning
I was the first designer on a team building a new enterprise merchandise financial planning product. Over twelve weeks I helped the team rebuild a shared understanding of what we were making, made the case that won leadership's commitment to rebuild it on the right foundation, and shipped the pilot MVP as the only designer on the project.
Role
Senior designer, first on the team
Scope
Pilot MVP, 12-week build
Domain
Enterprise merchandise financial planning
Stack
Figma, Figma Make, Lovable, Claude Code
01 — THE SITUATION
The situation I walked into
Merchandise financial planning is how retailers plan a selling season before it starts and steer it once it's underway. Before the season, top-down financial targets for sales, margin, and inventory come down from leadership, and planners reconcile those targets against bottom-up forecasts built on last year's performance and category strategy. Once the season is live, they track actuals against the plan and adjust continuously. It's high-stakes, deeply analytical work, and for most planners the tool of choice is still Excel.
That was the bar I was designing against, and the team I joined was a long way from clearing it.
When I arrived, there was no designer, no design research, and no single agreed-upon picture of the product. There were two product managers, a few solution architects, and no dedicated engineers yet. Two pilot customers were already using an early version of MFP that had been assembled reactively, feature by feature, in response to specific customer requests, and built on top of a platform originally made for an adjacent purpose. That foundation worked against the product: planners expect their tool to do what Excel does, and the borrowed platform struggled to meet those expectations.
Two things happened right as I joined that raised the stakes. The lead product manager, who carried much of the team's domain knowledge, left. And three to four engineers joined who were new to merchandise financial planning. So at the exact moment the team was staffing up to build in earnest, the person who understood the domain best was gone, and most of the people who would build it were starting from zero.
There had been some discovery earlier, run by the PMs through focus groups and client workshops, but none of it had been done by designers or researchers, and none of it had been synthesized into anything the team could act on. There were several competing versions of the end-to-end process floating around, but no source of truth. No roadmap. No prioritized set of features. No working model for how the team would actually operate together.
The team didn't need more features. It needed a shared understanding of what it was building and why.
02 — ALIGNMENT
Building the first shared map
Before I designed a single screen, I made a map.
The team had several competing mental models of how merchandise financial planning actually works end to end, and no agreed-upon version. You can't design a product when the people building it don't share a picture of what it's for. So my first deliverable wasn't an interface. It was a service blueprint of the entire MFP lifecycle: seven phases from strategic planning through post-season review, across six actor roles, from executives and finance down to buyers, supply chain, and store operations.
Mapping it meant reconciling those competing versions into one. That forced the disagreements into the open and gave us a shared vocabulary for the first time. It became the team's single source of truth, the artifact we pointed to when we needed to locate a feature in the larger process, scope a release, or onboard someone new to the domain. For a group that had just lost its most knowledgeable member and added engineers new to the field, the map did something the team badly needed. It put what we collectively knew in one place, where everyone could see it.
03 — DISCOVERY
Driving real discovery
Discovery had technically happened before I arrived. The PMs had run focus groups and client workshops. But none of it had been led by a designer or researcher, and none of it had been synthesized into anything the team could act on. We had inputs, not insights.
So I built the research function the project didn't have. I drew on all of the existing discovery work, then went further: I authored a research plan and interview protocols and ran discovery interviews with merchandise financial planning subject matter experts with decades of combined experience. I synthesized everything into a prioritized findings report, the team's first real evidence base for what to build and why.
Those three insights pointed at the same thing. Planners didn't need another grid. They needed the tool to do the analytical heavy lifting that Excel makes them do by hand.
04 — VISION
The vision concept that helped make the case
The early MFP build had a structural problem the team kept running into. It was built on a platform made for an adjacent purpose, and certain features planners needed were either hard or impossible to deliver on that foundation. The team knew this. What it didn't have was a concrete, tangible picture of what the product could become if it were built right.
So I made one. I designed a high-fidelity vision concept for MFP, using generative AI tools to move fast: Figma Make to get wireframe concepts down quickly, Lovable to bring them to high fidelity, and Claude Code to build the concept in a working environment rather than a static mockup. The result wasn't a slide deck of screens. It was something close to a working product that people could react to.
The vision made the research tangible. It showed the dashboard surfacing priority exceptions instead of burying them in a grid. It showed the real-time impact of a plan change rendered visually, the moment you made it. It showed what the product could be when it wasn't fighting its own foundation.
We brought it to leadership across a series of meetings, walking through the benefits and demoing the concept directly. The decision to rebuild on the right platform rested on a few things together, including the technical constraints a replatform would unblock. My work was a major factor in getting it sold. The vision gave leadership something the case had been missing: a clear, credible picture of the payoff, concrete enough to believe in. By the end of those conversations, leadership was on board and greenlit the MVP build on the right foundation, on a twelve-week timeline.
Outcome
05 — NEW WORKING MODEL
Designing without a playbook
When anyone on the team can generate a working interface, what is the designer's job?
This project ran on tools that didn't exist in a stable form a year earlier. We were building with generative AI in the loop: Figma Make, Lovable, Claude Code. That meant the traditional product design model was, in a real sense, blown up.
Early on, while the team was still testing what the new platform could do, non-designers were generating UI directly. Most of it was functional, and that was the point of the experiment. But it wasn't built on our design system, it skipped our tokens, and the UX and craft weren't where they needed to be, the kinds of gaps an experienced eye catches in seconds. My approach was to separate the two things generation was conflating: the functionality was usually fine, but the design needed work. I'd say so plainly, then build the real version in my own branch.
As that testing phase wrapped, design ownership consolidated to me, and I started shaping what the working model should actually be: design in a branch, pushed for the team to review, iterated from there. There was no proven best practice to borrow. I was defining one as I went.
06 — SHIPPING
Shipping the MVP
With the platform decision made, I had twelve weeks to design the MVP as the only designer on the project.
The scope was deliberately tight. We took the core of the vision concept and cut it down to what a pilot customer needed to actually plan a season, with the rest sequenced for later releases. The MVP centered on two areas. The dashboard gave planners an at-a-glance read on plan health and surfaced priority items that needed attention, so they could see what was off without combing through the grid to find it. The workspace held the planning grid itself, where planners do the real work of building and adjusting a plan, along with the flow to submit a plan for approval. Around those, I designed the supporting machinery the product needed to function: a manager approval queue for reviewing and accepting or rejecting submitted plans, a setup flow for managers to define the fiscal calendar that every plan is built against, and plan creation with a choice of seeding method.
Some things from the vision didn't make the cut, and that was the right call. The AI-generated insights on the dashboard were deferred. So was the interactive KPI lens, where selecting a metric card reframes the entire dashboard around that metric. Both were strong ideas. Neither was essential to a pilot customer planning their first season in the tool, so they moved to later releases. Holding the line on what an MVP actually needs is part of the job.
The one piece I fought to keep was the impact panel.
On a twelve-week build, everything is a candidate to be cut, and the real-time impact panel in the workspace was one of them on scope grounds. I pushed to keep it, because the research had been clear about why it mattered. This was the exact gap Excel leaves open: when a planner changes an input, they can't see the downstream consequence without working it out by hand. The impact panel closed that gap, showing the effect of a change on the full balance set the moment it was made. It was the clearest answer the product had to the question of why a planner would leave their spreadsheet.
The research backed it directly. When a planner in our discovery sessions watched the impact visualization shift in real time as the numbers changed, her reaction was immediate. That was the differentiator talking. It stayed in scope, and it shipped.
At the end of the twelve weeks, the MVP was delivered for the pilot, designed start to finish by one designer, on a product that twelve weeks earlier had no shared definition of what it was.
07 — REFLECTION
What this work proved
I joined a team that was building fast without the things that make building work: no shared picture of the product, no synthesized research, no agreed-upon model of how the work should happen. Over twelve weeks, design became the function that supplied them. I gave the team its first shared map of the domain. I built the research function it didn't have and turned scattered inputs into an evidence base. I made the case, with a vision concept, that helped move the product onto the foundation it needed. Then I designed and shipped the MVP on that foundation, solo.
Design isn't only the screens. It's the shared understanding that lets a group of people build the same thing, and the judgment about what that thing should be.
The project also sat right on the front edge of how design work is changing. Generative tools are dissolving the old boundaries between who designs, who builds, and who decides, and the industry doesn't have a settled answer yet for what that means for craft and quality. That's a model I expect to keep refining, because it's where the field is going.