IO app: explaining messages and reminders before download
An independent proposal for IO’s public website: make messages, deadlines and preferences easier to understand without pretending to redesign the native app.
Published · 10 September 2026Updated · 7 September 2026
00 · Premise
Explaining a feature is already part of the experience.
The starting point is IO’s public messages webpage, observed on 7 September 2026. I did not open an account or inspect personal messages. The question is narrow: can someone arriving in a browser understand the actions available in the app? This comparison concerns that informational entry point, not the usability of the native inbox.
UX Clinic · Real external case
From a download invitation to recognisable tasks.
Before shows the official page’s first viewport; the phone is IO’s published illustration, not my authenticated app session. After reorganises features described by the same source. It is an independent static website concept, not a modified release of IO.
Before · original website
After · independent proposal
Recognise the original page’s priority
The original has a distinctive identity, a direct heading and visible store links. It works as a product introduction and installation invitation. Reminders and communication preferences are explained further down, while the first viewport is dominated by the phone visual. This does not establish a universal problem; it may matter for visitors seeking a practical answer before downloading.
Practical actions
- Preserve identity and access to the stores.
- Distinguish feature exploration from installation intent.
Bring three tasks into one view
The proposal brings forward three units: reading communications, adding a reminder when a message has a deadline, and managing preferences. These are documented features, not invented capabilities. Their position and relative prominence change. Each block answers a different question without requiring visitors to interpret small interface text inside a promotional image.
Practical actions
- Use task-oriented verbs.
- Do not imply automatic reminders for every message.
Keep guidance separate from personal service access
The concept retains a download route and explicitly says that this page does not display personal messages. It adds no shortcut to an authenticated inbox: that would require checking deep links, sign-in and device behaviour. Deadline meaning also depends on the individual service. This revision proposes no universal rule for payments or formal notifications.
Practical actions
- Separate explanation from authenticated access.
- Verify app links before promising a direct hand-off.
Test understanding rather than clicks alone
I would compare both versions with people unfamiliar with IO, asking where they would manage a deadline or communication preferences. Correct expectations matter alongside download choices. The compact version sacrifices some visual impact: if it weakens recognition without improving understanding, a shorter summary alongside the existing visual may be preferable. Keyboard, contrast and mobile reading still need implementation-level checks.
Practical actions
- Compare correct expectations and misunderstandings.
- Do not claim conversion gains without measurement.
Ready to use
Before implementing a similar change
- All three functions match current documentation.
- The download route remains visible.
- The guide does not resemble a personal inbox.
- Reminders are not described as universal or automatic.
- Understanding is tested with real participants.
Hypothesis to validate
Make the value understandable before requesting installation.
This proposal does not fix an unobserved internal flow. It clarifies the relationship between documented features. Any benefit remains a hypothesis, with a real trade-off between visual impact and practical orientation.