Plan
Path sketch
Sketch the beginning, interruption, and return of a small journey. Keep the sketch rough enough that the question remains more important than the drawing.
A product fieldbook for mobile releases
Turn a small mobile release into evidence you can use.
Qelavuno is a practical way to notice what changed, record how it was checked, and carry the useful questions into the next build.
For people shaping, checking, and learning from mobile work. No account or upload is required on this site.
Fieldbook principleCapture the decision beside the check.
Small releases deserve a clear trail, not a larger ceremony.
Use short observations, dated checks, and specific next questions. The aim is clarity for the team, not a score, forecast, or promise about a release.
01 / Release lane
Four handoffs that leave useful traces.
A release can stay small while its learning loop becomes more deliberate. Give every handoff one observable question and one place to write what you saw.
01 / FrameName the smallest behavior being released.
02 / ExerciseTry it on a real device and relevant setting.
03 / ObserveWrite what worked, confused, or needs follow-up.
04 / CarryChoose the one question to take forward.
02 / Build stamps
Make the check legible before the memory fades.
Build stamps are tiny, repeatable notes. They identify the moment, the device or condition, and the observation without pretending that one pass represents every person or context.
A
Change namedWhat behavior was intentionally different?
B
Context keptWhich device, setting, assistive tool, or network condition mattered?
C
Next question carriedWhat would be worth checking again with more people or another build?
03 / Choose a route
Start with the kind of uncertainty you actually have.
These routes are working prompts, not rigid workflow claims. Select one to reveal a focused fieldbook page.
Device reality
Check the smallest released path on the device categories and operating conditions that matter to your audience. Record the build, a short path description, and anything that is surprising enough to change a follow-up check.
Access path
Try the path with relevant accessibility features, text sizes, contrast needs, and input methods in mind. Treat each observation as an invitation to test more carefully, rather than as a declaration that access has been solved.
Message clarity
Place two concise variants beside the same task and note where their purpose diverges. Avoid reading a single review as proof; use the comparison to write better questions for the next conversation or moderated test.
04 / Split-testing ledger
A comparison is a record of conditions, not a verdict.
Keep one small ledger when testing variants. It makes it easier to separate a change you made from a condition you noticed, while leaving room for uncertainty.
| Field | Write beside it |
|---|---|
| Question | What is being compared? |
| Constant | What stays intentionally the same? |
| Observation | What did the review reveal? |
| Next pass | What needs a better check? |
A field ledger supports discussion; it does not establish a promised product, performance, or outcome.
05 / Field cards
Pick a card for the next useful conversation.
Filter the cards by the kind of work in front of you. Each one is a small prompt for observation and discussion.
Showing all field cards.
Check
Access pass
Try one assistive setting or sensory consideration at a time, then record the point where context changes the experience.
Review
Variant note
Describe the difference between two approaches in ordinary language before discussing why one may invite a different response.
Plan
Release edge
Write where this release begins and ends. A clear edge makes it easier to recognise which feedback belongs to this change.
Check
Context switch
Repeat the same small action after changing one relevant condition, such as text size, connection, device, or input method.
Review
Decision replay
Replay the moment a team chose a direction. Note what evidence was present, what was assumed, and what is still untested.
Before a small release
Use a short list that respects the work.
These marks stay only in the page while you are using it. They are not sent, scored, or used to make promises about a release.
07 / Responsible account and number guidance
Treat virtual-number questions as a policy and safety topic.
A virtual number may be subject to platform rules, regional regulation, identity safeguards, and account recovery risks. This fieldbook does not sell access, provide codes, teach evasion, recommend bypassing policy, or support impersonation.
- Read the service’s current policies before choosing a contact method.
- Use truthful ownership and consent practices for any account or communication flow.
- Keep recovery information and security decisions in your own authorised records.
- When in doubt, seek official support or qualified advice rather than workarounds.
An educational outline for PPC role preparation, not a vacancy notice or an employer claim.
08 / PPC role field note
Prepare for a PPC conversation with evidence, not promises.
This is an informational job-description lens for people exploring paid media work. It does not announce a live opening, represent an employer, or imply any hiring result.
- Capability focus: explain how you frame a campaign question, audience, creative idea, measurement limitation, and learning cycle.
- Interview preparation: bring anonymised examples of decisions, trade-offs, and what you would revisit with more time or data.
- Responsible practice: discuss consent, targeting boundaries, accessible creative, and clear reporting language.
09 / Questions in the margin
The fieldbook is most useful when the answers stay honest.
Open a question to read the practical boundary around each prompt.
No. A fieldbook can help a team document assumptions, device checks, and questions before or between deeper research activities. It cannot stand in for inclusive recruitment, consent-based studies, accessibility assessment by relevant people, or the careful interpretation that comes from listening to participants in context.
A useful release note names the change, the path that was exercised, the conditions that may matter, and one short observation. It should also preserve uncertainty: note what was not checked, what needs another device or perspective, and which next question would genuinely affect the next decision.
Treat a comparison as a record of a question and its conditions, not as a universal claim about people or product outcomes. Keep the difference understandable, document relevant context, avoid overstating a small sample, and use the observation to decide whether a more appropriate test or conversation is needed.
No. The form below is browser-only. When its required fields are completed, it prepares a local draft using your browser’s storage when available, and then clearly confirms that nothing was transmitted. It is intended for personal note-taking, not for messaging, support requests, submissions, or external contact.
10 / Contact note
Prepare a local note for your own fieldbook.
This browser-only form stores or prepares a local draft on this device when your browser permits it. It sends nothing anywhere, and it is not a channel for external contact.
Carry the useful question
A release becomes evidence when the next decision can see it.
Qelavuno keeps the artefacts small: a lane, a stamp, a ledger, and an honest margin note.
Need to revisit a note?
Return to the browser-only contact note area to prepare another local draft. It remains a local tool and does not send information.
Go to Contact note