Guía de handoff para un diseño pixel perfect. Parte III

UI kits

Un UI kit es un inventario de todos los elementos que usas en un proyecto. Te ayuda a mantenerlo todo actualizado y facilita el mantenimiento cuando trabajas en equipo en proyectos grandes.

En un UI kit deberías reflejar los colores del proyecto, la tipografía, componentes como botones, campos de formulario y sliders, y sus distintos estados, como hover, active y default. Aplica el principio D.R.Y. ("Don't Repeat Yourself", no te repitas) para decidir si un elemento debe ir o no en el UI kit. Si tienes dos elementos parecidos en los artboards, lleva uno al UI kit. En los artboards de los diseñadores que no usan UI kits suele haber dos, tres o cuatro botones distintos con diferencias mínimas e irrelevantes. En esos casos, lo más probable es que el desarrollador los implemente todos en lugar de crear una única versión unificada.

Te recomendamos Craft para crear la librería de UI de tu proyecto. En proyectos más grandes, conviene tener una versión del UI kit en HTML y CSS y usarla como referencia para el resto de elementos.

Exportación

Facilítale la vida al desarrollador y aumenta las posibilidades de conseguir un diseño pixel perfect usando alguna de estas herramientas:

• Invision Inspect
• Zeplin
• Sympli
• Sketch Measure

Te ayudan a extraer de tu archivo de Sketch o PSD los colores, las fuentes, los tamaños, los assets, las distancias entre elementos, las propiedades CSS y mucho más. Invision y Zeplin, además, te permiten escribir notas sin obligarte a crear capas adicionales, como pasa en Photoshop.

Estados de los elementos

Para evitar malentendidos, te recomendamos usar una terminología concreta para los distintos estados de los elementos, igual que en CSS. Así los desarrolladores sabrán de qué hablas sin necesidad de dar demasiadas explicaciones.

• Default
• Hover: el estado del elemento cuando pasas el ratón por encima
• Active: el estado del elemento mientras se pulsa
• Focus: el estado del elemento seleccionado con el teclado o activado con el ratón (por ejemplo, campos de texto y áreas de texto)
• Visited: el estado de los enlaces que ya se han visitado

Line-height

El line-height es una parte muy importante del diseño y del proceso de handoff. Lo fundamental es entender cómo renderiza el navegador cada elemento y cómo le afecta el line-height. Fíjate en la imagen de abajo: es un ejemplo típico de un bloque de texto renderizado por un navegador. La altura del elemento coincide con el line-height, y la altura de los distintos caracteres no se corresponde con la del elemento en su conjunto.

Una ventaja de Sketch es que renderiza los objetos de texto con la misma lógica. En Photoshop, en cambio, el tamaño de los elementos no depende del line-height.

La buena práctica es usar un line-height coherente con las fuentes. No uses muchos line-heights distintos y personalizados en el sitio. Cada fuente tiene un line-height por defecto. Por ejemplo, Roboto tiene un line-height de 1,4 veces el tamaño de fuente: si el tamaño es de 16px, el line-height será de 22px. Aunque decidas no usar el valor por defecto, intenta mantener la misma proporción en todo el sitio. Los valores habituales van de 1,3 a 1,6 veces el tamaño de fuente. A los desarrolladores les encantará, porque prefieren definir un line-height global, olvidarse de él y trabajar solo con los tamaños de fuente.

Ahora, unas notas sobre cómo tratan los decimales los distintos navegadores. Partimos, por ejemplo, de estos valores:

• Tamaño de fuente: 36px
• Line-height: 1.4

Chrome, Safari y Opera: solo calculan valores enteros y truncan los decimales. 36px * 1.4 = 50.4, que se trunca a 50px.

Firefox: calcula con decimales. 36px * 1.4 = 50.4, y se queda en 50.4px. Si tienes dos líneas de texto como en el ejemplo de abajo, serán 100.8px. La principal diferencia con Safari y Chrome es que, si eliges un line-height como 1.41, en estos obtendrás 100px, mientras que en Firefox el contenedor medirá 101.533px.

La conclusión es que Firefox usa valores de line-height más precisos, como 1.33333. Si eso no te preocupa, quédate con números limpios y redondos, como 1.3.

Fuentes

Lo primero, intenta encontrar fuentes que te sirvan en Google Fonts. Los navegadores admiten distintos formatos de fuente, lo que significa que, para usar ciertas fuentes personalizadas, el desarrollador tendrá que prepararlas con servicios específicos que convierten ttf/otf a woff, woff2 o eot. En ese proceso, las fuentes pueden perder calidad. Así que mi recomendación es usar fuentes personalizadas solo si sabes que tus desarrolladores no van a fallar en el proceso. Tienen que saber trabajar con fuentes.

Un par de cosas que debes tener en cuenta al usar fuentes:

• No uses más de dos fuentes. Afecta al tiempo de carga de la página, sobre todo si son personalizadas.
• No uses demasiados tamaños ni estilos distintos (italic/bold/light/thin/regular).

Desarrolladores y diseñadores

A veces los diseñadores odian a los desarrolladores porque no son capaces de hacer realidad sus ideas, y a veces los desarrolladores odian a los diseñadores porque piden funcionalidades técnicamente difíciles de implementar. Estos problemas se resuelven con algo muy sencillo: hablando. Habla con tus desarrolladores, y no solo en la fase final. Comenta tus ideas antes de empezar a dibujar, porque descartar una idea en una fase temprana no es ningún drama. Si lo haces, es menos probable que el resultado te decepcione.

Creemos que siempre es posible que desarrolladores y diseñadores lleguen a un compromiso razonable y trabajen juntos de forma eficaz para reducir el coste y los plazos de sus proyectos.

Parte 1: software, nomenclatura, optimización de imágenes, sprites, SVG y favicon

Parte 2: retícula, diseño responsive, animaciones y prototipos