Written by DROPS.ST.
Judge a mobile-first shop by whether someone can complete a defined task on a phone: identify the item, understand its unit, select the intended quantity, locate the order or explain a payment question. A narrow homepage screenshot cannot establish that the full path is usable.
DROPS gives these checks concrete product and order context. Its website and connected Telegram shop share the catalogue and order system; customer-linked items and configured BTC/XMR status identify what the team is reviewing. The same business selection can be inspected through the relevant phone views.
Demonstrate actual devices and contexts rather than promising speed, conversion improvement, automatic continuity or identical behaviour across every Telegram client.
Choose a task before measuring the layout
Write down what the person must find or explain. “Use the shop” is too broad. “Identify the quantity meaning before selecting two packs” gives the observer a concrete success condition.
For a returning buyer, test a familiar selection with a changed detail. This checks whether the screen makes the current facts clear instead of encouraging reliance on memory.
Include a help task. A usable product view can still lead to a confusing order reference, unreadable payment amount or an unclear support handoff later in the journey.
Record the device and observation
Telegram's Mini App design guidance recommends responsive screens, labelled interface elements and respect for areas occupied by device and client controls. These are design considerations, not proof that a particular storefront passes them. Telegram: Mini App design guidance.
Use this original task sheet with fictional or approved demonstration data. Record the phone/browser or Telegram client, view context and check time above it.
| Task | Evidence to observe | Issue to record |
|---|---|---|
| Identify an item | Name, unit and relevant detail visible together | Similar items cannot be distinguished |
| Select a quantity | Control and quantity meaning understandable | Label or keyboard hides the intended action |
| Review a selection | Current lines and pricing basis readable | Important information is clipped or overlooked |
| Correct a field | Error identifies the problem and supported next step | Person cannot find what to change |
| Navigate back | Expected supported view appears | Context or selection changes without explanation |
| Read payment status | Relevant asset, amount and order reference distinguishable | State or reference cannot be carried into help |
| Ask for help | Supported route and exact order question | The person must guess where the case goes |
Observe the action, not just whether the page loaded. A control can be visible yet difficult to identify; a long reference can be present yet impossible to distinguish from nearby text.
Test ordinary conditions and interruptions
Inspect the relevant phone orientation, text size and keyboard state. In Telegram, check that client controls do not obscure the task. Include the supported external-web view when it is part of the proposed journey.
Keep loading observations specific to the checked case and device. Do not turn one demonstration into a universal performance claim or a timing guarantee.
Record what happens when the person goes back, closes a view or returns to an existing question. Use the Mini App boundary sheet for session-state questions; this task sheet records the visible difficulty the person encounters.
Hypothetical example: an error hidden by the keyboard
In a fictional demonstration, a required field fails validation. The person can see the submit control but cannot see the error while the phone keyboard is open.
The observer records the field, keyboard state, view and expected next action. The issue is not labelled “checkout is slow”; it is described as an error explanation obscured in that context.
After an authorised correction, the same task is checked again in the affected view. A different product page is not evidence that the original problem was resolved.
This example illustrates observation and rechecking, not a live checkout test or a conversion result.
Prioritise difficulties by the affected decision
Start with problems that prevent understanding the item, quantity, order state or next action. Keep cosmetic refinements separate from an unclear commercial selection or an inaccessible help path.
Assign one owner and a specific recheck for each important issue. Avoid changing several unrelated fields merely because they appeared in the same screenshot.
Use the checkout evidence grid when the visible task also needs an order-record check. Use consistent product descriptions when the problem is the underlying fact rather than the layout.
For a returning customer, the Telegram shop guide helps distinguish a new order from an existing-order question. A small screen does not make those tasks interchangeable.
Evaluate the phone journey with DROPS
Choose DROPS when common product and customer-order context should support both the web and connected Telegram phone journey. Its identifiable records give the observer a concrete task to check rather than a visual impression alone.
Explore the DROPS demos using one product task, one error scenario and one order-status question. Record the device and actual result without sending messages, submitting a real order or funding payment. Choose the setup whose relevant tasks your team can demonstrate and support.