How I thought it through — from the buyer's question to a working system.

I started with the person on the other side of the screen. A nursing program director with approval for a simulation lab — four Med-Surg stations, twenty-four students.

They know exactly what they need to teach. What they don't know is product names — and nobody starts with a SKU.

Then I looked at the other side. The catalog speaks its own language — category, brand, attribute, SKU — and it has to.

One “hospital bed” is forty variants; a diagnostic set can be pieces sold separately.

Neither side is wrong. They just don't speak the same language.

And that's the gap I decided to work on: there is no translator between teaching words and catalog words. When search can't translate, the buyer hits a dead end — and a dead end is invisible; no error, no report.

I checked two misspelled searches on the public site and got no suggestions. Two checks is a hypothesis, not a finding — but it's exactly the kind you test with real search logs.

Then I asked myself why this matters. Because this buyer isn't one sale — one question carries a whole lab, and the next cohort after it.

I modeled the shape of that order, and I labeled every number as modeled, because the point is the stakes, not a revenue claim.

So what could fix this? I considered the obvious answers.

A full redesign? Expensive, risky, and unnecessary — the company's website already works. A bigger search engine? A tool doesn't know your buyers' words. Doing nothing? The dead ends stay invisible.

That's when it clicked: this is not a technology failure. It's an ownership gap — translation, data, page quality, fixes, and measurement each need someone running them, continuously. And that is a coordinator's job.

So my solution is not a redesign. It's a loop I would run every week as the coordinator: translate the buyer's words, fix the data behind the results, check the pages, hand precise tickets to the web team, and measure whether each change actually helped.

And for the deepest translation — the buyer's actual question — I designed Pathfinder, which starts from the room instead of the product. I'll show it in its own step.

And I didn't leave it as a diagram — I built every step of the loop as a working screen on my case-study site, each with its own address, like rooms in one building.

Search lives at Product discovery, where you type a query and see why each result ranked. Data lives at Catalog quality, where records are scored and the import runs. Page checks live at Website QA, in a register you can filter and export. The ticket lives at Developer handoff, where you can read T-003 exactly as the web team would receive it. And measurement lives at Reporting, where the KPIs and the funnel are defined.

Nothing is a mockup — every screen has buttons that do things. That matters, because a diagram shows what I think; a working system shows how I work.

Step one: translation. I built a synonym dictionary between buyer words and catalog words.

For example: “diagnostic kit” finds diagnostic sets, “med surg lab” finds medical-surgical simulation, and “vitals trainer” finds patient simulators — each pair works because I taught it to.

The system is real, and you can test it yourself: it's the Product discovery page on my case-study site, a working search I built on a 65-record sample of the company's public catalog — my own local demonstration, not the company's live engine.

And on the job, the dictionary isn't magic; it grows from real search logs, term by term.

I gave typos the same care, because real people type fast. Try “hosptial bed” — one letter out of place — and the search still finds the hospital beds instead of returning nothing; the result even tells you it treated “hosptial” as one edit away from “hospital.”

Then I went further: every result explains exactly why it ranked, with open scoring — an exact SKU match counts most, then an exact title, then brand, category, a typo-tolerant match, an applied synonym — each worth visible points. Search “BS029901” and the exact SKU jumps straight to the top; search “hosptial bed” and you can read which rules fired on each result.

Why does this matter? Because when ranking looks wrong, I can see which rule caused it, tune that one rule, and re-test before anything ships. A rule you can see is a rule you can tune safely — a black box gives you neither.

Step two: the data behind the results. Search can only find what a record contains — a thin title or a missing image is an invisible product.

So every record gets a completeness score out of 100, from a formula written in plain field names, not mystery numbers: Identity counts 25% — SKU, title, brand. Category and attributes count another 25%. Customer-facing content counts 20% — summary, price, image. SEO fields count 15% — meta title and description at the right lengths. Search merchandising counts 10% — aliases and a related product. And source freshness counts 5% — where the data came from, and when.

Add them up — that's the score. A record at 40 tells me exactly which parts are empty, and filling them is what moves it to 95.

New items enter the same disciplined way: a mapped, validated import that rejects duplicates at the door.

Step three: I check what the customer actually sees — content, links, images, titles, metadata, page by page. And I keep what I saw separate from what I think it means.

Here's a real example from my sixteen-page check. What I saw — just the fact: on three category pages, the meta description runs about 190 characters. What I think it means — the interpretation: search engines cut descriptions near 160, so those pages likely show up truncated.

One more. Seen: on the sampled pages, the first heading was “We Use Cookies” — the cookie banner, not the page title. Means: search engines and screen readers may read the cookie message as the page's topic.

