Naming Conventions in Mobile Design

Establishing clear naming conventions in mobile design is crucial for maintaining an organized workflow, facilitating collaboration, and ensuring consistency across your project. Proper naming conventions help designers, developers, and other team members quickly understand the structure and purpose of design elements, making it easier to update, maintain, and scale the mobile app. Here’s a guide on how to approach naming conventions in mobile design, covering screens, components, assets, and classes.

1. Screen Naming Conventions

Screens are the fundamental units of mobile app design. Clear and consistent naming of screens ensures that the design and development teams can easily navigate and understand the flow of the app.

• Use Descriptive Names: Name screens based on their function or content. This makes it clear what each screen does or contains.

  • Example: LoginScreen, HomeScreen, ProfileScreen, SettingsScreen

• Indicate Hierarchy: If the app has a hierarchical structure, include the parent screen or section in the name.

  • Example: SettingsScreen/Notifications, ProfileScreen/Edit, DashboardScreen/Statistics

• State Variants: When a screen has different states (e.g., empty state, error state), include the state in the name.

  • Example: CartScreen/Empty, LoginScreen/Error, SearchScreen/Results

• Flow and Navigation: Reflect the user flow in the naming. For example, if there is a specific flow for onboarding, name the screens accordingly.

  • Example: OnboardingScreen/Step1, OnboardingScreen/Step2

2. Component Naming Conventions

Components are reusable elements in your design, such as buttons, cards, or input fields. Naming these components consistently helps in maintaining clarity and reusability.

• Use Hierarchical Naming: Name components hierarchically to indicate their relationship within the design system.

  • Example: Button/Primary, Button/Secondary, Card/Product, Input/Text

• State and Interaction Variants: For components that have multiple states or interactions, include these in the name.

  • Example: Button/Primary/Pressed, Input/Text/Focused, Checkbox/Checked

• Size Variants: If a component comes in different sizes, specify the size in the name.

  • Example: Button/Primary/Small, Button/Primary/Large, Icon/Search/Small

• Platform-Specific Components: If there are variations between iOS and Android, indicate the platform in the component name.

  • Example: Button/Primary/iOS, Button/Primary/Android

3. Asset Naming Conventions

Assets include images, icons, and other media used in your mobile app design. Consistent naming of assets ensures that they are easy to find and use.

• Descriptive Naming: Name assets based on their purpose or content.

  • Example: icon-search.svg, image-banner.png, avatar-default.jpg

• Resolution and Density: For mobile assets, it's crucial to include the resolution or pixel density in the name, especially for different screen densities (e.g., @1x, @2x, @3x).

  • Example: icon-search@2x.png, background@3x.jpg

• Platform-Specific Assets: If assets differ between iOS and Android, include the platform in the name.

  • Example: icon-home-ios.svg, icon-home-android.svg

• State Variants: For assets that change based on state (e.g., button icons), include the state in the name.

  • Example: icon-checkbox-checked.svg, icon-checkbox-unchecked.svg

4. Class Naming Conventions (CSS/HTML for Web-Based Mobile Apps)

For web-based mobile apps or hybrid apps, CSS class naming is crucial for styling and maintaining consistency.

• BEM Methodology: Use the BEM (Block, Element, Modifier) methodology for naming classes. This ensures that class names are structured and scalable.

  • Block: The main component or section (e.g., nav, button).

  • Element: A child element within a block, prefixed with a double underscore (__).

    • Example: nav__item, button__icon

  • Modifier: A variation of a block or element, prefixed with a double hyphen (--).

    • Example: button--primary, nav__item--active

• Platform-Specific Classes: For components that have different styles or behaviors on different platforms, include the platform in the class name.

  • Example: button--ios, button--android

• State-Specific Classes: Include the state in the class name when styling different states of an element.

  • Example: button--pressed, input--error, modal--open

5. Typography Naming

Typography should be consistent across the app. Naming your text styles properly helps maintain this consistency.

• Hierarchical Naming: Name text styles based on their hierarchy in the design.

  • Example: Heading/H1, Heading/H2, Body/Regular, Caption/Small

• Platform-Specific Text Styles: If typography differs between platforms, include the platform in the name.

  • Example: Heading/H1/iOS, Body/Regular/Android