Context: This article anonymizes a September 1, 2026 attempt to file a Japanese moving-out notification from an Android phone. It is not an attack on a specific municipality. The experience is compared with official Digital Agency information, documented incidents, and public form-design guidance. Names, addresses, destination, municipality, and exact device model are removed.
1. It waited until everything was entered, then died at the final step
The first My Number Card read worked. The second read worked. The form accepted the moving details. At that point the service looked exactly like digital government is supposed to look: no trip to an office, no paper, no queue.
Then came the final identity check before submission.
That read alone would not work.
The message said, in effect, that card reading had taken too long and the user should resume. The absurd part was the timing: the error appeared in well under a second. It did not feel as if the system had waited too long. It felt as if only the timeout had access to faster-than-light travel.
The worst part was not merely the error. It was where the error lived: after all the input, at the point where the user believed the job was finished.
2. Five card positions, roughly fifteen attempts, then the whole process again: about thirty reads
The obvious first suspect was card placement. The phone was tried high, low, centered, shifted left and right — roughly five positions. The final read was retried around fifteen times.
Then the entire procedure was restarted and attempted again. Same ending. In total, the user became a person whose main public-service activity was holding a plastic card against a phone about thirty times.
At that point, “try moving the card slightly” stops being an adequate diagnosis. The card also worked in other real-world readers, and the first two reads inside this very procedure had already succeeded.
Placement can never be ruled out with mathematical certainty, but the evidence clearly justifies looking beyond placement alone.
3. Why reads one and two can work while read three fails
To the user, all three actions look identical: touch the card to the phone. Behind the screen, they are not necessarily the same transaction.
Mynaportal’s official FAQ describes separate operations in the moving one-stop flow: login, reading name and address data, and attaching a signature to the application.[1] The Digital Agency likewise describes the new Myna App as supporting login authentication, reading basic information, and applying electronic signatures.[2]
So the same physical gesture can enter different software paths.
That means “the first read worked, therefore the third must be the same” is a false assumption. If reads one and two succeed while the signature read fails, a broken card is only one of several possible explanations; app handoff, signature processing, state management, device compatibility, or other software layers may also matter.
4. Late August 2026 was almost comically bad timing
The surrounding calendar matters.
- August 25: the new Myna App launched, integrating functions previously split across older government apps.[2]
- August 26: Mynaportal officially recorded an incident from about 16:00 to 21:30 in which an error at the final signature stage prevented applications from being submitted.[3]
- August 27: the Android app was updated with fixes for problems including startup crashes on some devices and repeated device authentication that blocked progress.[4]
- August 28 update: the Japan Pension Service warned that some Android devices could hit errors when moving into the Myna App and reading a My Number Card during its online application flow.[5]
- September 1: this Android moving-out attempt repeatedly failed only at the final read.
The Pension Service problem is not proof that the moving-out failure had the same root cause. They are not identical services. But it is legitimate context: official Android/app-transition/card-reading failures existed on a closely related path immediately after the new app launch.
The accident calendar is simply too neat to ignore.
5. “Reading may take more than five seconds” versus an error in under one second
Another Japanese government online-application guide notes that smartphone reading of a My Number Card can take more than five seconds and tells users to keep the phone and card in contact until reading completes.[6] Mynaportal’s Android guidance similarly tells users to place the card at the phone’s contactless reading area and hold it still.[7]
Fine. Users can wait five seconds. They can wait ten.
But they cannot follow “keep waiting” instructions when the application declares failure almost instantly.
That mismatch raises a useful diagnostic possibility: perhaps the failure happened before a normal NFC reading timeout — during app handoff, signature initialization, session state, or another earlier stage — and the user-facing layer collapsed several causes into one generic “reading took too long” message.
The exact cause cannot be proven from outside the system. The UX problem can: the message did not tell the user what action could actually change the outcome.
It was a speed quiz where only the buzzer was fast.
6. Is everyone else able to do it? — not a total outage, but real incidents existed
There is no basis for claiming that Mynaportal was universally broken and nobody could submit a moving-out notification. Many users clearly complete the process successfully.
But the opposite extreme is also wrong. Official sources documented Android-specific reading errors, app crashes, repeated authentication problems, and a Mynaportal final-signature incident during the same launch window.[5][3][4]
The best description is therefore: not a universal outage, but a period in which device- and path-specific failures were demonstrably possible.
From the user’s perspective, the outcome remains wonderfully terrible: use an online service designed to remove the city-office trip, spend time filling the form, perform around thirty NFC attempts, and then decide to visit the office anyway.
Digital government successfully generated a longer route to analog government.
7. The worst UX was not “an error happened”; it was “the error happened at maximum cost”
No complex system can promise zero failures. NFC hardware varies. Phones vary. Authentication and signatures are complicated.
What a service can control is the cost of failure.
For long forms, public design systems emphasize preserving user input, supporting save-and-resume when appropriate, and clearly distinguishing user mistakes from service problems.[8][9] General usability guidance likewise stresses error prevention and useful recovery information.[10]
The painful sequence here was:
enter everything → reach final authentication → instant failure → “resume” → no meaningful explanation of what to change.
That is not merely an NFC problem. It is a recovery-design problem.
8. The minimum fixes do not require futuristic AI
The useful improvements are boring, which is good.
- Offer an early signature-capability check. Before a long form, verify that the device can reach the final signing path.
- Autosave the entered form. A failed signature should not threaten the previous work.
- Separate error categories. No NFC detection, card authentication failure, app-handoff failure, and signature failure should not all look identical when the system can distinguish them.
- Do not answer an instant software failure with placement advice alone. The timing itself is diagnostic information.
- After repeated failures, provide an escalation screen. App version, restart, alternate device, known incident, or in-person route should be visible in one place.
- Connect known incidents to the transaction screen. Users should not have to excavate a government FAQ after the form collapses.
And after attempt fifteen, the application could honestly display:
“You have tried enough. We should stop pretending this is only your card placement.”
9. Then came the health check: please do not schedule an administrative stress test before blood-pressure measurement
The comic final detail was timing: a health check was next.
Japanese Society of Hypertension guidance recommends a quiet seated rest before office blood-pressure measurement and avoiding conversation during measurement.[11] Stress and measurement conditions can affect short-term readings; this does not mean Mynaportal “causes hypertension.”
It means that thirty failed NFC retries are an exceptionally stupid warm-up for a blood-pressure check.
The intended result of online administration: less travel and less waiting.
The actual sequence that morning:
- Fill out an online form.
- Retry NFC about thirty times.
- Get angry.
- Decide to visit the office anyway.
- Go get blood pressure measured.
If the only digital deliverable is a temporary upward nudge in the measurement, the transformation has taken a wrong turn.
10. Conclusion: not digital transformation, but a digital detour
The funniest and most important detail is not “the card could not be read.”
It could be read. Twice. The form could be completed. Only the last step died.
That pattern naturally makes users blame themselves: maybe the position is wrong, maybe the case is wrong, maybe they moved too soon. Yet the launch-week record shows that Android and final-signature problems were real enough for multiple official notices.[2][5][3][4]
The exact root cause of one individual attempt remains unknown. The design lesson does not.
Online public services are not finished when they work in the happy path. They are finished when failure does not confiscate the user’s time.
If the promise is “skip the city office,” please delete the hidden route:
complete everything → die at final signature → thirty NFC attempts → city office anyway.
That is not digital transformation.
It is a digital detour.
Sources
- マイナポータル FAQ — 引越しワンストップサービスで必要なマイナンバーカード操作. Separately describes login, reading name/address information, and signature attachment faq.myna.go.jp
- デジタル庁 / Digital Agency — マイナアプリの案内・2026年8月25日の提供開始に関する公表資料. Functions include login authentication, basic-information reading, and electronic signatures digital.go.jp
- マイナポータル — 障害・メンテナンス情報. Records the August 26, 2026 incident in which an error during the final-signature stage prevented application submission for a period myna.go.jp
- Google Play — マイナアプリ更新情報（2026年8月27日）. Update notes included fixes for force-closing on some devices and repeated device authentication that could block progress play.google.com
- 日本年金機構 / Japan Pension Service — 2026年8月28日更新のAndroid・マイナアプリ読取エラー告知. States that some Android devices could encounter an error when transitioning to Myna App and reading a My Number Card in the relevant electronic-application path nenkin.go.jp
- 出入国在留管理庁 / Immigration Services Agency of Japan — オンライン申請Q&A. Notes that smartphone My Number Card reading can take more than five seconds and instructs users to maintain contact until completion moj.go.jp
- マイナポータル FAQ — Androidでのマイナンバーカード読取位置・保持方法 faq.myna.go.jp
- U.S. Web Design System — Complete a complex form / Progress easily. Guidance on reducing burden and supporting progress, including save-and-resume patterns where appropriate designsystem.digital.gov
- GOV.UK Design System — Error messages and service-problem pages. Guidance on useful error recovery, retaining entered values, and distinguishing service problems from user mistakes. https://design-system.service.gov.uk/patterns/problem-with-the-service-pages/ design-system.service.gov.uk
- Nielsen Norman Group — 10 Usability Heuristics for User Interface Design. Error prevention and useful recovery guidance nngroup.com
- 日本高血圧学会 / Japanese Society of Hypertension — 血圧測定に関する案内. Recommends a quiet seated rest before office measurement and avoiding conversation during measurement jpnsh.jp
