Tally: let the last answer decide the next question
Tally is a document-style online form builder for registrations, requirements and feedback. Conditional questions adapt to answers, helping each person provide the information their path needs before submitting.
Form your own approach first, then explore the reasoning to check trade-offs and validation you may have missed. There is no single right answer.
After changing attendance mode, what should the form keep and send?
Scenario
Design registration for a pottery workshop. People can attend in person or online; online attendance includes a mailed materials kit. This is an invented product exercise, not a recreation of Tally’s interface.
Conditions and goals
- Everyone provides a name, contact details and participation mode. In-person attendance needs a session but no delivery address. Online attendance needs a recipient, address and acknowledgment of delivery information, but no in-person session.
- Someone may choose online, complete the address and then switch to in-person. The final submission must contain only information needed by the current path; it must not silently send the old address.
- Decide whether to retain the address as a draft for switching back. Explain where it is stored, how long or under what conditions it is retained, and how the person can clear it. This is a draft policy to design, not an assumption that Tally automatically clears hidden answers.
- Identify missing required information on the active path. Hidden old fields must not leave someone unable to understand why submission is blocked. Support keyboard use and phone reading, and do not use an unexpected page jump to confirm submission on the person’s behalf.
Deliverables
Sketch initial selection, online entry, switching back to in-person, and final confirmation. Explain the relationship between visibility, requiredness, retained drafts and actual submission. Walk through “online address → in-person → online again,” stating what is retained or removed at each step. Design two observation tasks to check whether people can explain what will be sent. A complete visual design is unnecessary; do not invent test results.
Explore the reasoning
- List each path’s information needs. Separate common fields from branch fields. Session and delivery information belong to different paths. Put visibility, requiredness and submission in one state table rather than designing appearance alone.
- Separate draft values from submitted values. You could retain old values for the current page session, or clear them on switching and explain the consequence. Either way, the final submitted information contains only the active path. CSS hiding does not exclude data.
- Explain changes after switching. Say that this is now an in-person registration and the address will not be sent. When switching back online, explain whether a draft is restored or re-entry is needed. Do not promise deletion and then restore hidden cached data.
- Keep errors and focus with effective fields. Report only currently visible required fields that lack answers. Check focus and reading order when fields disappear during keyboard use. Keep explicit final submission confirmation.
- Test return-path understanding. Ask one person to enter an address, switch to in-person and explain the pending submission. In another task, switch back online and check whether restoration or clearing matches expectations. Improve explanations from observations, rather than checking only that buttons work.