A passport photo tool sounds like a fairly small project.
Upload an image. Crop it. Prepare the background. Export the right dimensions.
Then someone uploads a perfectly reasonable photo, another country’s workflow handles it, and the India flow keeps asking them to retake it.
That’s a problem I’ve been working through while building ApprovaVisa, a tool for preparing passport and visa photos online.
Getting the image to process was only part of the work. The other part was making sure the person using the tool could understand what had happened.
“Please retake your photo” doesn’t explain much
From the user’s side, an unchanged preview and a repeated retake message look like a broken upload.
That’s a reasonable conclusion.
If processing stops, the interface needs to explain why. Is the source photo unsuitable? Is there a requirement the tool cannot meet? Did something fail during processing?
Those situations need different responses. Asking someone to keep uploading another photo won’t help if the problem is in the application.
This experience made me pay closer attention to the information we show when a workflow cannot continue. An error message should give someone a useful next step.
A specification change touches more than the backend
Updating a photo requirement sounds simple until you follow it through the product.
The details page explains the requirements. The processing flow applies them. The preview shows the result. The downloaded file needs to match what was promised.
If those parts disagree, the user has no easy way to know which one is correct.
While updating the India workflow, I had to think about those pieces together. Changing a dimension in one place is only useful if the rest of the experience follows it.
It also matters how we describe the result. A tool can prepare an image and check certain properties, but the receiving authority makes the final acceptance decision.
A working backend can still look broken
After the processing issue, we had a smaller but very visible problem.
The scanning interface had stage numbers, progress percentages, and preview controls overlapping on the image.
Each element had a purpose. Together, they were difficult to read.
This was happening at the exact moment someone wanted to inspect their photo and understand whether processing was going well.
The layout needed clearer spacing and predictable positions. The overlays could stay on the image, but they needed room to do their jobs.
It was a useful reminder: a successful backend response doesn’t automatically produce a clear user experience.
The transitions deserve more attention
I’m now looking more carefully at the moments between steps:
- Upload to processing.
- Processing to preview.
- Preview to download.
At each transition, the user should be able to answer a few questions:
- Did my photo actually change?
- What did the tool do?
- Is there anything I still need to check?
- What will I receive if I continue?
Those questions sound obvious when written down. They’re surprisingly easy to miss while concentrating on the processing code.
Where the project is now
ApprovaVisa lets users select their country and document type, upload a photo, and preview the prepared result before payment. Downloads include a digital photo and an A4 print sheet.
I’m continuing to improve the experience around that workflow, especially the explanations and previews.
Building it has reminded me that even a focused tool can carry complicated expectations. Someone isn’t just testing an image processor—they’re trying to finish an application and move on with their day.
Have you built something where the backend worked, but the interface made it look broken? What helped you spot the problem?
Top comments (1)
Lets gooo