Product and UX content
The content model is the product decision
When the same information has to exist in two forms, deciding how it is stored settles what the product can do — long before anyone writes an interface.
Content people are usually handed a schema and asked to fill it. By then most of the interesting decisions have been made. What a field can hold, what has to be duplicated, what can only be derived — those decide what the interface is capable of, and they are made before anyone writes a screen.
The clearest example I have is my own. DriveTrain is a study app for the Russian driving-theory exam, and its whole reason to exist is that the same question has to be readable in two languages.
Two ways to build the same thing
There are two obvious ways to make a bilingual study app, and both are wrong.
Translate the interface. Buttons, menus, and settings become English. The questions stay in Russian. The learner still cannot read the thing they came for.
Translate the content. The questions become English. Now the learner understands them, and arrives at the exam having never seen the Russian phrasing they will be marked on — including its legal vocabulary, which is the part that decides the answer.
Both of these are content decisions dressed up as translation projects. Neither touches the actual problem, which is that the learner needs both versions, against each other, at the moment they are answering.
What the model had to hold
So the model is not “a question, plus a translation”. It is one question record that carries both languages at once: the question text, all of its answer options, and its written explanation, in Russian and in English.
That is a heavier record. It is also the only version that lets the product do the one thing it exists to do.
Everything else follows from it:
- Switching language is a field swap, not a request. The other language is already in the record being displayed. That is why it is instant, why it works with no connection, and why it works inside a timed exam — where a network call would be unacceptable.
- Answers already given survive the switch. The answer is attached to the question, not to the language, so moving between them mid-question costs the learner nothing.
- Every option is translated individually. Theory questions are decided by the differences between options, so translating only the question stem would have looked complete and taught nothing.
- Every explanation exists in both languages, with no exceptions. An explanation the learner cannot read is not an explanation.
None of that is interface work. It is all consequences of where the words live.
The test that is really a content decision
The same thing happens with progress. “How much of this have I learned?” sounds like a number the interface displays. It is actually a definition, and there are several available.
Count every question ever answered correctly, and a lucky guess counts forever. Count questions answered correctly on the first attempt, and honest revision looks like failure. DriveTrain counts a question as known only if the most recent attempt was correct — so a guess that a later attempt contradicts stops counting, and the completion figure means something.
That single rule also produces the app’s most useful screen for free. If correctness is a property of the latest attempt, then the set of questions currently wrong is something the app already knows. It becomes a drill that fills itself and empties itself, and the learner is never asked to curate a revision list.
What to ask before the schema is fixed
The general version of this, for any product where the same thing has to exist in more than one form — languages, currencies, units, reading levels, regions:
- What has to be true at the same time, on the same screen?
- Which of these is stored, and which is derived? Anything derived can be wrong or slow at exactly the wrong moment.
- What does the user lose when they move between the forms?
- Which numbers are definitions rather than measurements, and who is choosing the definition?
Ask those while the schema is still a conversation. Afterwards, the answer to all four is “whatever the model allows”.
The full write-up of how DriveTrain works is on its product page.