🚀 Welcome to MDriven Learn –  MDriven is now on Discord!  Don’t miss the latest Release Notes.
Usability guidelines for MDriven apps
This page was created by Wikiadmin on 2026-07-29. Last edited by Wikiadmin on 2026-07-29.

You can use these guidelines to make MDriven-generated application interfaces easier for end users to understand and operate; they are for developers designing MDriven Designer ViewModels and Turnkey user interfaces.

Make the current state visible

Show users what data they are looking at and whether that data is current. A universe of discourse is the set of records currently available in the interface.

For example, when a user filters a list of 400 retrieved records, make it clear that the filter works within those 400 records. Show the current scope and when it was last refreshed. A record added after the last refresh cannot appear in that scope.

Distinguish search from filtering

Make the interaction match the user's expectation:

  • For a filter that responds while the user types, give visible feedback that the list is changing.
  • For a search where users expect to finish entering terms, provide an explicit action to run the search.
  • Do not make users guess whether text changes the current list or starts a broader search.

Give feedback that explains what to do next

Use immediate feedback for field-level requirements and express it as the next action the user should take.

For example, for a vehicle identification number that must contain 17 characters, show a label such as VIN number too short while the value is incomplete. Update the feedback when the value becomes valid and when it becomes too long.

Use visual feedback to communicate meaning, not decoration. For example, use consistent row colors to show whether an item is overdue, on schedule, or between those states. Do not rely on color alone when the user also needs an explicit instruction or status.

Keep actions consistent and clear

Use the same presentation for the same kind of action throughout the application. Do not present one Save action as a link, another as a button, and another as navigation away from the current screen.

Separate navigation from operations that change data. Context-dependent actions should make their target clear. For example, place an action that applies to a selected row in that row's context menu rather than presenting it as an unrelated page-level action.

Be careful with double-click behavior. If the first available action on a row can delete data, double-clicking the row can produce an unexpected deletion. Make destructive operations distinct from navigation.

Make editing state understandable

Show whether the user is viewing data or editing persistent data. This helps users navigate without worrying that an accidental change will be saved.

For example, keep persistent values unavailable until the user enters edit mode. When an action is unavailable, decide deliberately whether to show it disabled or hide it:

Choice Use it when Example
Show a disabled action Users need to know that the operation exists, even though it is not currently available. Show an unavailable action so the user can recognize that it becomes available after entering edit mode.
Hide an action Showing the action would add noise and does not help the user understand the task. Hide actions that are not needed while the user is only navigating.

Use visual hierarchy to explain interaction

Do not use high-priority styling for every control. If an element expands content in place, make that behavior visible instead of making it look like a navigation button.

For example, present an expandable section as an accordion with an arrow or plus indicator. Reserve strong color and call-to-action styling for actions that require immediate attention.

Apply the guidance in your UI

Use UI & Styling Documentation when you implement layout, styling, fonts, themes, and web or desktop UI customization. Review each ViewModel with these questions:

  1. Can the user tell what records are in scope and when they were refreshed?
  2. Can the user tell whether text performs filtering or search?
  3. Does feedback state what the user should do next?
  4. Are navigation, editing, and destructive actions visibly different?
  5. Does styling communicate information and priority instead of adding visual noise?

Watch the UX discussion for examples of filtering, status feedback, consistent actions, and context-sensitive interaction.