Form design often appears simple on the surface, yet even the smallest visual decisions can significantly influence usability. During a recent form redesign exercise, a seemingly straightforward question emerged:
"Should every mandatory field include a red asterisk (*)?
At first glance, the answer seemed obvious. Established UX research provides clear guidance on how required fields should be indicated. But as the design process unfolded, real user behavior introduced a nuance that challenged the conventional approach.
What began as a routine design decision ultimately became a valuable reminder of how UX principles, real data, and product context must work together to shape effective design decisions.
When UX Principles Suggest Minimalism
Many widely accepted UX guidelines recommend marking only optional fields when most form inputs are required. This recommendation is frequently discussed by organizations such as Nielsen Norman Group and is supported by concepts from Cognitive Load Theory.
The reasoning behind this approach is straightforward. When users interact with a form:
- fewer visual elements improve scanning speed
- cleaner layouts reduce cognitive effort
- less visual noise helps users focus on completing tasks
This idea also aligns with the principle of maintaining a strong signal-to-noise ratio in interface design, where important information should stand out without being buried in unnecessary visual indicators. Under this logic, marking only the exceptions (optional fields) keeps the interface clean while allowing users to assume that the remaining fields are required.
Based on these principles, the initial design adopted this minimal indicator approach.

However, real product data soon introduced a different perspective.
When Real User Behavior Challenges Theory
The client shared insights from multiple applications within their ecosystem. Despite clear validation messages, users frequently submitted forms with missing required fields.
This pattern suggested that something within the interface was failing to clearly communicate expectations, especially for users encountering the system for the first time.
Interestingly, internal analytics indicated that forms with stronger visual indicators for mandatory inputs produced fewer submission errors.
This observation raised an important question:
"Could a design pattern that theoretically reduces cognitive load actually introduce confusion in a specific product context?
To investigate further, two versions of the same form were created.
Testing Two Design Approaches
Two form variations were tested to understand how users interacted with different visual indicators.
Version A – Minimal Indicator Approach
- Only optional fields were marked
- The layout remained visually clean
Version B – Mandatory Indicator Approach
- Every required field included a red asterisk (*)
- Mandatory inputs were visually emphasized

The results revealed an interesting behavioral divide.
Users new to the system
Users who were unfamiliar with the interface completed Version B more accurately.
The mandatory markers acted as visual anchors, quickly guiding their attention toward the fields that required action. Instead of scanning the entire form to infer requirements, users could rely on clear visual cues.
This behavior also aligns with Jakob’s Law, which suggests that users rely on familiar design patterns they have encountered across other digital products. Because asterisks are widely used indicators of required fields, new users instinctively recognized their meaning.
Frequent users of the system
Frequent users displayed a different pattern. They completed the minimal Version A slightly faster.
Over time, experienced users develop visual scanning shortcuts based on familiarity with the interface. When additional markers appear next to every field, the interface becomes visually denser, interrupting these established scanning patterns.
This subtle slowdown can also be explained through Hick’s Law, which states that increasing the number of visual elements can increase the time required to process information and make decisions.
Even though experienced users eventually adapt to new visual patterns, additional interface elements still introduce a small but persistent processing cost.
Balancing Principles with Context
Rather than declaring one approach universally correct, the final design decision focused on context and user needs.
Forms that were complex or used by users with varying levels of familiarity benefited from explicit mandatory indicators. In these cases, clarity and error prevention outweighed the need for strict visual minimalism.
On the other hand, simpler forms used frequently by experienced users performed better with the cleaner approach of marking only optional fields.
The goal was not to follow a single rule rigidly, but to apply the most appropriate pattern based on how the interface was actually being used.

Design Takeaways
This small design experiment highlighted several important lessons:
- UX principles provide valuable guidance, but they must always be validated against real user behavior.
- Clear visual indicators can reduce errors for users who are unfamiliar with a system.
- Minimal visual patterns often improve efficiency for experienced users.
- Even small UI elements can influence scanning patterns and interaction speed.
- Testing design assumptions with real usage data leads to stronger product decisions.
The Bigger Lesson
Design principles exist for a reason. They capture years of research, experimentation, and shared knowledge within the design community.
However, the most effective UX decisions rarely emerge from principles alone. They occur at the intersection of:
- established research and design laws
- real user behavior
- the specific context of a product
Great design is not simply about following every rule. It is about understanding when a rule serves the user, and when adapting it leads to a better experience.
In practice, UX maturity often reveals itself not in how strictly principles are applied, but in how thoughtfully they are interpreted.
A shorter version of this article was originally published on the Think Forge Global blog.
