Nombres

Un buen nombre

Para que un nombre sea efectivo, tiene que cumplir con ciertas características básicas: ser reconocible y hacer que sea posible identificar a lo que está haciendo referencia. Aún cuando parezca buena idea dejar a ese grupo como "Copy 23", invertir unos pocos segundos en poner un nombre decente después de crear algo, ayudará a aumentar la velocidad y el orden en el proceso de diseño. Así que, más allá de dónde se use, ¿cómo debería ser un nombre?

Tiene una estructura lógica

Two examples, a button and an input field, on top of each other

Es importante usar algún tipo de lógica para construir el nombre, algo que sea predecible y que se mantenga siempre igual -- y que no cambie seguido dependiendo de la situación. Quizás esto es aún más importante en los componentes, que generalmente tienen una estructura compleja.

No tiene relación con propiedades visuales

Two different ways of naming headings, showing good and bad practices

Está lógica que hemos mencionado antes quiere decir usar el contexto, la función y la jerarquía como partes del nombre. Pero no las propiedades visuales, que podrían cambiar a lo largo del tiempo, haciendo que el nombre pierda sentido. Si nombras algo basándote en su color o el radio de las esquinas, el nombre dejará de ser útil cuando esas cosas cambien. Pero, como siempre, hay excepciones que veremos más adelante.

Es corto, pero significativo

The top example provides a button with a long name, and below it a good, shorter name

En los componentes, seguir una estructura lógica nos suele hacer acabar con nombres largos. Pero una vez que estamos usando una instancia (es decir, la copia de ese componente y no el original editable) podemos simplificar el nombre para reducirlo lo más posible. Esto hará que la lista de capas sea más fácil de escanear de un solo vistazo. La parte importante de todo esto es que, por hacer algo más corto, no sacrifiquemos el propósito del nombre de poder identificar a lo que se refiere.

Es corto y todo el mundo lo conoce

¿Sabías que "Cheers" es el bar donde todos saben tu nombre? En un equipo, la convención de nombres debería ser conocida, acordada y usada por todos sus miembros. No puede pasar que de proyecto en proyecto y diseñador en diseñador (o incluso dentro del mismo producto) hayan distintas formas de nombrar la cosas.

The top part shows a card with a name in Spanish, and the one in the bottom it's in English

Una pequeña nota: si tienes un equipo distribuido o con diseñadores internacionales, lo mejor es usar nombres en inglés. Esto hará que tus archivos sean más fáciles de entender, independientemente de dónde esté la otra persona.

Tamaños

Una interfaz está llena de tamaños diferentes, desde textos a breakpoints o espacios entre elementos. La forma más fácil y escalable se relaciona con los tamaños de ropa que usamos en el mundo real. Es un concepto universal ampliamente entendido. De lo más pequeño a lo más grande, sería algo como esto:

A scale of colour boxes shows how sizes can be named in a gradually increasing way
xs = Extra small
sm = Small
md = Medium
lg = Large
xl = Extra large
2xl = Extra, extra large

Opcionalmente, podríamos usar "xxl" en lugar de "2xl", pero encuentro que cuando los tamaños empiezan a crecer, se compromete la legibilidad si no usamos los números y dejamos solamente las "x".

Hay otras formas de nombrar a los tamaños. Algunas de ellas se refieren a animales o usan otro tipo de analogías. Esto me parece divertido, pero en algunos casos no queda tan claro qué es más grande que qué, por lo tanto la utilidad de tales sistemas es un poco limitada (sin contar que también son complicadas de ampliar). Sólo como un ejemplo, esto es lo que quiero decir (de nuevo de más pequeño a más grande):

mouse
rabbit
dog
horse
elephant
whale

Colores

Como regla general, y tal como pasa con otras cosas, intentamos no referirnos a colores en particular (por ejemplo, "yellow") sino que preferimos la función o el contexto en su lugar. Si esto no es posible o suficiente, podemos referirnos primero a propiedades visuales más amplias (como "light" o "dark") y finalmente usar algo más concreto si es que ayuda.

Categorías

Los colores principales en una interfaz se pueden agrupar en “Primary”, “Secondary” y “Highlight”, dependiendo de dónde se usan y cuál es su función. La función debería ser consistente y coherente a lo largo de un producto.

An interface with some primary, secondary and highlight colours pointed in the design
  • Primary se usa para los elementos con interacción, como botones y enlaces.
  • Secondary es un color complementario en el sentido de que se usa para contrastar con el Primary, por ejemplo, para un botón secundario que no tiene que destacarse tanto.
  • Highlight, por otro lado, se usa para llamar la atención en algunos elementos en particular que tiene un rol importante, como un botón de enviar al final de un formulario. También se puede usar para indicar elementos activos, como una pestaña seleccionada.

Además de estos, hay más categorías que pueden tener una existencia más utilitaria, como por ejemplo:

Neutrals
Backgrounds
Opacities
Shadows
Icons
Texts

Paleta de colores

Generalmente no tenemos sólo un tono de los colores de Primary o Secondary. Muchas veces usamos una paleta con una selección más amplia de opciones claras y oscuras, por lo habitual creadas a partir de una base, que se usan para los estados de Hover, ítems deshabilitados, y más.

A colour scale shows a base colour and divisions in darker and lighter shades

En esos casos, nombramos al color base como "00": por ejemplo, "Primary / 00". Para cualquiera de las opciones más claras u oscuras, generamos una escala de unos 10 pasos, y numeramos cada color dependiendo de su posición en esa escala. De esa forma, en la última posición estarán los colores más claros y más oscuros de sus respectivas escalas.

Primary / 00
Primary / Dark / 10
Primary / Dark / 20
Primary / Dark / 30
Primary / Dark / 50
Primary / Light / 10
Primary / Light / 20
Primary / Light / 30
Primary / Light / 50

Generar todos los pasos es importante para poder hacer referencia a las posiciones. Claramente, no es necesario usar todas ellas en nuestra escala. Podemos omitir algunas, aquellas que no consideremos que vayamos a usar, como las que no tienen (de momento) una aplicación real en el diseño de nuestra interfaz.

Grupos y capas

Las capas deben ser nombradas de la forma más simple y limpia para facilitar su lectura. Cuando la capa es un símbolo o la instancia de un componente, el nombre debería reemplazarse por una versión simplificada.

The top example shows layers with original, long names -- the bottom example shows a cleaner list of names

Dentro de un componente o grupo, las capas deben reflejar la función que realizan (algo que a veces será igual independientemente de su contenido) -- y no deben estar afectadas por el contenido en sí mismo.

The list ont top has layers named after its contend, and the good example below it show more generic names

Las capas deben ser fáciles de leer, pero también fáciles de identificar. Por lo tanto, en algunos casos podría ser necesario un sufijo para separar un elemento de otro, y fácilmente entender de qué se trata con sólo darle un vistazo rápido. Esto es especialmente útil cuando tenemos dos capas del mismo tipo una al lado de la otra.

A card with thow buttons, using a hyphen to better specify the function of its buttons

Componentes

Los nombres de los componentes irán de lo más general a lo más particular, indicando primero el contenido y función, y después sus variantes y estados. Una forma de ver esto en la práctica es:

Componente / Función o jerarquía / Variante / Estado

Usando un ejemplo más gráfico, podríamos tener algo como esto:

Button / Secondary / Compact / Enabled

Esto podría extenderse en componentes más complejos, aquellos que al mismo tiempo incluyen otros componentes anidados. Como regla general, priorizamos la función y contexto sobre las variantes y particularidades de comportamiento.

A design of an empty state, showing an illustration on top, a text in the middle and a button below it