Derivar los componentes necesarios de dos vistas del producto

Un sistema de diseño resulta más fácil de utilizar cuando su alcance inicial nace de tareas reales de la interfaz. Empiece por las vistas que el producto necesita de verdad. Una lista extensa de componentes posibles aún dice poco sobre qué variantes debe utilizar su equipo.

Registrar dos vistas y sus tareas

Un portal de clientes ficticio sirve de ejemplo desarrollado. En la lista de proyectos, los clientes deben reconocer y abrir un proyecto. En la vista de detalle, deben leer su estado y descargar documentos aprobados. Ambas vistas pertenecen al mismo producto, pero atienden tareas distintas.

Anote la finalidad, el contenido y los posibles estados de cada elemento visible. Un marco parecido no basta para justificar un componente compartido. También importa si coinciden el significado y el comportamiento.

Decidir la base compartida y las composiciones propias

La tarjeta de proyecto y la fila de archivo pueden compartir elementos básicos pequeños. No por ello deben convertirse en un mismo componente grande. Una excepción tiene sentido cuando una variante compartida dificulta innecesariamente comprender la tarea.

Completar una entrada concreta de la biblioteca

Para el indicador de estado, el ejemplo registra: uso en ambas vistas del proyecto; texto de estado procedente de los datos del proyecto; color solo como presentación adicional; ninguna acción de clic propia. Quedan pendientes los valores de estado necesarios y el tratamiento de las traducciones largas. Estas decisiones deben aclararse antes de la implementación, en vez de ocultarse tras valores de ejemplo arbitrarios.

Carbon describe los componentes como soluciones diseñadas y programadas para tareas concretas de interfaz. Aplique esta perspectiva también al elegir: documente conjuntamente finalidad, variantes y límites de un componente. Que un nombre exista en una biblioteca no basta como regla de uso.

Comprobar el alcance inicial en ambas vistas

Coloque primero los componentes elegidos en ambos diseños. Revise contenidos habituales y traducciones largas; en los elementos interactivos, compruebe también el uso del teclado y los cambios de estado. Anote la versión utilizada y las diferencias que se mantienen deliberadamente. El ejemplo ofrece un documento de trabajo, no una biblioteca ya implementada. El siguiente paso es una selección manejable con los puntos pendientes aclarados que el equipo pueda implementar y probar después.

Fuentes

• Carbon: Components Overview