The facts, nobody can argue with; the interpretations, we can debate and test. That separation is exactly why the register can be trusted — and acted on.

Step four. When I find a problem I can't fix myself — like that description text running too long — the fix belongs to the outside web team, because they own the page templates.

So I don't send an email saying “please fix the descriptions.” I write a ticket: a work order with four parts.

One, the evidence: here is the page, here is what I found, here is the date — nobody has to go searching. Two, what “done” means: those descriptions end up 160 characters or less. Three, how to check it: open these three pages and look at this exact spot. Four, who owns it.

Now the team reads it once and knows exactly what to do, how long it takes, and how to prove it's finished — no meeting, no chain of emails. A vague request costs days of back-and-forth; a precise ticket costs minutes. That's ticket T-003, and it's on the site, written out in full.

Step five: after a fix, how do I know it actually worked? Simple — decide what to count before the fix, so there is a before and an after.

I count three things. How many searches come back with nothing. How many people who search actually find and open a product. And how many of those go on to ask for a quote.

Take our week: we fixed “hosptial bed” on Monday. Next week I look — did empty searches go down? Did more people reach the bed pages? Did more quote requests come in? If yes, the fix worked. If not, I try the next thing — no guessing.

One honest note: the numbers on my site are practice numbers, clearly marked, there to show the screens working; on the real job, the company's real numbers replace them from day one.

Without counting, “I think it helped” is just an opinion. With counting, you know.

Now let me run the whole loop for you in one week, on one search term.

Monday, search: someone typed “hosptial bed” and got nothing — I add the typo rule and a synonym, and the search works.

Tuesday, data: the results now show me a bed with no image and half a description. That's a record problem, not a search problem — I complete it, forty to ninety-five.

Wednesday, QA: I check that product's category page the way a customer sees it, and its description text runs too long.

Thursday, ticket: the web team owns that template, so I write T-003 — evidence, acceptance criteria, QA steps, an owner.

Friday, measure: I watch the two numbers that tell the truth — how many searches still return nothing, and how many people go from searching to quoting.

One turn done. Monday, the next term. One search term pulled the entire loop through the week.

And here is Pathfinder — the tool that answers the buyer's exact question. Instead of asking them to search product names, it asks the questions a program director can actually answer: What skills will you teach? How many stations? How many students?

Then it does the translating for them: it builds one Med-Surg station from those answers, multiplies it by four, and sizes the supplies for twenty-four students — a shopping list organized by category, with a reason attached to every line.

Take the bed. Nobody wakes up wanting a specific bed model by name. They want students practicing safely at a bedside. Pathfinder knows a Med-Surg station needs a hospital-style bed at every station — so the list says: four beds, one per station, because learners rehearse positioning, rails, and bedside access.

The exact model gets chosen last, together with the educators. That's the whole idea: start from the room, end at the product — the way the buyer actually thinks.

Assumptions change, so I made the plan keep up — move the students, the stations, the budget, and it recalculates on the spot.

And I kept its output honest: a discussion list for nurse educators to confirm, never a clinical prescription.

The five-step habit isn't only for search — I used the same way of working on the rest of the job too.

Helping people find the company's website from Google: I wrote down what the pages say to search engines today — facts first — then my proposed improvements, clearly marked as proposals, plus three example ad campaigns whose budgets are practice numbers until real account data exists.

The trade show: same method — a plan that says who does what, by when, what it costs, and what happens with every lead after the show.

And underneath all of it, a sources page: every fact in this project carries a note saying where it came from and the date I saw it — so you never have to take my word for anything.

Same habits in every corner: look first, write it down, label the guesses, make it checkable.

Where did all this material come from? One place: the company's public website — the pages any customer can open in a browser. Product pages, category pages, the buying guides.

From those pages I copied sixty-five products into my own practice file — that's my sample. I picked sixteen of those pages and checked them one by one — that's the audit.

Then I put a label on every statement, so you know what kind of fact you're looking at.

Public: I saw it on their website, on this date. Bounded: I checked a few, not everything — a clue, not proof. Modeled: a practice number I created to make the screens work, clearly marked. Hypothesis: my educated guess, waiting for their real data to confirm or reject it.

I organized the website to be read in one order: Start here gives you the question and the method, the walkthrough tells the story in seven scenes, and then four working tools let you press the buttons yourself.

Everything else is supporting depth — open it when a question comes up.

And I mirrored all of it in Excel, because this role reports in Excel. Thirteen sheets, guided by the first tab: live lookups, counts, and cross-tabs — eight hundred sixty-five formula cells you can inspect — plus a native PivotTable.

Color shows what's source, what's calculated, and what's an assumption. Nothing hides.

One question, answered by a system — search, data, QA, ticket, measure. Then we ask the next question.