Find out which customer is struggling before specifying the repair

“Customers cannot send us their artwork” sounds like a request to rebuild an upload form. It may describe several different journeys. A returning customer may already have an approved file on record, while a new customer needs instructions about formats and a way to explain an unfinished idea.

The first project conversation should establish which person, entry point and attempted task the evidence actually concerns. Otherwise a team can spend a meeting designing the wrong form.

Reconstruct the entry path

Imagine a print studio receiving enquiries through a Costa Rica website. Its owner brings three safely redacted examples and assumes that the upload tool is failing. In two examples, first-time visitors entered through a campaign page whose main button says “Send your artwork.” Neither visitor had final artwork. The third is a repeat customer asking to reuse a previous design.

The upload endpoint accepts an appropriate fictional test file. That result does not prove that every device or file works, but it changes the immediate question. The first two people need a route for discussing preparation; the third needs to identify earlier work. Replacing the uploader would leave those decisions unexplained.

Record the actual page and button used, what the visitor had available and what they thought would happen next. Ask staff to show how they answered the enquiry. A campaign screenshot without its destination cannot establish the entire path.

Keep observations separate from explanations

Useful meeting notes distinguish “visitor had no final file” from “upload is broken.” They distinguish “customer asked to reuse an earlier job” from “customer failed to attach artwork.” Both statements can sound similar in a complaint summary while requiring different work.

Find the person who decides what the studio accepts: a finished design, source material requiring preparation, or an approved repeat. Confirm the information needed for each. The developer should not invent a print-production policy or promise that any file can be made usable.

Language review belongs here too. Compare the approved English and Spanish explanation of each path, including its eventual staff response. A translation that makes an exploratory request sound like a production-ready order changes the business commitment.

Use one bounded first test

In the fictional review, the team proposes three clearly described routes: discuss artwork preparation, provide a finished file, and reference an earlier job. The first accepts an explanation without pretending that a file exists. The repeat route requests a safe previous-job reference and leaves staff to verify it. The finished-file route retains the working upload capability.

Across the original enquiries and a separate finished-file control, each person can now choose a path that matches their starting point. Staff receive enough context to assess the next step. The existing finished-file control still reaches the same upload process; it has not been removed to simplify the demonstration.

This is evidence for a content and intake change, not proof that upload performance never needs attention. Preserve any genuine file-error reports as a separate investigation with their own reproducible conditions.

Leave with a usable decision

The meeting should finish with the proposed first scope, the person approving production terminology, the languages requiring review and the evidence needed to accept the result. Note what remains unknown: supported formats, preparation fees, access to older jobs or provider constraints may require further investigation.

Do not send private artwork, customer records or credentials in a general enquiry. A public link and a fictional reconstruction are enough to begin. An appropriate review method can be agreed if protected material is necessary later.

Prepare the project scope or describe the difficult customer task.