Saltar al contenido principal

Estructura - UX dentro de escenas

Con el objetivo de contar con una arquitectura modular más clara, coherente y alineada al flujo de UX documentado por el área de Diseño en Figma, así como de mejorar la comunicación y el entendimiento entre áreas, se definió de manera conjunta una estructura y nomenclatura común para organizar, implementar y gestionar la UX dentro de los proyectos de Unity.

Esta definición busca funcionar como un lenguaje compartido entre Diseño y Programación, permitiendo que ambos equipos trabajen sobre una misma base conceptual, aunque desde perspectivas y responsabilidades distintas.

Puntos a considerar​

Cada disciplina involucrada (Diseño y Programación Unity) aborda los proyectos desde modelos mentales distintos, construidos a partir de su experiencia y forma de trabajo:

  • Diseño se enfoca en aspectos creativos y perceptuales, como comunicación visual, teoría del color, jerarquía, accesibilidad, psicología del usuario y flujos de UX.
  • Programación Unity se enfoca en la creatividad aplicada a la ingeniería de software, priorizando funcionalidad, reutilización, modularidad, mantenibilidad, escalabilidad y estabilidad técnica.

Ambas disciplinas son creativas, pero resuelven problemas diferentes y utilizan herramientas conceptuales distintas. Reconocer esta diferencia es clave para evitar malentendidos y fricción en el flujo de trabajo.

Diferencia de significado en términos compartidos​

Aunque existan términos aparentemente idénticos entre disciplinas como Módulo, su significado y alcance no siempre coinciden.

  • Para Diseño, un módulo puede representar una unidad visual o de UX (por ejemplo, un conjunto de componentes que forman una pantalla o sección).
  • Para Programación, un módulo representa una unidad lógica y técnica, con límites claros de responsabilidad, dependencias controladas y potencial reutilización en distintos contextos o proyectos.

Por esta razón, no es suficiente compartir el nombre de un concepto; es necesario definir explícitamente su significado dentro del contexto del proyecto y del motor (Unity), evitando asumir que ambas áreas interpretan lo mismo.

Sobre el uso de modelos teóricos como Atomic Design​

Modelos como Atomic Design funcionan como marcos teóricos para comprender la modularidad desde una perspectiva conceptual y visual. Su valor principal está en ayudar a pensar y comunicar estructuras, especialmente en diseño de interfaces.

Sin embargo, dentro del desarrollo de software, y particularmente en Unity, estos modelos no pueden aplicarse de forma literal ni tomarse como una arquitectura técnica válida por sí mismos.

Esto se debe a que:

  • No contemplan dependencias técnicas, ciclo de vida de objetos, performance, ni restricciones propias de Unity.
  • No definen responsabilidades de código, desacoplamiento, ni reglas de escalabilidad.
  • Su enfoque es descriptivo y conceptual, no operativo ni ingenieril.

Por lo tanto, estos modelos deben entenderse como referencias conceptuales, no como reglas estrictas de implementación. La arquitectura modular en Unity debe basarse en principios de ingeniería de software, adaptándose al flujo de UX definido por Diseño, pero sin comprometer la salud técnica del proyecto.

La siguiente estructura propuesta no busca imponer una forma de pensar sobre otra, sino crear un puente entre Diseño y Programación, donde:

  • Diseño puede reconocer cómo su UX se traduce a estructuras claras en Unity.
  • Programación puede implementar soluciones técnicas sólidas sin perder alineación con la intención de UX.

Alineación en la clasificación de elementos modulares​

En conjunto con el área de Diseño se creó la siguiente tabla de equivalencias que muestra la clasificación modular interna de cada área y los términos a usar para mejorar la comunicación:

DiseñoProgramación UnityComún
FoundationPropiedadPropiedad
AtomComponenteElemento
MoleculeMóduloFeature
SegmentPasos en una secuencia
User flowSecciónTemplate
Design systemSistemaSistema modular
ExperienceExperienciaApp

Regla mental compartida:

Diseño define la intención y la experiencia.

Unity define el comportamiento y la ejecución.

Ambos comparten el mismo nivel conceptual.

Estructura basada en Figma​

Para la creación de la UX en aplicaciones de XR Training solemos hacer uso del módulo Machine Manager, el cual permite crear flujos secuenciales con listas de pasos por completar.

Por organización, legibilidad de la escena y alineación con el área de Diseño, se organizarán los componentes State Machine, de la siguiente manera:

  • Como hijos del GameObject _MachineManager, tendrán que estar los GameObjects con componentes State Machine y cuyos nombres se basan en el nombre del segmento en Figma.

  • Dentro de cada componente State Machine, la nomenclatura de sus estados deberá basarse en el ID y la descripción de [PENDIENTE], siendo su estructura la siguiente: ID_Descripción.

  • En caso de que dentro de Unity, por practicidad interna, operativa o ingenieril basada en dependencias técnicas del elemento reutilizable (por ejemplo la arquitectura modular de un objeto grab) y/o la arquitectura del módulo Machine Manager, no se pueda tener un solo estado por [PENDIENTE], se podrá dividir en múltiples estados siempre y cuando se respete la siguiente nomenclatura y en las notas se especifique la razón:

    • ID+Letra del abecedario en mayúsculas_Descripción

    • Por ejemplo:

      • ID17A_Interaction with items
      • ID17B_Interaction with items

Ejemplo:

  • _MachineManager

    • SM_SegmentName

      • ID00_WelcomeUI
      • ID01_Start training

    • SM_SegmentName

      • ID00_Display instructions
      • ID01_Wait for user interaction
      • …
      • ID12_Display evaluation UI

    • SM_SegmentName

      • ID00_Load next level

Referencias:​

  • Nigel Cross – Designerly Ways of Knowing
  • Don Norman – The Design of Everyday Things
  • Robert C. Martin (Uncle Bob) – Clean Architecture

https://unity.com/resources/create-modular-game-architecture-scriptableobjects-unity-6