Optimizing Mobile Text Input and Information Expression
Text rules should be defined by the task the content performs—not by the field name or component style.
The Lincoln Way is Lincoln’s mobile application for vehicle status, community communication, related purchases, and official owner services. In August 2022, I worked as the sole UX designer within the external partner’s scope, covering requirements analysis, competitive research, text-rule definition, interaction design, and design specifications. The client product lead reviewed and approved the work.
RoleSole UX Designer · external partner
DurationApproximately one month
ScopeResearch · rules · interaction · specifications
The seven primary screenshots show the application’s current shipped experience. Some details differ from the August 2022 delivery; they therefore evidence observable tasks and states, while authorship is limited to the confirmed responsibilities, rules, and implementation scope.
Controlled short text
Name · nickname
Short, concentrated rules, low editing cost
Should invalid input be prevented, and how should the exact rule be explained?
Structured unique identifier
VIN
One answer, strict length and character set
How can input accuracy and final validation be improved?
Open long text
Post body
No single answer, high user investment, shared allowances
Should excess content be preserved, and how should state, consequence, and recovery be expressed?
Six cross-context dimensions
- Content structure
- Length and editing cost
- Answer certainty
- Downstream visibility
- Failure consequence
- Cross-object coupling
Open long text requires a recoverable interaction model
Long text carries substantial user effort. When content exceeds the limit, the interface should preserve that effort, identify the affected allowance, explain the publishing consequence, and restore the valid state coherently.
One visible character is not a naturally consistent implementation unit
The current application reproducibly counts Chinese characters, Latin letters, digits, and spaces as one; line breaks as zero; and different emoji as two, three, or four. Without engineering evidence, the implementation cause remains unknown. The specification must connect the complete chain rather than infer an encoding model.
- 01Perceived symbolWhat the user understands as one character
- 02Visible UI countWhat changes the number shown in the interface
- 03Input limitWhat marks or prevents overflow
- 04Submission validationWhat the client accepts as valid
- 05Service and storageWhat the system preserves
- 06Redisplay and editingWhether the same content returns with the same count
| Input | Visible count increase | Evidence status |
|---|---|---|
| Chinese · Latin · digit | +1 each | Reproducible |
| Space · line break | +1 · +0 | Reproducible |
| 😀 | +2 | Reproducible |
| 👍🏽 | +3 | Reproducible |
| 🇨🇳 | +4 | Reproducible |
| Tested family / profession sequence | +2 | Exact sample and field remain TODO |
Four feedback states define the recovery loop
The model distinguishes normal entry, early warning, invalid overflow, and the return to a valid publishing state.
Normal
Keep the count low-emphasis so expression remains primary.
Approaching
Increase emphasis before the boundary is reached.
Over limit
Preserve content while identifying excess, consequence, and affected object.
Recovered
Restore count color, explanation, and publishing state together.
The shared body/topic allowance is confirmed. The design issue is whether people can predict the topic’s cost before selection and understand how to recover afterward.
The same maximum does not imply the same rule
Name permits Chinese and Latin letters and remains private. Nickname also allows underscore and serves as the public identity. Invalid nickname input disables Save; valid input produces a success toast and exits the page.
Name and nickname share one profile surface and the same numeric limit, while serving different identity responsibilities.
The confirmed rule allows Chinese and Latin letters, so “widisj” should be valid. The current error indicates a mismatch between the rule and implementation.
Nickname allows up to 14 units and underscore, but the combined message does not identify which rule is currently violated.
Because short text carries little editing investment, input beyond the maximum can be prevented instead of preserving overflow. A repairable error should identify whether length or character rules failed, state the consequence, and explain the next valid action.
The current nickname field still permits input beyond 14 units. The defined rule and final implementation must therefore be reported separately.
A unique identifier requires specialized treatment
A VIN has one correct answer, a fixed length, and a controlled character set. Its priority is not a persistent 0/17 counter, but accurate transcription, normalized input, clear progression, and final validation.
Accept exactly 17 uppercase Latin letters or digits; capitalize letters automatically; prevent illegal and excess input; disable progression while incomplete; and perform final validation on confirmation.
The VIN rules and interaction were within my confirmed delivery scope. The exact scan-failure feedback remains unresolved and is excluded from the public conclusion.
From page-level cases to a text-rule decision tool
The tool standardizes the decision sequence—not one universal component: text archetype, cross-context dimensions, counting unit, input boundary, validation timing, error placement, recovery, and end-to-end testing.
| Decision dimension | Controlled short text | Structured unique identifier | Open long text |
|---|---|---|---|
| Current case | Name · nickname | VIN | Post body |
| Answer and structure | User-authored within rules | One answer with strict format | Free expression with no single answer |
| Editing cost | Low | Medium; transcription-sensitive | High; preserve authored content |
| Typical boundary | Length · allowed characters · visibility | Fixed length · character set · normalization | Total allowance · shared objects · publishing state |
| Overflow strategy | Prevent and explain specifically | Prevent illegal or excess input; validate submission | Preserve content; prevent invalid publishing; support recovery |
| Feedback priority | Failed rule and repair | Scan · find · format · confirmation | State · affected object · consequence · recovery |
| QA boundary | Chinese · Latin · symbols · button state | 17 units · case · scan · illegal input | Chinese · Latin · emoji · topic · paste · line break · recovery |
A measurement plan—not claimed post-launch results
As an external partner, I did not retain access to production analytics after delivery. The following measures define how the interaction should be evaluated; they are not presented as achieved outcomes.
| Text type / scenario | Priority measures | Validation question |
|---|---|---|
| Controlled short text | First-save success · rule recognition · repeated errors | Can people identify the violated rule and repair it immediately? |
| VIN | First-entry success · completion time · scan adoption · validation failures | Do specialized input and help reduce transcription cost? |
| Open long text | Overflow incidence · recovery rate · recovery time · abandonment | Do preserved content and state feedback support recovery? |
| Body + topic | Shared-allowance comprehension · topic-add failures | Do people understand that a topic consumes body allowance? |
| Multilingual / emoji | Rule prediction · front-end/back-end boundary consistency | Do user understanding and implementation validation remain aligned? |
The outcome was not a collection of field limits, but a method for deciding text structure, counting boundaries, input constraints, validation, and recovery.