Atomic Design

Machine Translated by Google
Diseño atómico
brad escarcha
Diseño atómico
brad escarcha
Tabla de contenido
1. Diseño de sistemas
Crea sistemas de diseño, no páginas 8
2. Metodología de Diseño Atómico
Átomos, moléculas, organismos, plantillas y páginas
38
3. Herramientas del oficio
Pattern Lab y las cualidades de las guías de estilo
efectivas 64
4. El flujo de trabajo atómico
Personas, procesos y hacer que los sistemas
de diseño sucedan 94
5. Mantenimiento de los sistemas de diseño
Hacer que los sistemas de diseño resistan la prueba del tiempo 142
Gracias y reconocimientos 182
Recursos 184
Sobre el Autor 191
Copyright © 2016 Brad Frost Todos los derechos reservados
Editor: Brad Frost
Corrector: Owen Gregory
Diseñadora de libros impresos: Rachel Arnold Sager
Diseñadora de libros electrónicos: Rachel Andrew
ISBN: 9780998296609
Creado con orgullo en Pittsburgh, Pensilvania.
Prefacio
Era 2013 y nos reuníamos con Brad Frost y Jennifer Brook alrededor de una mesa de cocina
iluminada por el sol en Brooklyn. Los cuatro acabábamos de comenzar a trabajar en un nuevo
sitio web para TechCrunch y estábamos dibujando esquemas en el departamento de Jennifer,
lidiando con las nuevas demandas del diseño receptivo. Brad sacó su computadora portátil: "He
estado jugando con una nueva idea".
La pantalla de Brad parecía como si una página web hubiera explotado. Fragmentos y piezas de
interfaz de usuario flotan libres unos de otros, sin ataduras por un diseño o jerarquía unificados.
Parecía un montón de piezas de repuesto de un garaje web.
Brad esbozó su sonrisa loca y asintió, "Genial, ¿verdad?" Los tres le devolvimos la mirada
sin comprender. Alguien tosió.
Y luego Brad Frost, el desarrollador de frontend, comenzó a hablar como Brad Frost, el
químico. Habló sobre átomos, moléculas y organismos, sobre cómo las grandes piezas de diseño
pueden dividirse en otras más pequeñas e incluso recombinarse en diferentes piezas grandes.
En lugar de visualizar la receta terminada para el diseño, en otras palabras, nos estaba mostrando
los ingredientes. Y nos iluminamos: este fue un cambio de perspectiva, una forma de alejarse de
concebir el diseño de un sitio web como una colección de plantillas de página estáticas y, en
cambio, como un sistema dinámico de componentes adaptables. Fue una forma inspirada de
abordar este sitio web receptivo, y todos los proyectos receptivos para el caso.
La nueva idea de Brad fue el diseño atómico y cambió la forma en que trabajamos en este
mundo asombrosamente multidispositivo. Al pensar en interfaces simultáneamente tanto en el
nivel grande (página) como en el nivel pequeño (atómico), simplificamos nuestro proceso:
introducimos un pensamiento más riguroso en el papel de cada elemento; caímos en hábitos que
mejoraron la consistencia de nuestro UX; y, lo que es más importante, comenzamos a trabajar
mucho más rápido y de manera más colaborativa. El diseño atómico era nuestro superpoder.
En las primeras etapas del rediseño de TechCrunch, hubo un momento en el que hablamos
sobre cómo queríamos que fuera la página del artículo. En una hora, Brad tenía una versión
totalmente receptiva cableada de su kit de piezas. Ese fue el momento en que nos dimos cuenta
de lo rápido que íbamos a poder movernos, un caso poderoso para invertir en este enfoque
inteligente y modular.
Casi cuatro años después, no hemos mirado atrás. Brad continuó refinando sus técnicas
y herramientas en los proyectos que siguieron,
6 DISEÑO ATÓMICO
incluyendo sitios de gran éxito para Entertainment Weekly y Time, Inc.
Hemos utilizado estas lecciones para ayudar a los equipos de productos
internos a crear sitios más rápidos y con mayor calidad, crear sistemas de
diseño masivos para organizaciones que buscan centralizar su trabajo de diseño
y desarrollo en todas las oficinas internacionales, y mucho más.
El diseño atómico nos dio velocidad, libertad creativa y flexibilidad.
Cambió todo. Creemos que también hará lo mismo por ti.
Este maravilloso libro explica la filosofía, la práctica y el mantenimiento
de los sistemas de diseño atómico. Y lo hace con la generosidad alegre y
servicial que tanto describe al propio Brad.
La energía y el gran entusiasmo de Brad por la web y sus creadores son
ilimitados. Durante años, Brad ha trabajado en la vanguardia de la técnica de
diseño receptivo y ha compartido todo a lo largo del camino. Su sitio This Is
Responsive es el recurso de referencia para encontrar soluciones receptivas a
cualquier problema de UX. Su blog y Twitter comparten sus obstáculos y sus
soluciones. Cuando los diseñadores y desarrolladores siguen a Brad Frost, obtienen
un flujo rápido y denso de conocimientos prácticos y apasionados para crear sitios
web hermosos y resistentes.
Este libro duplica todo eso.
Si tuviera la oportunidad, Brad llamaría a la puerta de cada diseñador y
desarrollador para entregar personalmente su mensaje. Hemos visto con
asombro (y leve envidia) cómo este derviche gira alrededor del mundo para
compartir sus consejos con cientos de equipos y organizaciones en los seis
continentes. (¡El diseño atómico, próximamente en la Antártida!) Pero incluso
Brad Frost no puede estar en todas partes a la vez, y estamos encantados de
que haya detallado sus ideas con tanta profundidad y buen humor en este libro.
El diseño atómico está explotando en todo el mundo; transformó nuestra
práctica de diseño; y estamos emocionados de que traiga la misma combustión
creativa a su proceso también.
Josh Clark y Dan Mall, Los colaboradores frecuentes de Brad y su
los más aficionados
ADELANTE 7
Capítulo 1
Diseño
Sistemas
Crea sistemas de diseño, no páginas
7 http://www.uie.com/articles/magic_escalator/
8 http://en.wikipedia.org/wiki/Scrum_%28software_development%29
8 DISEÑO ATÓMICO
Hace mucho, mucho tiempo, existían estas cosas llamadas libros.
¿Recuerdalos? Estos artilugios eran pesados y voluminosos y estaban hechos de
pulpa de árboles muertos. Dentro de estos libros había cosas llamadas páginas.
Les diste la vuelta y te cortaron los dedos.
cosas horribles Estoy tan contenta de que estos libros con sus páginas afiladas ya no
estén.
Oh espera…
Nuestro pasado paginado
La página ha estado con nosotros desde hace mucho tiempo. Unos cuantos
milenios, en realidad. Los primeros libros eran gruesas losas de arcilla creadas hace
unos 4000 años, pronto reemplazadas por pergaminos como la forma preferida de
consumir la palabra escrita. Y aunque la tecnología de lectura ha recorrido un largo
camino, desde el papiro hasta el pergamino, el libro de bolsillo y los píxeles, el concepto
de página se mantiene firme hasta el día de hoy.
La metáfora de la página se ha incorporado al léxico de la web desde el principio. Tim
BernersLee inventó la World Wide Web para que él, sus colegas del CERN y otros
académicos pudieran compartir y vincular fácilmente su mundo de documentos. Esta
génesis académica de la web, basada en documentos, es la razón por la que el
concepto de página está tan profundamente arraigado en el vocabulario de Internet.
¿Así que lo que?
Como discutiremos a lo largo de este libro, la forma en que se nombran las cosas
afecta en gran medida la forma en que se perciben y utilizan. Pensar en la web
como páginas tiene ramifcaciones reales sobre cómo las personas interactúan con
las experiencias web e influye en cómo creamos interfaces web.
Desde el principio, la metáfora de la página proporcionó a los usuarios un
lenguaje familiar con el que navegar en esta nueva y valiente World Wide Web.
Conceptos como marcadores y paginación ayudaron a los nuevos usuarios web a
explorar y finalmente dominar un medio completamente nuevo utilizando convenciones
con las que ya se sentían cómodos.
CAPÍTULO 1 / DISEÑO DE SISTEMAS 9
El navegador Chrome muestra el mensaje "Esta página web no está disponible".
La página era, y sigue siendo, una metáfora muy visible y útil para los usuarios de
la web. También tiene una profunda influencia sobre cómo se crean las experiencias
web.
En los primeros días de la web, las empresas que buscaban estar en línea simplemente
traducían sus materiales impresos a sus sitios web. Pero a pesar de que estos sitios
web de folletos ofrecían una perspectiva muy unidimensional de lo que la web podía
ofrecer, ver los sitios web como representaciones digitales de la página impresa era
fácil de entender para los creadores.
Pero ahora llevamos 25 años en este nuevo medio, y esta forma de
hablar que alguna vez fue necesaria se ha quedado más tiempo de lo esperado.
Desafortunadamente, la metáfora de la página sigue siendo profunda con
respecto a cómo analizamos y ejecutamos nuestros proyectos web. Aquí hay
algunos ejemplos que escucho regularmente:
“Somos una startup que busca lanzar un sitio web de cinco páginas
este octubre…”
“Brad, ¿cuánto tiempo llevará construir la página de inicio ?”
"¿Cómo vamos a rediseñar este sitio web de la universidad que contiene más de
30,000 páginas?"
10 DISEÑO ATÓMICO
Todas las afirmaciones anteriores cometen el error fundamental de
asumiendo que una página es una cosa uniforme, aislada y cuantificable. La
realidad es que la web es un medio fluido, interactivo e interdependiente. Tan
pronto como aceptamos este hecho, la noción de página se erosiona
rápidamente como un medio útil para alcanzar y crear experiencias web.
¿Cuánto tiempo llevará construir una página de inicio? Bueno, eso depende de lo
que contenga, ¿verdad? Tal vez la página de inicio simplemente consista en un
eslogan y una imagen de fondo, lo que significa que podría estar lista para el
almuerzo. O tal vez esté repleto de carruseles, formularios dinámicos e integraciones
de terceros. En ese caso, tal vez la página de inicio tarde varios meses en
completarse.
En cuanto al sitio web de la universidad de 30 000 páginas, podría ser tentador
declarar: “¿¡Miles de páginas!? ¡Vaya, eso suena desafiante!” Pero en realidad, esas
30.000 páginas pueden constar de tres tipos de contenido y dos diseños generales.
En última instancia, el nivel de esfuerzo de un proyecto está mucho mejor
determinado por la funcionalidad y los componentes. contenido dentro de esas
páginas, más que en la cantidad de páginas mismas.
La metáfora de la página ha cumplido su propósito de ayudar a los usuarios a
familiarizarse con la web y proporcionó a los creadores el lenguaje de transición
necesario con el que crear para un medio completamente nuevo.
Pero para construir interfaces bien pensadas destinadas a servir a una multitud de
dispositivos conectados, ha llegado el momento de que evolucionemos más allá de
la página.
rompiendo la pagina
Afortunadamente, la comunidad web está trabajando arduamente para
establecer principios y prácticas que nos ayuden a hablar y crear para la
web de manera efectiva. Y hay un concepto que sigue apareciendo en todas
las conversaciones sobre cómo crear experiencias web exitosas: la modularidad.
La modularidad es anterior a la web por mucho. La Revolución Industrial
trajo piezas intercambiables y la línea de montaje de Henry Ford transformó para
siempre la fabricación de automóviles.
proceso. Los primeros autos y componentes se fabricaron individualmente, lo que provocó
muchas pesadillas de seguridad y mantenimiento. Ford descompuso el automóvil en sus
componentes y modularizó el proceso de ensamblaje. Los resultados hablaron por sí solos:
automóviles más uniformes, más confiables y más seguros salieron de la fábrica y en un
tiempo récord para arrancar.
A medida que la era de las máquinas se convirtió en la era de las computadoras, los
informáticos comenzaron a practicar la programación orientada a objetos y establecieron
importantes conceptos modulares como la separación de preocupaciones y el principio de
responsabilidad única. De este mundo nació la World Wide Web, por lo que no sorprende
que el diseño modular rápidamente se convirtió en un principio de diseño para la arquitectura
de la web.
Lento pero seguro, estos conceptos se abrieron paso en los flujos de trabajo de los
diseñadores web. A principios de la década de 2000 vimos la introducción de bibliotecas como
YUI y la interfaz de usuario de jQuery que proporcionó a los desarrolladores un conjunto de
herramientas de widgets y patrones para crear interfaces de usuario más consistentes.
Si la modularidad ha existido durante tanto tiempo, ¿por qué estamos hablando de eso
ahora?
La respuesta corta es que la modularidad importa más que nunca. En este momento, toda
nuestra industria se está ahogando en un mar de dispositivos, tamaños de ventana gráfica
y entornos en línea. Y las cosas no se están desacelerando en el corto plazo.
La disrupción solo acelerará. La cantidad y diversidad de
dispositivos conectados , muchos de los cuales aún no hemos
imaginado, explotará, al igual que la cantidad y diversidad de
personas en todo el mundo que los usan. Nuestros estándares,
flujos de trabajo e infraestructura existentes no se mantendrán. La
avalancha actual de dispositivos ya los está llevando al límite. No
pueden soportar lo que viene.
El manifiesto FutureFriendly
12 DISEÑO ATÓMICO
Estos son solo algunos de los dispositivos conectados de los que debemos preocuparnos.
Nos guste o no, este universo multidispositivo es nuestra realidad. Ya fue bastante difícil
hacer que nuestras páginas web se muestren de manera consistente en un puñado de
navegadores de escritorio, pero ahora tenemos la tarea de garantizar que nuestras
experiencias web se vean y funcionen maravillosamente en una variedad vertiginosa de
teléfonos inteligentes, tabletas, phablets, netbooks, computadoras portátiles y computadoras
de escritorio. , televisores, consolas de juegos y más.
Para abordar esta realidad mientras mantenemos la cordura, es absolutamente necesario que
demos un paso atrás y dividamos estas gigantescas responsabilidades en partes más
pequeñas y manejables.
Y eso es exactamente lo que la gente está haciendo. El espíritu de la modularidad se está
abriendo paso en todos los aspectos del proceso de creación web y tiene efectos
profundos en la estrategia, el proceso, el contenido, el diseño y el desarrollo de las
organizaciones.
Una estrategia manejable
Todas las organizaciones finalmente se están dando cuenta de que demoler todo su sitio
web y reemplazarlo con un sitio web NewAndShiny™ cada tres u ocho años no es (y
nunca lo fue) una solución óptima.
¡Afuera con lo viejo! ¡Adelante con lo nuevo! Sin duda es una perspectiva
atractiva. Pero incluso antes de que se elimine el confeti de la fiesta de lanzamiento, las
llamadas comienzan a llegar. "¡Moviste mi queso!" lloran los usuarios, que pasaron años
aprendiendo la interfaz y la funcionalidad anterior.
Cuando se lanzan rediseños masivos con cambios signifcativos en la experiencia,
los usuarios quedan derribados en lo que Jared Spool llama la "escalera mecánica
mágica del conocimiento adquirido". Los grandes rediseños son una sacudida para
el sistema, y los nuevos usuarios frustrados tienen que gastar una gran cantidad de
tiempo y energía en volver a aprender la experiencia para volver a subir lentamente por
la escalera mecánica del conocimiento adquirido.
Además de desorientar a los usuarios, estos rediseños monolíticos no llegan a
la raíz organizativa del problema. Sin un cambio fundamental en el proceso, la
historia está destinada a repetirse, y lo que es NewAndShiny™ hoy se
convierte en OldAnd Crusty™ mañana. El ciclo se repite a medida que las
empresas impulsan actualizaciones menores hasta el próximo gran rediseño, lo que
finalmente las paraliza y frustra a los usuarios en el proceso.
Afortunadamente, incluso las organizaciones masivas están siguiendo el ejemplo del
mundo de las startups más pequeñas y esbeltas y se esfuerzan por sacar las cosas
por la puerta más rápido. Al crear productos mínimos viables y enviarlos con
frecuencia para mejorar la experiencia de manera iterativa, las organizaciones pueden
abordar mejor los comentarios de los usuarios y mantenerse al día con el panorama
web en constante cambio.
Alejarse de los rediseños al estilo de Ron Popeil, configurarlo y olvidarse
requiere cambios deliberados en la estructura organizativa y el flujo de trabajo. Lo
cual es mucho más fácil decirlo que hacerlo.
Un proceso iterativo
Si tuviera una cuarta parte por cada vez que escuché a una parte interesada declarar
"Estamos tratando de ser más ágiles", estaría orbitando la Tierra en mi nave espacial
privada en lugar de escribir este libro.
Querer ser más ágil es encomiable. Pero ágil es un término cargado, con grandes
diferencias entre mayúsculasA Agile y minúsculasa ágil. CapitalA Agile es una
metodología específca para el desarrollo de software, dotada de un manifiesto y marcos
complementarios como Scrum y delgado.
14 DISEÑO ATÓMICO
Minúsculas: ágil es más un deseo informal de crear un proceso eficiente. Este
deseo ciertamente puede implicar la adopción de principios generales de mayúsculaA Agile,
pero puede que no implique adoptar el proceso Agile en su totalidad. El gerente de proyecto
Brett Harned explica:
Queremos ser más ágiles; estamos aceptando el cambio, mejorando
continuamente, siendo lo más flexibles posible y adaptándonos como mejor
nos parezca. La cuestión es que nunca seremos verdaderamente ágiles,
como dice el Manifiesto. Está bien, siempre y cuando digamos lo que seremos.
Bret Harned
La estructura organizativa, las relaciones con los clientes, las personalidades, etc., juegan
un papel importante en la determinación del proceso de un proyecto. El truco consiste en
encontrar el proceso que funcione mejor para usted, las limitaciones y oportunidades de
su organización.
Si bien puede ser imposible adoptar un proceso verdaderamente Agile, sigue siendo una
buena idea trabajar en equipos interdisciplinarios, ingresar al entorno final más rápido, enviar
antes y con frecuencia, y dividir las tareas más grandes en componentes más pequeños. En
el capítulo 4, detallaremos cómo establecer un flujo de trabajo efectivo basado en patrones.
Modularización del contenido: estoy en Team Chunk
Prepare su contenido para ir a cualquier parte, porque va a ir a todas
partes.
Por una Web Amigable para el Futuro
Publicar contenido para la web solía ser una tarea bastante sencilla, ya que la web de
escritorio era el único juego disponible. Oh, como han cambiado las cosas. Hoy, nuestro
contenido es consumido por una gran cantidad de teléfonos inteligentes, teléfonos tontos,
netbooks, notebooks, tabletas, lectores electrónicos, relojes inteligentes, televisores,
consolas de juegos, señalización digital, tableros de automóviles y más.
Para abordar adecuadamente este panorama digital cada vez más diverso y ecléctico,
debemos revisar drásticamente nuestra percepción del contenido y las herramientas
que usamos para administrarlo.
En el futuro, lo que creo es que vamos a tener mejores herramientas
de gestión y publicación de contenido. Vamos a tener formas de tomar
contenido bien estructurado, fragmentos de contenido bien diseñados
que luego podemos descubrir cómo queremos reestructurar y publicar
y mostrar de una manera que sea adecuada para la plataforma
adecuada.
Karen McGrane
Afortunadamente, este futuro está empezando a tomar forma. Las organizaciones
están reconociendo la necesidad de crear contenido modularizado para llegar mejor a
su audiencia donde sea que se encuentren. Y los sistemas de administración de
contenido están evolucionando más allá de sus raíces de plataforma de publicación
web hacia herramientas que pueden crear y mantener elegantemente contenido modular.
Si bien los sofisticados sistemas de administración de contenido han existido durante
años en forma de soluciones personalizadas como la plataforma COPE (Crear una vez,
publicar en todas partes) de NPR , El pensamiento modular inteligente se está abriendo
camino en los principales sistemas de gestión de contenido.
código con clase
La modularidad ha sido durante mucho tiempo un principio básico en el
mundo de la informática, como discutimos anteriormente. Si bien este principio
existía mucho antes de que se inventara la web, la modularidad tardó un tiempo en
arraigarse en la mente y el corazón de los desarrolladores web.
A pesar de existir desde 1995, JavaScript, el lenguaje de programación de la
web, primero tuvo que soportar algunos dolores de crecimiento para madurar
hasta convertirse en el lenguaje capaz y respetado que es hoy. Ahora que JavaScript
ha crecido, los desarrolladores pueden aplicar esos principios informáticos probados y
verdaderos a sus flujos de trabajo de desarrollo web.
Como resultado, vemos que la gente desarrolla patrones sofisticados de
JavaScript y arquitecturas.
Aplicar principios de programación modular a JavaScript es un poco obvio, ya que
JavaScript es en sí mismo un lenguaje de programación.
Pero el pensamiento orientado a objetos también se está abriendo paso en otros
aspectos de la web, incluido CSS, el lenguaje de estilo de la web.
Metodologías como OOCSS, SMACSS, y BEM han surgido para ayudar a los
diseñadores web a crear y mantener arquitecturas CSS modulares.
16 DISEÑO ATÓMICO
Reparado visualmente
La modularidad no solo está infiltrando el lado del código del estilo en la web, sino
que está revolucionando la forma en que los diseñadores visuales abordan el diseño
web moderno.
A medida que prolifera la cantidad de ventanas gráficas y entornos, se vuelve
insostenible producir maquetas estáticas de cada página de una experiencia web.
Como bromeó Stephen Hay, presentar composiciones de Photoshop completamente
preparadas "es la forma más efectiva de mostrar a sus clientes cómo nunca se verá su
sitio web".
Eso no quiere decir que las herramientas de diseño estático como Photoshop y
Sketch no sean importantes. Lejos de ahi. Pero es la forma en que usamos estas
herramientas lo que ha cambiado drásticamente. Si bien la creación de cientos de
composiciones completas no es realista, estas herramientas estáticas se destacan
por proporcionar un campo de juego para establecer lo que Andy Clarke llama
"atmósfera de diseño":
La atmósfera describe los sentimientos que tenemos que son
evocados por el color, la textura y la tipografía. Es posible que ya
pienses en la atmósfera en otros términos. Puede llamarlo "sentimiento",
"estado de ánimo" o incluso "identidad visual". Independientemente de las
palabras que elija, la atmósfera de un diseño no depende del diseño. Es
independiente de la disposición y la ubicación visual. Se verá, o se sentirá,
en todos los tamaños de pantalla y en todos los dispositivos.
Andy Clarke
Establecer una atmósfera de diseño desde el principio es fundamental para el
éxito de un proyecto, por lo que los diseñadores han encontrado formas de facilitar estas
conversaciones importantes sin tener que generar maquetas completas.
La diseñadora Samantha Warren desarrolló artefactos de diseño llamados
mosaicos de estilo, que demuestran las exploraciones de color, tipo y textura en un bonito
resumen de una página. El diseñador Dan Mall se basó en la idea de Samantha con un
concepto llamado collages de elementos, que demuestran exploraciones de atmósfera de
diseño en un collage explotado de elementos de interfaz.
Los mosaicos de estilo, un concepto creado por la diseñadora Samantha Warren, permiten a los
diseñadores explorar el color, la tipografía y la textura sin tener que desarrollar composiciones completas.
Al dividir las exploraciones visuales en partes más pequeñas, los
diseñadores ahorran tiempo y esfuerzo y evitan presentar diseños
prematuros y poco realistas a los clientes. Más importante aún, estos enfoques
alejan a las partes interesadas de simplemente reaccionar ante una imagen
bonita y, en cambio, facilitan conversaciones cruciales sobre la dirección
general del diseño y cómo se relacionan con los objetivos del proyecto.
Discutiremos estos conceptos con más detalle en el capítulo 4, ¡pero baste
decir que el flujo de trabajo del diseño visual está cambiando en gran medida!
Diseño de interfaz de usuario sistemático
No estamos diseñando páginas, estamos diseñando sistemas
de componentes.
Stephen Hay
¿De qué está hecha una interfaz? ¿Cuáles son nuestros ladrillos Lego?
¿Cuáles son nuestras piezas de sándwich Subway que combinamos en
millones de combinaciones deliciosas? Son estas preguntas las que nos hemos
estado haciendo cada vez más ahora que estamos enviando nuestras interfaces
a más y más lugares.
Hace unos años, Ethan Marcotte nos presentó la idea del diseño web
receptivo. y sus tres principios básicos: cuadrículas fluidas, medios flexibles y
consultas de medios CSS. Estos tres ingredientes proporcionaron una base muy
necesaria para que los diseñadores crearan diseños flexibles.
18 DISEÑO ATÓMICO
que se adaptan inteligentemente a cualquier tamaño de pantalla. Quizás lo más importante
es que el diseño receptivo ayudó a que los diseñadores se entusiasmaran con la creación
de experiencias web reflexivas, adaptables y para múltiples dispositivos.
Como los diseñadores descubrieron rápidamente, la creación de experiencias web
para múltiples dispositivos implica mucho más que la creación de páginas blandas. Cada
pieza individual de una interfaz contiene sus propios desafíos y oportunidades únicos para
que se vea y funcione maravillosamente en muchos tamaños de pantalla y entornos.
¿Cómo podemos presentar la navegación principal, que generalmente se muestra como una
lista horizontal en pantallas grandes, de manera reflexiva en pantallas más pequeñas?
¿Cómo se traducen las cajas de luz, las migas de pan y los carruseles en ventanas de
visualización más pequeñas y tipos de entrada alternativos? Son estas preguntas las que me
llevaron a crear This Is Responsive, una muestra de patrones receptivos que demuestran las
diversas formas en que un componente en particular podría ejecutarse en un entorno receptivo.
Si bien This Is Responsive tiene éxito en articular cómo estos patrones de interfaz pueden
escalar a través de tamaños de pantalla y entornos, aún depende de los diseñadores y
desarrolladores poner estos patrones en acción. Y resulta que eso es mucho trabajo.
Frameworks de interfaz de usuario, en teoría y en la práctica
Los diseñadores y desarrolladores ya tienen poco tiempo y recursos, y ahora tienen
la tarea de crear interfaces que se vean y funcionen maravillosamente en cualquier
entorno. Esa es una orden muy alta.
Esta necesidad de abordar la creciente diversidad de dispositivos sin dejar de
sacar proyectos de forma sensata ha dado lugar a marcos frontend como
Foundation by Zurb. y Bootstrap. Estos marcos de interfaz de usuario brindan a los
diseñadores una colección de patrones HTML preensamblados, estilos CSS y JavaScript
para agregar funcionalidad a componentes interactivos como menús desplegables y
carruseles. En esencia, estos marcos son kits de herramientas útiles para ensamblar
interfaces rápidamente.
Bootstrap proporciona una colección de componentes de interfaz de usuario para acelerar el desarrollo.
Y chico, estas cosas son populares. Mientras escribo esto, Bootstrap es el repositorio
más popular en el sitio de código compartido GitHub, con más de 77.000 estrellas y
30.000 tenedores. La popularidad de estos marcos es un testimonio del hecho de
que los diseñadores y desarrolladores están buscando una base sólida para pararse
en este panorama web cada vez más complejo.
Uno de los aspectos más atractivos de estos marcos es la velocidad.
Los marcos como Bootstrap permiten a los diseñadores obtener ideas del
terreno rápidamente, crear prototipos rápidamente y lanzar sitios antes.
Debido a que los patrones proporcionados por un kit de herramientas ya
están probados en varios navegadores, los desarrolladores pueden dedicar su tiempo
a tareas más importantes en lugar de golpearse la cabeza contra una mesa probando
alguna versión arcaica de Internet Explorer. Y en caso de que los diseñadores se
queden atascados, las comunidades de estos marcos pueden proporcionar apoyo y
consejos útiles.
Para los freelancers, este aumento en la velocidad puede significar que pueden
asumir uno o tres proyectos adicionales, lo que genera más estabilidad financiera
para el año. Y en el mundo de las startups, un lugar donde está Bootstrap
20 DISEÑO ATÓMICO
omnipresente: los productos viables mínimos pueden lanzarse antes, lo que lleva a
respuestas más rápidas con respecto a la viabilidad de los productos.
Entonces, los marcos como Bootstrap son sistemas de diseño increíblemente populares que
proporcionan componentes bien probados, lo que da como resultado diseños consistentes y
lanzamientos más rápidos. ¿Qué no se podría amar? Bueno, como casi todo en la vida, hay
contras junto a los pros.
Problemas en el marco del paraíso
Cuando era niño, veía películas de ciencia ficción y programas de televisión con una
extraña fascinación. Había una pregunta que nunca pude quitarme del todo: ¿ por qué
todos están vestidos igual?
En el futuro, todos se visten igual. Crédito de la ilustración: Melissa Frost.
Solo podía suponer que, dado el tiempo suficiente, resolvemos la moda. “¡Dime, estos monos
son bastante elegantes y cómodos también! Vamos a usar esto de ahora en adelante”. "¡Suena
bien para mí!"
Por supuesto, no es así como funcionan los seres humanos. Todos tenemos diferentes gustos,
metas y deseos. La variedad, como dicen, es la sal de la vida, y la moda, la música y el diseño
reflejan nuestra naturaleza diversa. Sin embargo, en la web tendemos a caer en la trampa de
querer que todos hagan las cosas de la misma manera. "¿Por qué no todos los navegadores
simplemente se estandarizan en WebKit?" "¿Por qué los fabricantes de dispositivos no pueden
usar los mismos tamaños de pantalla?" "¡Siempre usa jQuery!" "¡Nunca uses jQuery!" "¡Solo usa
marcos!" “¡Nunca uses marcos!”
Al igual que en el mundo real, las diversas necesidades, objetivos y deseos de los
proyectos web conducen a una miríada de soluciones diferentes. Por supuesto,
hay un momento y un lugar para todo, y los diseñadores y desarrolladores
necesitan discernimiento para saber qué herramientas usar y cuándo.
Los marcos frontend son herramientas que brindan una solución específica
y una apariencia particular. Si bien esas soluciones ayudan a acelerar el
desarrollo, las experiencias resultantes terminan pareciéndose a esos monos de
ciencia ficción. Cuando todos usan los mismos botones, cuadrículas, menús
desplegables y componentes, las cosas naturalmente comienzan a verse iguales.
Si Nike, Adidas, Puma y Reebok rediseñaran sus respectivos sitios usando
Bootstrap, se verían sustancialmente similares. Eso ciertamente no es lo que
buscan estas marcas. Claro, cada marca puede modificar y ampliar la apariencia
predeterminada, pero después de un tiempo, la personalización significa luchar
contra la estructura, el estilo y la funcionalidad dados por el marco.
Además de los problemas de similitud, estos marcos pueden agregar
una hinchazón innecesaria a una experiencia. Es fantástico que los marcos
proporcionen una gran cantidad de componentes y funcionalidades preconstruidos,
pero un gran porcentaje de diseñadores y desarrolladores no adoptarán todos los
aspectos del marco. Desafortunadamente, los usuarios aún tienen que descargar
el CSS y JavaScript no utilizados del marco, lo que resulta en cargas de página
más lentas y frustración.
En el otro lado de la moneda, es posible que los marcos no lleguen lo
suficientemente lejos, lo que lleva a los desarrolladores a necesitar crear
una cantidad sustancial de código personalizado para lograr los objetivos de
sus proyectos. En algún momento, se cruza un umbral en el que los beneficios
iniciales de usar un marco, es decir, el desarrollo, se ven superados por el
tiempo dedicado a modificar, ampliar y arreglar el marco.
Y luego está el tema de los nombres. Usar un marco significa suscribirse
a las convenciones de estructura, nomenclatura y estilo de otra persona. Por
supuesto, es importante establecer un léxico inicial útil, pero lo que tiene sentido
para una organización puede no ser lo que sale de la caja de un marco. Yo, por
mi parte, me resistiría a la idea de usar el componente predeterminado de
Bootstrap para un área de contenido destacada que llaman "jumbotron". La
forma en que las convenciones de nomenclatura de un marco se combinan con
una base de código y un flujo de trabajo existentes debe discutirse adecuadamente
antes de subirse al tren del marco.
22 DISEÑO ATÓMICO
Ahora que hemos puesto a prueba los marcos, es importante dar un paso
atrás y reconocer que, conceptualmente, estos marcos son muy acertados. Es una
excelente idea trabajar con un kit de herramientas de diseño que promueva la coherencia
y acelere el tiempo de desarrollo. Mientras discutía el rediseño de la página de inicio de
Microsoft por parte de la tienda web Paravel con sede en Austin, el desarrollador Dave
Rupert enfatizó la importancia de crear y entregar un sistema de diseño a su cliente.
Dave articuló maravillosamente que no se trata necesariamente de usar Bootstrap para
cada cliente, sino de crear "pequeños Bootstrap para cada cliente".
Los entregables receptivos deben parecerse mucho a los sistemas de estilo Bootstrap
de Twitter que funcionan completamente y que se adaptan a las necesidades de sus
clientes. Estos ejemplos de código vivo son guías de estilo autodocumentadas que
se amplían para adaptarse a las necesidades de un cliente, así como a las
necesidades de la web en constante evolución para múltiples dispositivos.
Dave Ruperto
No se trata solo de usar un sistema de diseño, se trata de crear su propio
sistema.
Los sistemas de diseño salvan el día
Entonces, ¿cómo son los sistemas de diseño robusto? ¿Qué forma toman? ¿Cómo
los crea, los mantiene y los hace cumplir?
Las piedras angulares de los buenos sistemas de diseño son las guías de estilo,
que documentan y organizan los materiales de diseño al mismo tiempo que brindan
pautas, uso y medidas de protección.
Da la casualidad de que hay muchos favores de las guías de estilo, incluida la
documentación de identidad de marca, escritura, voz y tono, código, lenguaje de
diseño y patrones de interfaz de usuario. Este libro no detallará todas las categorías de
la guía de estilo, pero es importante echar un vistazo a cada una para comprender mejor
cómo cada guía de estilo influye en las demás y cómo las guías de estilo para la web
encajan en un ecosistema más grande.
Identidad de la marca
Las pautas de identidad de marca definen los activos y materiales que hacen que
una empresa sea única. Los logotipos, la tipografía, las paletas de colores, los
mensajes (como las declaraciones de misión y los eslóganes), las garantías (como
las tarjetas de presentación y las plantillas de PowerPoint) y más se agregan y
describen en las pautas de identidad de la marca.
Guía de estilo de la marca de la Universidad de West Virginia.
Es esencial que una marca se presente de manera coherente en un número
cada vez mayor de medios, canales y puntos de contacto.
¿Cómo pueden todos dentro de una organización hablar con una sola voz y
sentirse parte de una entidad singular? ¿Cómo saben los terceros qué colores
Pantone usar y cómo usar correctamente el logo de la marca?
Las pautas de identidad de marca brindan respuestas a estas preguntas
fundamentales en un centro centralizado.
Históricamente, las pautas de identidad de marca estaban contenidas en
libros de tapa dura (¿recuerdas, esas cosas con las páginas?), Pero como con
todo lo demás, las guías de estilo de marca se están abriendo camino en línea.
24 DISEÑO ATÓMICO
lenguaje de diseño
Si bien las pautas de identidad de la marca son bastante táctiles, las pautas del lenguaje
de diseño son un poco más difíciles de precisar. Las guías de estilo del lenguaje de diseño
articulan una dirección de diseño general, una filosofía y un enfoque para proyectos o
productos específicos.
Para presentarse de manera cohesiva en una gama cada vez mayor de productos
y medios, Google desarrolló un lenguaje de diseño llamado diseño de materiales. la
guía de estilo de diseño de materiales defne su filosofía de diseño general, objetivos y
principios generales, al mismo tiempo que proporciona aplicaciones específicas del lenguaje
de diseño de materiales.
El lenguaje de diseño de materiales de Google.
Las guías de estilo del lenguaje de diseño pueden (y generalmente lo hacen)
incorporar aspectos de otras categorías de guías de estilo para hacer que los conceptos
de alto nivel sean un poco más tangibles.
Las pautas del lenguaje de diseño no están escritas en piedra como lo están las pautas de la
marca. Por ejemplo, es probable que un día Google desarrolle un nuevo lenguaje de diseño
para reemplazar el diseño de materiales, por lo que mientras la marca general de Google
permanecerá intacta, el vocabulario de diseño en torno a sus productos cambiará.
voz y tono
Las personas interactúan con las marcas a través de una gran variedad de canales
y medios. Además de los medios digitales que hemos discutido hasta ahora, las
marcas también operan en medios impresos, minoristas, exteriores, radio, televisión
y otros canales. Cuando una marca debe comunicarse a través de tantos puntos de
contacto variados, hablar de una manera unificada y coherente se vuelve fundamental
para el éxito de una marca.
La voz de una marca permanece igual día a día, pero su tono tiene que
cambiar todo el tiempo, dependiendo tanto de la situación como de los
sentimientos del lector.
Kate Kiefer Lee
La voz es un aspecto elemental de la identidad de una marca, por lo que, por lo general,
las pautas de identidad de la marca incluyen alguna referencia a la voz de la marca.
Sin embargo, estas pautas generalmente no tienen muchos matices, por lo que las
pautas de voz y tono son tan importantes.
Pautas de voz y tono de MailChimp
Las pautas de voz y tono se aclaran al articular cómo la voz y el tono de la empresa
deben cambiar en una variedad de escenarios. Directrices de tono y voz brillante de
MailChimp definir
26 DISEÑO ATÓMICO
cómo cambia el tono de la marca según los tipos de contenido, de modo que cuando se
rechaza la tarjeta de crédito de un usuario, los escritores saben cómo alejarse de su tono
de voz generalmente descarado y juguetón y adoptar un tono más serio.
Escribiendo
El auge de la web y los sitios web administrados por contenido hace que sea
más fácil que nunca para muchas personas dentro de una organización publicar
contenido. Esto, por supuesto, puede ser un arma de doble filo, ya que mantener un
estilo de escritura consistente para una organización con muchas voces puede ser un
desafío. Las guías de estilo de escritura brindan a cada autor algunas pautas y barandillas
para contribuir con contenido.
Las guías de estilo de escritura pueden ser extremadamente granulares, definiendo detalles
en torno a la puntuación y la gramática, pero no siempre tienen que ser tan detalladas.
Guía de estilo de escritura de la Universidad de Dalhousie proporciona una lista concisa
de principios y mejores prácticas que deben seguir los contribuyentes de contenido.
La guía de estilo de redacción de The Economist.
Guías de estilo de código
Es esencial que los equipos escriban código legible, escalable y mantenible. Pero
sin una manera de promover y hacer cumplir la consistencia del código, es fácil que las
cosas se desmoronen y dejen que cada desarrollador se las arregle solo.
Las guías de estilo de código proporcionan convenciones, patrones y ejemplos de
cómo los equipos deben abordar su código. Estas pautas y barandillas ayudan a
controlar la locura para que los equipos puedan concentrarse en producir un gran
trabajo juntos en lugar de refactorizar un montón de código descuidado e inconsistente.
La guía de estilo de código de GitHub proporciona las mejores prácticas para escribir HTML, CSS, JavaScript y
Ruby dentro de su organización.
28 DISEÑO ATÓMICO
Bibliotecas de patrones
Y ahora para el evento principal. Las bibliotecas de patrones, también conocidas como guías
de estilo frontend, bibliotecas de interfaz de usuario o bibliotecas de componentes, se están
convirtiendo rápidamente en la piedra angular del diseño de interfaz moderno.
Código para la biblioteca de patrones de Estados Unidos
El resto de este libro se concentrará en cómo abordar el diseño de interfaces de manera
sistemática y detallará cómo establecer y mantener bibliotecas de patrones.
Beneficios de la guía de estilo
Lograr que las interfaces de usuario funcionen en una miríada de tamaños de pantalla,
dispositivos, navegadores y entornos es una tarea difícil en sí misma. Pero una vez que
tiene en cuenta otros miembros del equipo, clientes, partes interesadas y peculiaridades
organizacionales, las cosas comienzan a parecer francamente intimidantes.
Las guías de estilo son herramientas importantes que ayudan a prevenir el caos, tanto
desde el punto de vista del diseño y desarrollo como desde una perspectiva organizacional.
He aquí por qué las guías de estilo ahora son herramientas esenciales para el diseño y
desarrollo web moderno.
consistentemente increíble
Las guías de estilo web promueven la coherencia y la cohesión en una interfaz de
usuario. Esta coherencia beneficia tanto a las personas que crean estas interfaces
como a sus usuarios.
Recientemente visité el sitio web de mi proveedor de seguro médico para pagar
mi factura. En el transcurso de cinco clics, me encontré con cuatro diseños de
interfaz distintos, algunos de los cuales parecían haber sido tocados por última vez en
1999. Esta experiencia inconsistente puso la carga sobre mí, el usuario, de averiguar
qué iba dónde y cómo interpretar elementos dispares de la interfaz. Cuando llegué al
formulario de pago, sentí que no podía confiar en que la empresa procesaría mi pago
con éxito y de forma segura.
Las guías de estilo ayudan a eliminar estas incoherencias fomentando la
reutilización de los elementos de la interfaz. Los diseñadores y desarrolladores
pueden consultar los patrones existentes para asegurarse de que el trabajo que
están produciendo sea coherente con lo que ya se ha establecido.
Incluso los terceros responsables de hacer coincidir sus interfaces de usuario
con la apariencia de las interfaces de usuario internas de una empresa pueden
hacer un gran uso de una guía de estilo. Las experiencias alojadas externamente,
como los portales de pago o los sitios localizados, pueden coincidir mejor con la
apariencia de la experiencia principal al aplicar los estilos definidos en la guía.
Hacer que las guías de estilo sean centrales para su proceso da como
resultado interfaces de usuario que se sienten más unidas y confiables, lo que
ayuda a los usuarios a realizar sus tareas más rápido y les permite dominar la interfaz.
Un vocabulario compartido
¿Qué significa "barra de herramientas de utilidad"? ¿Todos entienden lo que es un
"héroe del control deslizante táctil"?
A medida que aumenta el número de personas que trabajan en un proyecto, es muy
fácil que se produzcan interrupciones en la comunicación. No es raro que diferentes
disciplinas tengan diferentes nombres para el mismo módulo, y que las personas se
vuelvan deshonestas e inventen sus propias convenciones de nomenclatura. Para que
se produzca una verdadera colaboración, es esencial que los equipos hablen un idioma
común. Las guías de estilo están ahí para ayudar a establecer ese vocabulario
compartido.
30 DISEÑO ATÓMICO
Dar nombres a patrones como 'Blocks ThreeUp' en la guía de estilo de Starbucks ayuda a los miembros del
equipo a hablar el mismo idioma.
Las guías de estilo establecen un vocabulario coherente y compartido entre
todos los involucrados en un proyecto, fomentando la colaboración entre
disciplinas y reduciendo las interrupciones en la comunicación.
Educación
En su libro Guías de estilo de frontend, Anna Debenham explica hábilmente las
muchas ventajas de crear guías de estilo, incluido uno de los beneficios más
cruciales: la educación.
La educación es tan importante como la documentación. Una guía de estilo
puede mostrar a los clientes que los sitios web son sistemas en lugar de
colecciones de páginas.
Anna Debenham
Las guías de estilo demuestran a los clientes, las partes interesadas y
otras disciplinas que hay mucho trabajo realmente reflexivo en el diseño y
desarrollo de un sitio web más allá de simplemente "Oye, hagamos un nuevo
sitio web". Una biblioteca de patrones comunica el lenguaje de diseño de una
manera muy tangible, lo que ayuda a las partes interesadas a comprender que
un sistema subyacente determina la interfaz final.
Las guías de estilo pueden ayudar a aliviar lo que yo llamo el síndrome del copo
de nieve especial, en el que ciertos departamentos de una organización piensan
que tienen problemas únicos y, por lo tanto, exigen soluciones únicas.
Al exponer el sistema de diseño en forma de una guía de estilo, estos
muñecos de nieve especiales pueden apreciar mejor la consistencia y
comprender por qué sus solicitudes de diseños personalizados reciben rechazo.
Un flujo de trabajo empático
La educación no solo es importante para los clientes y las partes interesadas. Una buena
guía de estilo ayuda a informar a los diseñadores y desarrolladores sobre las herramientas
que tienen en su caja de herramientas y proporciona reglas y mejores prácticas sobre
cómo usarlas correctamente.
Al convertir una guía de estilo en la piedra angular de su flujo de trabajo (que detallaremos
en el capítulo 4), los diseñadores y desarrolladores se ven obligados a pensar en cómo sus
decisiones afectan el sistema de diseño más amplio. Se vuelve más difícil volverse rebelde
y más fácil pensar en el bien común.
Y aquí es exactamente donde quieres que estén los miembros del equipo.
Una guía de estilo proporciona un hogar para que cada disciplina contribuya con sus
respectivas consideraciones y preocupaciones por los patrones. Al recopilar todas estas
consideraciones bajo un mismo techo, la guía de estilo se convierte en un centro para
todos los involucrados en el proyecto, lo que ayuda a cada disciplina a comprender mejor el
sistema de diseño desde muchas perspectivas.
Probando, probando, 123
¿La página de inicio está rota, dices? Bueno, ¿qué es exactamente romperlo?
La capacidad de separar una interfaz en sus componentes hace que las pruebas
sean mucho más fáciles. Una guía de estilo le permite ver patrones de interfaz de forma
aislada, lo que permite a los desarrolladores concentrarse en lo que está causando errores,
inconsistencias del navegador o problemas de rendimiento.
Velocidad
Anteriormente en el capítulo discutimos cómo el diseño y desarrollo más rápidos es una de
las razones principales por las que los marcos de interfaz de usuario como Bootstrap son
tan populares. Estamos bajo presión para sacar los proyectos tan pronto como sea
humanamente posible. Al desarrollar su propio sistema de diseño, puede obtener las mismas
recompensas de velocidad que los kits de herramientas de interfaz de usuario listos para usar.
Es cierto que idear un sistema de diseño de interfaz y crear una biblioteca de patrones
personalizada inicialmente requiere mucho tiempo, reflexión y
32 DISEÑO ATÓMICO
esfuerzo Pero una vez que se establece la biblioteca de patrones, el diseño
y el desarrollo posteriores se vuelven mucho más rápidos, lo que tiende a hacer
felices a todos.
Federico Holgado, desarrollador líder de UX en MailChimp, explicó cómo la
biblioteca de patrones de MailChimp inicialmente constaba de patrones creados
a partir de las cuatro pantallas principales de su aplicación. Pero una vez que
pasaron a otras áreas del sitio, se dieron cuenta de que podían usar patrones
existentes en lugar de tener que generar patrones nuevos desde cero cada vez.
…Una vez que hicimos eso, mientras implementábamos cosas en otras
páginas, comenzamos a darnos cuenta: hombre, este sistema realmente
funcionará aquí y este sistema realmente funcionará aquí y aquí.
Federico Holgado
En él a largo plazo
No hay duda de que las guías de estilo ayudan a los equipos a hacer las cosas de
manera efectiva aquí y ahora. Pero al igual que un buen vino, las guías de estilo
aumentan su valor con el tiempo. Lo hermoso de los sistemas de diseño de interfaz
es que pueden y deben modificarse, ampliarse y refinarse en los años venideros.
Como se mencionó anteriormente, la creación de una biblioteca de patrones
personalizada requiere mucho trabajo duro por adelantado, pero ese trabajo duro
debería proporcionar una base estructural para futuras iteraciones y refinamientos.
Las lecciones aprendidas de análisis, pruebas de usuarios, pruebas A/B y
experiencia deben incorporarse a la guía de estilo, lo que la convierte en un
poderoso centro de verdad, conocimiento y mejores prácticas.
Mejor aún, incluso si tuviera que realizar un rediseño importante, descubrirá
que muchos de los componentes básicos de la interfaz estructural seguirán
siendo los mismos. Todavía tendrá formularios, botones, encabezados, otros
patrones de interfaz comunes, por lo que no hay necesidad de tirar al bebé con
el agua del baño. Una guía de estilo proporciona una base sólida para todo el
trabajo futuro, incluso si ese trabajo futuro puede parecer totalmente diferente.
Desafíos de la guía de estilo
A estas alturas, los benefcios de crear sistemas de diseño deberían
ser muy claros y, con suerte, las visiones de ciruelas dulces y
hermosas guías de estilo están bailando en su cabeza. Pero para alcanzar el
nirvana de la guía de estilo, primero debes superar los muchos desafíos
traicioneros que vienen con el territorio.
La venta dura
Para beneficiarse de las guías de estilo, las organizaciones primero deben
asignar el tiempo y el presupuesto necesarios para hacerlas realidad. Eso
requiere que las organizaciones superen la mentalidad a corto plazo que con
demasiada frecuencia se cuela en la cultura de la empresa.
Los benefcios a largo plazo que brindan las guías de estilo son obvios
para aquellos que ya están pensando en el juego largo. El desafío, por lo tanto,
se convierte en convencer a aquellos atrapados en una mentalidad de corto
plazo, trimestre por trimestre, de que establecer un sistema de diseño reflexivo
es una inversión inteligente en el futuro.
Cuestión de tiempo
La parte difícil es construir la máquina que construye el producto.
Dennis Crowley
Quizás el desafío más grande e inevitable es que las guías de estilo requieren
mucho tiempo para crearse. No sé tú, pero yo no voy al trabajo todos los días
pensando en qué hacer con mi tiempo. Nunca he conocido a una persona que
no se sienta presionada para trabajar, y esta presión naturalmente lleva a
enfocarse en el proyecto web principal. Desafortunadamente, los cronogramas
agresivos y los presupuestos finitos restan valor al esfuerzo requerido para hacer
realidad las guías de estilo, incluso cuando los equipos están comprometidos
con la causa.
34 DISEÑO ATÓMICO
Proyectos Auxiliares
Las bibliotecas de patrones a menudo se tratan como proyectos auxiliares, en lugar
de como componentes del producto final. Al tratar las bibliotecas de patrones como
algo separado del proyecto central, tienden a caer en la categoría agradable y se
convierten en los primeros en cortar cuando las cosas se ponen difíciles.
Este enigma del proyecto auxiliar me recuerda los sentimientos que a menudo
escucho sobre la factorización de la accesibilidad en los proyectos. Dicen: "Ojalá
tuviéramos el tiempo y el presupuesto para la accesibilidad, pero..." La noción de
que la accesibilidad (y otros principios como el rendimiento y la capacidad de
respuesta) es una línea adicional costosa es una falacia. Las bibliotecas de
patrones, al igual que la accesibilidad, son buenas ideas para incluir en su flujo de
trabajo, ya sea que el plan del proyecto las requiera explícitamente o no.
Mantenimiento y gobernanza
Incluso si se asigna tiempo y dinero para establecer guías de estilo, estas valiosas
herramientas a menudo mueren si no se les da el enfoque que necesitan para
alcanzar su verdadero potencial.
Una estrategia de mantenimiento y gobernanza es fundamental para el éxito de
las guías de estilo. Las guías de estilo se tirarán a la basura (justo al lado de todos
esos PSD y wireframes) y se abandonarán sin una estrategia adecuada para quién
las administrará, mantendrá y hará cumplir.
El mantenimiento de la guía de estilo es un tema muy importante y merece ser
cubierto en detalle, por lo que profundizaremos en cómo crear guías de estilo
mantenibles en el capítulo 5.
Confusión de la audiencia
Las guías de estilo pueden malinterpretarse como herramientas útiles
solo para diseñadores o desarrolladores, lo que conduce a una falta de
visibilidad que limita inmediatamente su efectividad. En lugar de servir como
un abrevadero para todos en la organización, una guía de estilo puede
convertirse en el secreto mejor guardado de una disciplina. Coloréame ingenuo,
pero no creo que esto ayude a fomentar una cultura de colaboración.
Sin pensar en audiencias más amplias, las guías de estilo pueden parecer
demasiado vagas o demasiado técnicas, lo que puede intimidar a otras
disciplinas y hacerles creer que estos recursos no son para ellas.
Estructura de la guía de estilo
Para que las guías de estilo sean recursos útiles para todos en una
organización, deben transmitir claramente qué son y por qué son importantes. Las
guías de estilo deben ser atractivas, atractivas, visibles, claras y fáciles de usar.
Como se mencionó anteriormente, deben ser conscientes de que una gran cantidad
de audiencias los verán, por lo que deben tratar de ser acogedores y útiles para la
mayor cantidad de personas posible.
La página de inicio de la guía de estilo de Yelp tiene un diseño atractivo y un texto de introducción importante que
explica el propósito y la audiencia de la guía.
falta de contexto
El contexto es clave para comprender un sistema de diseño. Desafortunadamente,
la mayoría de las bibliotecas de patrones no brindan ninguna pista sobre cuándo,
cómo y dónde se usan sus componentes. Sin proporcionar contexto, los diseñadores
y desarrolladores no saben qué tan global es un patrón en particular y, como resultado,
no sabrían qué páginas de su aplicación deberían revisarse, someterse a control de
calidad y probarse si se realizaron cambios.
36 DISEÑO ATÓMICO
'Bloque resaltado' parece útil, pero ¿dónde se usa este patrón?
Falta de una metodología clara
Por mucho que adoro las bibliotecas de patrones , No puedo dejar de notar una falta de
estructura en muchos de ellos. No me malinterpreten, creo que es absolutamente fantástico
que los equipos piensen sistemáticamente y documenten sus patrones de interfaz de usuario.
Pero a menudo siento que muchas bibliotecas de patrones son poco más que aerosoles de
módulos dispuestos libremente. Creo que hay margen de mejora.
En busca de una metodología de diseño de interfaces
Para que podamos crear experiencias para este panorama web ecléctico, debemos
evolucionar más allá de la metáfora de la página que nos ha acompañado desde el
nacimiento de la web. Afortunadamente, las organizaciones están adoptando la modularidad
en todos los aspectos del proceso de creación web, lo que conduce a un trabajo más inteligente
y sistemas más sostenibles.
A medida que la cantidad de dispositivos, navegadores y entornos continúa aumentando a
un ritmo asombroso, la necesidad de crear sistemas de diseño de interfaz reflexivos y
deliberados se vuelve más evidente que nunca.
Introduzca el diseño atómico.
Capitulo 2
Diseño atómico
Metodología
Átomos, moléculas,
organismos, plantillas y páginas
7 http://www.uie.com/articles/magic_escalator/
8 http://en.wikipedia.org/wiki/Scrum_%28software_development%29
38 DISEÑO ATÓMICO
Mi búsqueda de una metodología para crear sistemas de diseño de interfaz me llevó
a buscar inspiración en otros campos e industrias. Dado este mundo increíblemente
complejo que hemos creado, parecía natural que otros campos hubieran abordado
problemas similares de los que podíamos aprender y apropiarnos. Resulta que muchos
otros campos como el diseño industrial y la arquitectura han desarrollado sistemas modulares
inteligentes para fabricar objetos inmensamente complejos como aviones, barcos y
rascacielos.
Pero mis exploraciones originales siguieron retrocediendo al mundo natural, lo que provocó
recuerdos de estar sentado en un escritorio desvencijado en el laboratorio de química de
mi escuela secundaria.
Tomando pistas de la química
Mi clase de química de la escuela secundaria fue impartida por un serio veterano de Vietnam
con un bigote extraordinariamente impresionante. La clase del Sr. Rae tenía la reputación
de ser una de las clases más difíciles de la escuela, en gran parte debido a una tarea que
requería que los estudiantes equilibraran cientos y cientos de ecuaciones químicas contenidas
en una hoja de trabajo enorme.
Si eres como yo, es posible que necesites un poco de repaso para recordar cómo se
ve una ecuación química, así que aquí tienes:
Un ejemplo de una ecuación química que muestra átomos de hidrógeno y oxígeno combinándose para
formar una molécula de agua.
CAPÍTULO 2 / METODOLOGÍA DE DISEÑO ATÓMICO 39
Las reacciones químicas están representadas por ecuaciones químicas, que a
menudo muestran cómo los elementos atómicos se combinan para formar
moléculas. En el ejemplo anterior, vemos cómo el hidrógeno y el oxígeno se combinan
para formar moléculas de agua.
En el mundo natural, los elementos atómicos se combinan para formar
moléculas. Estas moléculas pueden combinarse aún más para formar
organismos relativamente complejos. Para explicar un poco más:
Los átomos son los componentes básicos de toda la materia. Cada elemento
químico tiene propiedades distintas y no se pueden descomponer más sin perder
su significado. (Sí, es cierto que los átomos están compuestos de fragmentos
aún más pequeños, como protones, electrones y neutrones, pero los átomos son
la unidad funcional más pequeña ).
Las moléculas son grupos de dos o más átomos que se mantienen unidos por
enlaces químicos. Estas combinaciones de átomos adquieren sus propias
propiedades únicas y se vuelven más tangibles y operativas que los átomos.
Los organismos son conjuntos de moléculas que funcionan juntas como una
unidad. Estas estructuras relativamente complejas pueden variar desde
organismos unicelulares hasta organismos increíblemente sofisticados como
los seres humanos.
Por supuesto, estoy simplificando la composición increíblemente rica del universo,
pero la esencia básica permanece: los átomos se combinan para formar
moléculas, que luego se combinan para formar organismos. Esta teoría atómica
significa que toda la materia del universo conocido se puede descomponer en un
conjunto finito de elementos atómicos:
La tabla periódica de los elementos químicos.
40 DISEÑO ATÓMICO
Aparentemente, la estrategia del Sr. Rae de hacer que los estudiantes equilibren toneladas de
ecuaciones químicas de manera aturdidora funcionó, porque estoy volviendo a ella todos estos años
más tarde en busca de inspiración sobre cómo abordar el diseño de interfaz.
La metodología del diseño atómico
A estas alturas te estarás preguntando por qué estamos hablando de la teoría atómica, y tal vez
incluso estés un poco enojado conmigo por obligarte a revivir los recuerdos de la clase de química de
la escuela secundaria. Pero esto va a alguna parte, lo prometo.
Discutimos anteriormente cómo toda la materia del universo se puede descomponer en un conjunto
finito de elementos atómicos. Da la casualidad de que nuestras interfaces se pueden dividir en un
conjunto finito similar de elementos.
Tabla periódica de elementos HTML de Josh Duck Articula maravillosamente cómo todos nuestros sitios
web, aplicaciones, intranets, hoobadyboops y lo que sea están compuestos de los mismos elementos
HTML.
La tabla periódica de elementos HTML de Josh Duck.
Debido a que estamos comenzando con un conjunto finito similar de bloques de
construcción, podemos aplicar el mismo proceso que ocurre en el mundo natural para
diseñar y desarrollar nuestras interfaces de usuario.
Introduzca el diseño atómico.
El diseño atómico es una metodología compuesta por cinco etapas distintas que
trabajan juntas para crear sistemas de diseño de interfaz de una manera más
deliberada y jerárquica. Las cinco etapas del diseño atómico son:
1. Átomos
2. Moléculas
3. Organismos 4.
Plantillas 5. Páginas
El diseño atómico son átomos, moléculas, organismos, plantillas y páginas que trabajan juntos al mismo tiempo
para crear sistemas de diseño de interfaz efectivos.
El diseño atómico no es un proceso lineal, sino más bien un modelo mental que
nos ayuda a pensar en nuestras interfaces de usuario como un todo cohesivo y una
colección de partes al mismo tiempo. Cada una de las cinco etapas juega un papel
clave en la jerarquía de nuestros sistemas de diseño de interfaz. Vamos a sumergirnos
en cada etapa con un poco más de detalle.
42 DISEÑO ATÓMICO
Átomos
Si los átomos son los componentes básicos de la materia, entonces los átomos
de nuestras interfaces sirven como los componentes básicos que componen
todas nuestras interfaces de usuario. Estos átomos incluyen elementos HTML
básicos como etiquetas de formulario, entradas, botones y otros que no se pueden
desglosar más sin dejar de ser funcionales.
Los átomos incluyen etiquetas HTML básicas
como entradas, etiquetas y botones.
Cada átomo en el mundo natural tiene sus propias propiedades únicas.
Un átomo de hidrógeno contiene un electrón, mientras que un átomo de helio
contiene dos. Estas propiedades químicas intrínsecas tienen efectos profundos
en su aplicación (por ejemplo, la explosión de Hindenburg fue tan catastrófica porque
la aeronave estaba llena de gas hidrógeno extremadamente inflamable en lugar de
gas helio inerte). En el mismo
42 https://developer.mozilla.org/enUS/docs/Web/HTML/Element
De manera, cada átomo de interfaz tiene sus propias propiedades únicas, como las
dimensiones de una imagen principal o el tamaño de fuente de un encabezado principal.
Estas propiedades innatas influyen en cómo se debe aplicar cada átomo al sistema de
interfaz de usuario más amplio.
En el contexto de una biblioteca de patrones, los átomos demuestran todos sus estilos básicos
de un vistazo, lo que puede ser una referencia útil a la que volver mientras desarrolla y mantiene
su sistema de diseño. Pero al igual que los átomos en el mundo natural, los átomos de interfaz
no existen en el vacío y solo cobran vida con la aplicación.
Moléculas
En química, las moléculas son grupos de átomos unidos entre sí que adquieren nuevas
propiedades distintas. Por ejemplo, las moléculas de agua y las moléculas de peróxido de
hidrógeno tienen sus propias propiedades únicas y se comportan de manera bastante diferente,
aunque estén formadas por los mismos elementos atómicos (hidrógeno y oxígeno).
En las interfaces, las moléculas son grupos relativamente simples de elementos de
interfaz de usuario que funcionan juntos como una unidad. Por ejemplo, una etiqueta de
formulario, una entrada de búsqueda y un botón pueden unirse para crear una molécula de
formulario de búsqueda.
44 DISEÑO ATÓMICO
Una molécula de formulario de búsqueda se compone de un átomo de etiqueta, un
átomo de entrada y un átomo de botón.
Cuando se combinan, estos átomos abstractos de repente tienen un propósito. El
átomo de etiqueta ahora define el átomo de entrada. Al hacer clic en el botón atom
ahora se envía el formulario. El resultado es un componente simple, portátil y
reutilizable que se puede colocar en cualquier lugar donde se necesite la función de
búsqueda.
Ahora, ensamblar elementos en grupos funcionales simples es algo que
siempre hemos hecho para construir interfaces de usuario. Pero dedicar una
etapa en la metodología de diseño atómico a estos componentes relativamente
simples nos brinda algunas ideas clave.
La creación de componentes simples ayuda a los diseñadores y desarrolladores
de UI a adherirse al principio de responsabilidad única, un antiguo precepto informático
que fomenta una mentalidad de "haz una cosa y hazla bien". Cargar un solo patrón
con demasiada complejidad hace que el software sea difícil de manejar. Por lo tanto,
la creación de moléculas de interfaz de usuario simples facilita las pruebas, fomenta
la reutilización y promueve la coherencia en toda la interfaz.
Ahora tenemos componentes simples, funcionales y reutilizables que podemos poner
en un contexto más amplio. ¡Entrar organismos!
Organismos
Los organismos son componentes de interfaz de usuario relativamente complejos compuestos
por grupos de moléculas y/o átomos y/u otros organismos. Estos organismos forman secciones
distintas de una interfaz.
Repasemos nuestra forma de búsqueda molécula. Un formulario de búsqueda a menudo puede
se puede encontrar en el encabezado de muchas experiencias web, así que pongamos esa
molécula de formulario de búsqueda en el contexto de un organismo de encabezado.
Este organismo de cabecera se compone de una molécula de formulario de búsqueda, un átomo de logotipo y una
molécula de navegación primaria.
El encabezado forma una sección independiente de una interfaz, aunque contiene varias partes más
pequeñas de la interfaz con sus propias propiedades y funciones únicas.
Los organismos pueden consistir en tipos de moléculas similares o diferentes. Un organismo
de encabezado puede constar de elementos diferentes, como una imagen de logotipo, una lista de
navegación principal y un formulario de búsqueda. Vemos este tipo de organismos en casi todos los
sitios web que visitamos.
46 DISEÑO ATÓMICO
Los organismos como los encabezados de los sitios web consisten en moléculas más pequeñas como la navegación principal, los formularios de búsqueda,
la navegación de utilidades y los logotipos.
Mientras que algunos organismos pueden consistir en diferentes tipos de
moléculas, otros organismos pueden consistir en la misma molécula repetida una y
otra vez. Por ejemplo, visite una página de categoría de casi cualquier sitio web de
comercio electrónico y verá una lista de productos que se muestran en algún tipo de
cuadrícula.
Construir desde moléculas hasta organismos más elaborados proporciona a los
diseñadores y desarrolladores un importante sentido del contexto.
Los organismos demuestran esos componentes más pequeños y simples en
acción y sirven como patrones distintos que se pueden usar una y otra vez. El
organismo de cuadrícula de productos se puede emplear en cualquier lugar donde
se necesite mostrar un grupo de productos, desde listas de categorías hasta resultados
de búsqueda y productos relacionados.
Ahora que tenemos organismos definidos en nuestro sistema de diseño, podemos
romper nuestra analogía química y aplicar todos estos componentes a algo que se
parece a una página web.
Un organismo de cuadrícula de productos en el sitio web de comercio electrónico de Gap consiste en la misma molécula de elemento
de producto repetida una y otra vez.
Plantillas
48 DISEÑO ATÓMICO
Ahora, amigos, es hora de decir adiós a nuestra analogía química.
El lenguaje de los átomos, las moléculas y los organismos conlleva una jerarquía útil
para que construyamos deliberadamente los componentes de nuestros sistemas de
diseño. Pero, en última instancia, debemos adoptar un lenguaje que sea más
apropiado para nuestro resultado final y que tenga más sentido para nuestros clientes,
jefes y colegas. Intentar llevar la analogía de la química demasiado lejos podría
confundir a las partes interesadas y hacer que piensen que está un poco loco. Confía
en mí.
Las plantillas son objetos a nivel de página que colocan componentes en un
diseño y articulan la estructura de contenido subyacente del diseño.
Para aprovechar nuestro ejemplo anterior, podemos tomar el organismo del
encabezado y aplicarlo a una plantilla de página de inicio.
La plantilla de la página de inicio consta de organismos y moléculas aplicadas a un diseño.
Esta plantilla de página de inicio muestra todos los componentes de
página necesarios que funcionan juntos, lo que proporciona contexto para estas
moléculas y organismos relativamente abstractos. Al crear un sistema de diseño
efectivo, es fundamental demostrar cómo se ven y funcionan los componentes juntos
en el contexto de un diseño para
demostrar que las partes se suman a un todo que funciona bien. Discutiremos esto más
en un momento.
Otra característica importante de las plantillas es que se enfocan en la estructura
de contenido subyacente de la página en lugar del contenido final de la página. Los
sistemas de diseño deben tener en cuenta la naturaleza dinámica del contenido, por lo
que es muy útil articular las propiedades importantes de los componentes, como el
tamaño de las imágenes y la longitud de los caracteres para los encabezados y los
pasajes de texto.
Mark Boulton analiza la importancia de definir la estructura de contenido subyacente
de una página:
Puedes crear buenas experiencias sin conocer el contenido.
Lo que no puedes hacer es crear buenas experiencias sin conocer
la estructura de tu contenido. De qué está hecho tu contenido, no
de qué es tu contenido.
Mark Boulton
Al defnir el esqueleto de una página, podemos crear un sistema que puede dar cuenta
de una variedad de contenido dinámico, al mismo tiempo que proporciona las medidas
de protección necesarias para los tipos de contenido que pueblan ciertos patrones de
diseño. Por ejemplo, la plantilla de la página de inicio de Time Inc. muestra algunos
componentes clave en acción y al mismo tiempo demuestra la estructura del contenido
con respecto al tamaño de las imágenes y la longitud de los caracteres:
50 DISEÑO ATÓMICO
La plantilla de la página de inicio de Time Inc. demuestra la estructura subyacente del contenido.
Ahora que hemos establecido el sistema esquelético de nuestras páginas, ¡pongámosles un poco de carne en
los huesos!
Paginas
Las páginas son instancias específicas de plantillas que muestran cómo se
ve una interfaz de usuario con contenido representativo real en su lugar. Sobre
la base de nuestro ejemplo anterior, podemos tomar la plantilla de la página de
inicio y verter texto, imágenes y medios representativos en la plantilla para mostrar
contenido real en acción.
La etapa de la página es la etapa más concreta del diseño atómico y es importante
por algunas razones bastante obvias. Después de todo, esto es lo que los
usuarios verán e interactuarán cuando visiten su experiencia.
Esto es lo que firmarán sus partes interesadas. Y aquí es donde ves que todos
esos componentes se unen para formar una interfaz de usuario hermosa y
funcional. ¡Emocionante!
52 DISEÑO ATÓMICO
La etapa de la página reemplaza el contenido del marcador de posición con contenido representativo real para dar vida al
sistema de diseño.
Además de demostrar la interfaz final como la verán los usuarios, las páginas son
esenciales para probar la eficacia del sistema de diseño subyacente. Es en la etapa
de la página que podemos ver cómo se mantienen todos esos patrones cuando se
aplica contenido real al sistema de diseño. ¿Todo se ve bien y funciona como
debería? Si la respuesta es no, entonces podemos retroceder y modificar nuestras
moléculas, organismos y plantillas para abordar mejor las necesidades de nuestro
contenido.
Cuando vertemos contenido representativo real en la plantilla de la página
de inicio de Time Inc., podemos ver cómo se mantienen todos esos patrones de
diseño subyacentes.
En la etapa de la página, podemos ver cómo se ve la página de inicio de Time Inc. con contenido representativo real
en su lugar. Con el contenido real en su lugar, podemos ver si los componentes de la interfaz de usuario que
componen la página sirven correctamente el contenido que se vierte en ellos.
Debemos crear sistemas que establezcan patrones de diseño reutilizables y que también reflejen con precisión la
realidad del contenido que estamos colocando dentro de esos patrones.
54 DISEÑO ATÓMICO
Las páginas también brindan un lugar para articular variaciones en las plantillas, lo
cual es crucial para establecer sistemas de diseño sólidos y confiables.
Estos son solo algunos ejemplos de variaciones de plantilla:
Un usuario tiene un artículo en su carrito de compras y otro usuario tiene
diez artículos en su carrito.
El tablero de una aplicación web generalmente muestra la actividad reciente, pero
esa sección está suprimida para los usuarios nuevos.
El título de un artículo puede tener 40 caracteres, mientras que el título de otro
artículo puede tener 340 caracteres. Los usuarios con privilegios administrativos
pueden ver información
botones y opciones en su tablero en comparación con los usuarios que no son
administradores.
En todos estos ejemplos, las plantillas subyacentes son las mismas, pero las
interfaces de usuario cambian para reflejar la naturaleza dinámica del contenido. Estas
variaciones influyen directamente en cómo se construyen las moléculas, los organismos
y las plantillas subyacentes. Por lo tanto, crear páginas que tengan en cuenta estas
variaciones nos ayuda a crear sistemas de diseño más resistentes.
¡Así que eso es diseño atómico! Estas cinco etapas distintas trabajan juntas
simultáneamente para producir sistemas de diseño de interfaz de usuario efectivos.
Para resumir el diseño atómico en pocas palabras:
Los átomos son elementos de la interfaz de usuario que no se pueden dividir más
y sirven como bloques de construcción elementales de una interfaz.
Las moléculas son conjuntos de átomos que forman átomos relativamente
componentes de la interfaz de usuario.
Los organismos son componentes relativamente complejos que forman
secciones discretas de una interfaz.
Las plantillas colocan componentes dentro de un diseño y demuestran
la estructura de contenido subyacente del diseño.
Las páginas aplican contenido real a las plantillas y articulan variaciones para
demostrar la interfaz de usuario final y probar la resistencia del sistema de diseño.
Ventajas del diseño atómico
Entonces, ¿por qué pasar por todo este galimatías? ¿Para qué sirve el diseño atómico?
Estas son preguntas válidas, considerando que hemos estado construyendo
interfaces de usuario durante mucho tiempo sin contar con una metodología explícita
de cinco etapas. Pero el diseño atómico nos brinda algunas ideas clave que nos
ayudan a crear sistemas de diseño de interfaz de usuario deliberados y más efectivos.
La parte y el todo
Una de las mayores ventajas que ofrece el diseño atómico es la capacidad de cambiar
rápidamente entre lo abstracto y lo concreto. Podemos ver simultáneamente nuestras
interfaces divididas en sus elementos atómicos y también ver
cómo esos elementos se combinan para formar nuestras experiencias finales.
El diseño atómico permite a los diseñadores transitar entre lo abstracto y lo concreto.
En su libro The Shape of Design, Frank Chimero articula maravillosamente el poder que
proporciona este recorrido:
El pintor, cuando está lejos del caballete, puede evaluar y analizar el
conjunto de la obra desde este punto de vista. Escudriña y escucha, elige
el siguiente trazo a realizar, luego se acerca al lienzo para realizarlo. Luego,
vuelve a dar un paso atrás para ver lo que ha hecho en relación con el
todo. Es una danza de contextos cambiantes, un ritmo de golpeteo a través
del suelo del estudio que produce un bucle de retroalimentación estrecho
entre la creación de calificaciones y la evaluación de calificaciones.
Frank Quimero
56 DISEÑO ATÓMICO
El diseño atómico nos permite bailar entre contextos como el pintor Frank
describe tan elocuentemente. Los átomos, moléculas y organismos que
componen nuestras interfaces no viven en el vacío. Y las plantillas y páginas
de nuestras interfaces están compuestas de partes más pequeñas. Las
partes de nuestros diseños influyen en el todo, y el todo influye en las partes.
Los dos están entrelazados, y el diseño atómico acepta este hecho.
Cuando los diseñadores y desarrolladores están creando un componente en
particular, somos como el pintor en el lienzo creando trazos detallados.
Cuando estamos viendo esos componentes en el contexto de un diseño con
contenido representativo real en su lugar, somos como el pintor a varios pies
del lienzo evaluando cómo sus trazos detallados afectan toda la composición.
Es necesario concentrarse en un componente en particular para garantizar
que sea funcional, usable y hermoso. Pero también es necesario asegurarse
de que el componente sea funcional, usable y atractivo en el contexto de la
interfaz de usuario final.
El diseño atómico nos brinda una estructura para navegar entre las partes y
la totalidad de nuestras interfaces de usuario, por lo que es crucial reiterar
que el diseño atómico no es un proceso lineal. Sería una tontería diseñar
botones y otros elementos de forma aislada, luego cruzar los dedos y esperar
que todo se una para formar un todo cohesivo. Así que no interprete las
cinco etapas del diseño atómico como “Paso 1: átomos; Paso 2: moléculas;
Paso 3: organismos; Paso 4: plantillas; Paso 5: páginas.” En su lugar, piense
en las etapas del diseño atómico como un modelo mental que nos permite
crear simultáneamente interfaces de usuario finales y sus sistemas de
diseño subyacentes.
Clara separación entre estructura y contenido.
Hablar de diseño y contenido es un poco como hablar del huevo y la gallina.
Mark Boulton explica:
El contenido debe estar estructurado y la estructuración altera
su contenido, el diseño altera el contenido. No es 'contenido luego
diseño', o 'contenido o diseño'. Es 'contenido y diseño'.
Mark Boulton
Un sistema de diseño bien diseñado se adapta al contenido que vive dentro de él, y el
contenido bien diseñado es consciente de cómo se presenta en el contexto de una
interfaz de usuario. Los patrones de interfaz que establezcamos deben reflejar con
precisión la naturaleza del texto, las imágenes y otros contenidos que viven dentro de
ellos. Del mismo modo, nuestro contenido debe ser consciente de la forma en que se
presentará. La estrecha relación entre el contenido y el diseño requiere que tengamos en
cuenta ambos cuando construimos nuestras interfaces de usuario.
El diseño atómico nos brinda un lenguaje para discutir la estructura de nuestros
patrones de interfaz de usuario y también el contenido que se encuentra dentro de esos patrones.
Si bien existe una clara separación entre el esqueleto de la estructura del contenido
(plantillas) y el contenido final (páginas), el diseño atómico reconoce que los dos se
influyen mucho entre sí. Por ejemplo, tome el siguiente ejemplo:
A la izquierda vemos el esqueleto de contenido de la interfaz de usuario, que consiste
en la misma molécula de bloque de persona repetida una y otra vez. A la derecha
vemos lo que sucede cuando completamos cada instancia de la molécula de bloque de
persona con contenido representativo. Visualizar el esqueleto del contenido y el contenido
final representativo nos permite crear patrones que reflejan con precisión el contenido que
vive dentro de ellos. Si el nombre de una persona se envolviera en cinco líneas dentro del
patrón, necesitaríamos abordar ese comportamiento roto en un nivel más atómico.
58 DISEÑO ATÓMICO
El contenido que vertemos en nuestras interfaces de usuario en la etapa de página
influirá en las características y parámetros de los patrones de diseño subyacentes.
¿Lo que hay en un nombre?
A lo largo de este libro he mencionado que el diseño y desarrollo modular no
es nada nuevo. Entonces, ¿por qué estamos introduciendo términos como átomos,
moléculas y organismos cuando podemos ceñirnos a términos establecidos como
módulos, componentes, elementos, secciones y regiones?
Durante todo el tiempo que he estado hablando sobre el diseño atómico, la gente ha
dado nombres alternativos para las etapas de la metodología. La Persona Uno
sugeriría: "¿Por qué no simplemente nombrarlos elementos, módulos y componentes?"
mientras que la Persona Dos sugeriría, "¿Por qué no simplemente nombrarlos base,
componentes y módulos?" El problema con términos como componentes y módulos
es que no se puede deducir un sentido de jerarquía solo de los nombres. Los átomos,
las moléculas y los organismos implican una jerarquía que cualquier persona con
conocimientos básicos de química puede entender.
Dicho esto, nombrar las cosas es difícil e imperfecto. Los nombres que he elegido
para las etapas del diseño atómico han funcionado muy bien para mí y para los
equipos con los que he trabajado mientras creamos sistemas de diseño de interfaz de
usuario. Pero tal vez no funcionen para usted y su organización. Eso está más que
bien. Aquí hay una perspectiva del equipo de diseño de GE:
Cuando mostramos nuestros conceptos de sistemas de diseño iniciales que
usaban la taxonomía de diseño atómico a nuestros colegas, nos encontramos
con algunas miradas confundidas. […] La evidencia fue clara, para que esto
tuviera éxito dentro de nuestra organización, teníamos que hacer que la
taxonomía fuera más accesible.
Jef Crossman, diseño de GE
La taxonomía en la que aterrizó el equipo fue "Principios", "Conceptos básicos",
"Componentes", "Plantillas", "Características" y "Aplicaciones". ¿Estas etiquetas
tienen sentido para usted? No importa. Al establecer una taxonomía que tenía
sentido para su organización, todos pudieron incorporarse a los principios del
diseño atómico y trabajar juntos de manera eficaz.
El "diseño atómico" como palabra de moda encapsula los conceptos de
diseño y desarrollo modular, lo que se convierte en una abreviatura útil para
convencer a las partes interesadas y hablar con colegas.
Pero el diseño atómico no es un dogma rígido. En última instancia, cualquier
taxonomía con la que elija trabajar debería ayudarlo a usted y a su
organización a comunicarse de manera más efectiva para crear un sistema de
diseño de interfaz de usuario increíble.
El diseño atómico es para interfaces de usuario.
El diseño atómico es un concepto nacido de la web. Después de todo, su humilde
autor es un diseñador web, que es principalmente la razón por la que este libro
se centra principalmente en las interfaces basadas en web. Pero es importante
comprender que el diseño atómico se aplica a todas las interfaces de usuario, no
solo a las basadas en la web.
Puedes aplicar la metodología de diseño atómico a la interfaz de usuario de cualquier
software: Microsoft Word, Keynote, Photoshop, el cajero automático de tu banco, lo
que sea. Para demostrarlo, apliquemos el diseño atómico a la aplicación móvil nativa
Instagram.
Diseño atómico aplicado a la aplicación móvil nativa Instagram.
60 DISEÑO ATÓMICO
Recorramos esta interfaz atomizada de Instagram:
Átomos: esta pantalla de la interfaz de usuario de Instagram consta de un puñado
de iconos, algunos elementos a nivel de texto y dos tipos de imágenes: la imagen
principal y la imagen del avatar del usuario.
Moléculas: varios íconos forman componentes utilitarios simples
como la barra de navegación inferior y la barra de acciones de fotos donde los
usuarios pueden dar me gusta o comentar una foto. Además, las combinaciones simples
de texto y/o imágenes forman componentes relativamente simples. Organismos: Aquí
podemos ver tomar forma al foto organismo,
que consta de la información del usuario, la marca de tiempo, la foto en sí, las acciones
en torno a esa foto y la información sobre la foto, incluido el número de Me gusta y el
pie de foto. Este organismo se convierte en la piedra angular de toda la experiencia de
Instagram, ya que se apila repetidamente en un flujo interminable de fotos generadas
por los usuarios.
Plantillas: podemos ver cómo nuestros componentes se unen en el contexto de un
diseño. Además, es aquí donde vemos el esqueleto de contenido expuesto de la
experiencia de Instagram, destacando el contenido dinámico como el identificador del
usuario, el avatar, la foto, el recuento de Me gusta y el título.
Páginas: Y finalmente vemos el producto final, completo con
contenido vertido en él, lo que ayuda a garantizar que el sistema de diseño subyacente
se una para formar una interfaz de usuario hermosa y funcional.
Muestro este ejemplo no web porque el diseño atómico tiende a malinterpretarse como
un enfoque de tecnologías específicas de la web como CSS y JavaScript. Permítanme
ser claro al respecto: el diseño atómico no tiene nada que ver con temas específicos de
la web como CSS o la arquitectura JavaScript. En el capítulo 1 discutimos la tendencia
hacia la modularidad en todos los aspectos del diseño y desarrollo, que incluye CSS y
JavaScript. Estas son tendencias fantásticas en CSS y JavaScript, pero el diseño atómico se
ocupa de crear sistemas de diseño de interfaz de usuario, independientemente de la
tecnología utilizada para crearlos.
Diseño atómico en teoría y en la práctica
Este capítulo presentó la metodología de diseño atómico y demostró cómo
los átomos, las moléculas, los organismos, las plantillas y las páginas trabajan
juntos para crear sistemas de diseño de interfaz deliberados y reflexivos. El diseño
atómico nos permite ver nuestras interfaces de usuario desglosadas en sus elementos
atómicos y también nos permite ver simultáneamente cómo se unen esos elementos
para formar nuestras interfaces de usuario finales. Aprendimos sobre el estrecho
vínculo entre el contenido y el diseño, y cómo el diseño atómico nos permite crear
sistemas de diseño que se adaptan al contenido que vive dentro de ellos. Y, finalmente,
aprendimos cómo el lenguaje del diseño atómico nos brinda una forma abreviada útil
para discutir la modularidad con nuestros colegas y proporciona un sentido de jerarquía
muy necesario en nuestros sistemas de diseño.
El diseño atómico es una metodología útil de diseño y desarrollo, pero esencialmente
es simplemente un modelo mental para construir una interfaz de usuario. A estas
alturas, es posible que se esté preguntando cómo hace que suceda el diseño atómico.
Bueno, querido lector, no tema, porque el resto del libro se centra en las herramientas
y los procesos para hacer realidad sus sueños de diseño atómico.
62 DISEÑO ATÓMICO
Capítulo 3
Herramientas del oficio
Pattern Lab y las cualidades de las
guías de estilo efectivas
En el capítulo anterior, introduje la metodología de diseño atómico
para construir interfaces de usuario. Espero que encuentre que el diseño atómico
es un modelo mental útil para construir sistemas de diseño de interfaz de usuario,
pero ahora es el momento de bajar de la torre de marfil y poner en práctica el
diseño atómico en el mundo real.
La piedra angular del diseño y desarrollo basado en patrones es la biblioteca de
patrones, que sirve como un centro centralizado de todos los componentes de la
interfaz de usuario que componen su interfaz de usuario. Como discutimos en el
capítulo 1, los benefcios de las bibliotecas de patrones son muchos:
Promueven la coherencia y la cohesión a lo largo de toda la experiencia.
Agilizan el flujo de trabajo de tu equipo, ahorrando tiempo y dinero.
Establecen un flujo de trabajo más colaborativo entre todos
disciplinas involucradas en un proyecto.
Establecen un vocabulario compartido entre todos en un
organización, incluidos los proveedores externos.
Brindan documentación útil para ayudar a educar a las partes
interesadas, a los colegas e incluso a terceros.
Hacen que los navegadores/dispositivos cruzados, el rendimiento y
prueba de accesibilidad más fácil.
Sirven como una base amigable para el futuro para que los equipos modifiquen,
ampliar y mejorar con el tiempo.
Todo eso suena maravilloso, ¿verdad? Casi puedo oírte decir: "Necesito toda
esta cosa de la biblioteca de patrones en mi vida". Pero, ¿cómo hacemos que
sucedan las bibliotecas de patrones? Bueno, has venido al lugar correcto, amigo,
porque el resto de este libro está dedicado exactamente a eso. Este capítulo
presentará herramientas útiles para crear bibliotecas de patrones, el próximo
capítulo discutirá cómo hacer que los patrones sean la piedra angular de su flujo
de trabajo de diseño y desarrollo, y el quinto capítulo cubrirá cómo hacer que su
sistema de diseño resista el paso del tiempo.
Este capítulo hablará sobre las cualidades de las bibliotecas de patrones
efectivas a través de la lente de una herramienta llamada Pattern Lab, un
proyecto de código abierto mantenido por los desarrolladores web Dave Olsen,
CAPÍTULO 3 / HERRAMIENTAS DEL OFICIO 65
Brian Muenzenmeyer, y yo para ejecutar sistemas de diseño atómico.
Si bien hablaré con entusiasmo de Pattern Lab y sus diversas funciones, quiero enfatizar
que el objetivo de este capítulo es cubrir las características de las bibliotecas de patrones
bien construidas, no venderle ninguna herramienta específica. ¡Diablos, Pattern Lab ni
siquiera está a la venta! Ninguna herramienta única será perfecta para cada configuración
y escenario, pero asegúrese de tener en cuenta los siguientes principios al decidir qué
herramientas usar para crear sus bibliotecas de patrones.
¿Qué es exactamente Pattern Lab?
Antes de sumergirnos en los aspectos prácticos de cómo funciona Pattern Lab, es importante
tomarse un tiempo para explicar qué es y qué no es la herramienta.
El laboratorio de patrones es...
una herramienta generadora de sitios estáticos para construir sistemas de diseño atómico.
una herramienta de documentación y anotación de patrones.
un kit de inicio de patrones.
Pattern Lab no es...
un marco de interfaz de usuario como Bootstrap o Foundation.
depende del idioma, la biblioteca o el estilo. un reemplazo
para un sistema de gestión de contenido.
Repasemos estos puntos, comenzando con el término generador de sitios estáticos. Las
herramientas de generación de sitios estáticos toman algunos códigos fuente y activos, los
compilan y escupen HTML, CSS y JavaScript simples en el otro extremo. Pattern Lab toma
el código fuente, es decir, los patrones, y compila esos patrones en una interfaz de usuario
frontal funcional dentro de un shell de biblioteca de patrones.
Entonces, ¿cómo se ve Pattern Lab listo para usar? Redoble de tambores por favor.
66 DISEÑO ATÓMICO
Un tablero predeterminado de Pattern Lab. Lo que le falta en buena apariencia, lo compensa en utilidad.
No es un diseño terriblemente inspirador, ¿eh? Lo creas o no, este diseño mínimo
(incluso podría decirse que falta ) es deliberado. Para evitar una clasificación
incorrecta como un marco de interfaz de usuario como Bootstrap, el diseño se
simplifica deliberadamente para que nadie tome por error la interfaz de usuario de
demostración de Pattern Lab para los estilos sugeridos. Pattern Lab no le da ninguna
respuesta sobre cómo diseñar o diseñar su código frontend; tiene que hacer todo
ese trabajo usted mismo. La apariencia, las convenciones de nomenclatura, la
sintaxis, la estructura, las bibliotecas y los scripts que elija usar para crear su interfaz
de usuario dependen totalmente de usted y su equipo. Diablos, incluso puedes usar
marcos de interfaz de usuario como Bootstrap dentro de Pattern Lab.
Pattern Lab está ahí para ayudar a unir todo.
Como un aparte técnico, Pattern Lab usa PHP o Node.js como el motor que une
los patrones y genera la biblioteca de patrones. Sin embargo, no necesita ser un
asistente de PHP o un gurú de Node.js para usar Pattern Lab, como tampoco
necesita saber cómo construir un motor de combustión interna para conducir un
automóvil. Además, su sitio web final no tiene que estar construido con PHP o
Node.js para usar la herramienta, ya que la salida de Pattern Lab es HTML, CSS y
JavaScript independiente del backend. Entonces, como cualquier decisión
tecnológica, elija una biblioteca de patrones
herramienta que se adapta a la infraestructura de su organización y se adapta a la
forma en que su equipo trabaja en conjunto.
Si todo eso te sonó como un galimatías, no te preocupes. Este capítulo se centra en
las características generales de Pattern Lab y los principios de las bibliotecas de
patrones eficaces en lugar de ir demasiado lejos por el agujero del conejo técnico. Si
está interesado, puede consultar la documentación de Pattern Lab. sumergirse en el
meollo del asunto.
Construyendo sistemas de diseño atómico con Pattern Lab
Para comprender el concepto central detrás de Pattern Lab, debe comprender las
muñecas de anidación rusas.
Muñecas rusas de anidación. Crédito de la imagen: S. Faric en Flickr
Las muñecas Matryoshka (también conocidas como muñecas rusas de
anidación) son muñecas de madera hueca bellamente talladas de tamaño creciente
que se colocan una dentro de otra. Los patrones en Pattern Lab funcionan de manera
similar: los patrones más pequeños (átomos) se incluyen dentro de patrones más
grandes (moléculas), que se incluyen en patrones aún más grandes (organismos),
que a su vez se incluyen en patrones aún más grandes (plantillas).
68 DISEÑO ATÓMICO
Construir interfaces de usuario de esta manera mantiene las cosas
SECAS, que es un principio informático de larga data que significa "no
te repitas". Lo que esto significa es que puede realizar un cambio en un
patrón, y en cualquier lugar que se emplee ese patrón se actualizará
mágicamente con esos cambios. Este enfoque de muñeca rusa anidada
acelera considerablemente su flujo de trabajo y, sin duda, es mejor que
examinar cientos de documentos de Photoshop para cada instancia de un
patrón con el fin de realizar un cambio simple.
Para que esto suceda, Pattern Lab utiliza la función de inclusión de
Moustache, un lenguaje de plantillas sin lógica. Así es como se ve una
inclusión de bigote:
{{> miniatura de átomo }}
Este es el código de bigote, en caso de que las llaves dobles ({{}}) que
parecen pequeños bigotes no lo delaten. El símbolo mayor que (>) es la
forma que tiene Moustache de decirle a Pattern Lab que incluya un patrón
atómico llamado "miniatura". Pattern Lab buscará en sus carpetas de
patrones para encontrar un átomo llamado "miniatura".
Este es el aspecto que puede tener la estructura de carpetas de patrones de
Pattern Lab. Puede nombrar y categorizar estas carpetas como desee, incluso
cambiando las etiquetas "átomos", "moléculas" y "organismos", "plantillas" y
"páginas". La consideración más importante es establecer nombres y
categorizaciones que sean más efectivos para su equipo.
Ahora que sabemos cómo se ve un include, pongámoslo en práctica y echemos
un vistazo a algunos patrones de un sitio web que ayudé a crear para Time Inc. Aquí
hay un patrón reutilizable que diseñamos:
Para el sitio web de Time Inc., creamos una molécula de bloque básica que consiste en una imagen en
miniatura, un titular y un extracto.
Este patrón debería parecer bastante familiar. Una imagen en miniatura, un
título y un extracto trabajando juntos como una sola unidad es un patrón común que se
encuentra en innumerables sitios web. Echemos un vistazo detrás de la cortina para ver
cómo se construye este patrón.
70 DISEÑO ATÓMICO
<div class="bloquear publicación">
<a href="{{ URL }}">
{{> átomospulgar }}
<h3>{{ título }}</h3>
<p>{{ extracto }}</p> </a>
</div>
Puede ver que tenemos: marcado HTML que consiste en un contenedor div con un
nombre de clase de blockpost; un enlace; un bigote incluido para la imagen en miniatura;
un elemento <h3> para el título; y una etiqueta <p> para el extracto. Notará que hay más
código Moustache para la URL, el título y el extracto, que usaremos más adelante para
intercambiar dinámicamente el contenido real. Más sobre esto en un momento.
Ahora que nuestro marcado de patrón está establecido, podemos incluir ese trozo de
código en patrones más grandes usando el mismo método de inclusión:
{{> moléculasbloquepost }}
Ahora pasemos a organismos más complejos como el encabezado del sitio web, que
se parece a esto:
El encabezado del sitio web consta de convenciones bastante comunes, como un átomo de logotipo, una molécula de navegación
principal y una molécula de formulario de búsqueda.
Cuando abrimos el capó para ver el marcado del encabezado en
Pattern Lab, vemos lo siguiente:
<encabezado rol="bandera">
{{> átomoslogo }} {{>
moléculasprimarynav }}
{{> búsqueda de moléculas}}
</encabezado>
¿Que está pasando aqui? Bueno, tenemos un elemento <header> básico, y
dentro de ese elemento incluimos el átomo de la imagen del logotipo, la molécula
de navegación principal y la molécula del formulario de búsqueda.
Y ahora podemos incluir ese patrón relativamente complejo en cualquier lugar que lo
necesitemos.
{{> organismosencabezado}}
Espero que ahora puedas ver las muñecas rusas en acción.
Los átomos más pequeños se incluyen en moléculas más grandes, y esas
moléculas se incluyen en organismos aún más grandes. Ahora tomemos estos
componentes y conéctelos a un diseño. Tome la plantilla de la página de inicio, por
ejemplo:
72 DISEÑO ATÓMICO
La plantilla de la página de inicio de Time Inc. consta de algunos patrones repetibles: un encabezado
global, un área principal, algunas secciones (que contienen una imagen, un título, un extracto y un
llamado a la acción), un área con cuatro elementos, un área factoide y un pie de página global.
Dé un rápido paseo por la plantilla de la página de inicio y verá algunos
patrones bastante estándar: un encabezado del sitio en la parte superior, un pie
de página del sitio en la parte inferior y un área de héroe de pantalla completa.
También verá algunos otros patrones que se repiten a lo largo de la plantilla.
Entonces, ¿cómo se ve esto en el código? Como era de esperar, ¡involucra
más inclusiones!
< rol principal="principal">
{{# héroe }}
{{> moléculashéroe}}
{{/héroe}}
<sección>
{{# bloque de experiencia }}
{{> moléculasbloqueprincipal}}
{{/ bloque de experiencia }} {{#
característica de experiencia }}
{{> organismoshistoriacaracterística }} {{/
experienciacaracterística }}
</sección>
<sección>
{{# publicidad factoide }}
{{> organismosfactoide }}
{{/publicidad factoide}} </sección>
<sección>
{{# publicidad }}
{{> moléculasbloqueprincipal }} {{/
publicidad }}
</sección>
...
</principal>
{{> organismospie de página}}
En esta etapa del juego, los patrones más pequeños ya están construidos,
por lo que todo lo que la plantilla debe hacer es colocarlos en el contexto de un diseño
de página y darles nombres únicos.
74 DISEÑO ATÓMICO
Echando un vistazo más de cerca al código, observe que ciertos patrones como
{{>organistsheader}} y {{>organistsfooter}} se incluyen de la misma manera que los
ejemplos anteriores. Pero también hay algunos otros patrones incluidos que se
complementan con información adicional, como la siguiente:
{{# publicidad factoide }}
{{> organismosfactoide }} {{/ factoide
publicidad }}
Incluimos los organismosfactoide de la misma manera que todos los demás
patrones, pero también lo llamamos publicidadfactoide envolviendo el incluir en
una sección de bigote , indicado por el código de bigote que contiene los símbolos
# y /. Al darle a la instancia del patrón un nombre único, podemos aferrarnos a él y
reemplazar dinámicamente el contenido del patrón. ¡Más sobre eso en la siguiente sección!
Este enfoque de muñeca rusa anidada para construir interfaces de usuario es
simple pero tremendamente poderoso. La estructura permite a los diseñadores y
desarrolladores mantener los patrones SECOS, ahorrando tiempo, esfuerzo y dinero.
El enfoque permite a los equipos crear una interfaz de usuario final mientras crean
simultáneamente el sistema de diseño de interfaz de usuario subyacente. Después de todo,
la interfaz final es una instanciación de su sistema de diseño subyacente. Los equipos
también pueden moverse entre lo abstracto y lo concreto, enfocándose en un patrón
particular para corregir errores ("¡El encabezado está roto!"), mientras ven cómo los
cambios en los patrones pequeños afectan el diseño general de la página.
Trabajar con datos dinámicos
Es importante articular la estructura de contenido subyacente de los patrones de
IU dentro del contexto de una biblioteca de patrones. Es por eso que hemos
estado buscando imágenes en escala de grises que muestren dimensiones y texto
de marcador de posición que contenga límites de caracteres. Pero si bien esta
información es útil para los equipos creativos, las imágenes en escala de grises y el texto
de Lorem ipsum no son con lo que los usuarios interactúan en su sitio real. Necesitamos
una forma de reemplazar nuestro contenido ficticio con contenido representativo real para
garantizar que nuestros patrones de interfaz de usuario coincidan con la realidad del
contenido que vive dentro de ellos.
Para demostrar cómo Pattern Lab cambia dinámicamente contenido real en plantillas,
echemos un vistazo a una comparación lado a lado de la plantilla de página de inicio y los
niveles de página de Time Inc.:
Una comparación lado a lado de la plantilla de página de inicio y los niveles de página de Time Inc. La
plantilla articula la estructura de contenido del sistema de diseño, mientras que la página muestra cómo se ve el
sistema con el contenido real que muestra.
76 DISEÑO ATÓMICO
A la izquierda tenemos el nivel de plantilla, que articula la estructura de contenido de
los patrones que componen la página web. Y a la derecha tenemos el nivel de la
página, donde vertemos contenido representativo real para demostrar cómo se vería
la interfaz de usuario final y probar la efectividad del sistema de diseño.
¿Cómo intercambiamos contenido ficticio por contenido real en Pattern Lab?
Pattern Lab usa JSON (así como YAML, Markdown y otros formatos de datos)
para defnir e intercambiar las partes dinámicas de contenido en nuestros diseños.
Los datos de marcador de posición predeterminados se defnen en un archivo llamado data.json
que se encuentra en el directorio /source de Pattern Lab . Dentro de este archivo definimos
todo el texto, las rutas de las imágenes y otros datos dinámicos que conformarán nuestra interfaz
de usuario. Aquí hay una pequeña muestra del archivo data.json de Time Inc .:
"héroe" : {
"titular": "Lorem Ipsum", "img": { "src": "/
images/sample/fpo_hero.png", "alt":
"Imagen de héroe"
}
}
Para los desarrolladores, este tipo de formato probablemente les resulte familiar.
Si no eres desarrollador, ¡no te asustes! Una vez que mire más allá de las llaves y
las comillas, verá que estamos definiendo un objeto de héroe (para el área de héroe
de sangrado completo directamente debajo del encabezado) que tiene un valor de
título de "Lorem Ipsum" y un img con un valor src de “/images/sample/fpo_hero.png”.
Simplemente estamos definiendo los atributos de este objeto y proporcionando
valores para esos atributos.
Una vez que esos objetos están definidos, podemos anular sus atributos
en el nivel de página de Pattern Lab. Esto se logra mediante la creación de un
nuevo archivo JSON que coincida con el nombre del patrón de página (para
la página de inicio de Time Inc., lo llamaremos 00homepage.json) dentro del
directorio /pages.
Dentro del directorio 'pages' tenemos el patrón de la página de inicio, así como un archivo JSON que
coincide con el nombre del patrón. Aquí es donde anularemos el contenido predeterminado con
contenido específico de la página.
Cuando abrimos 00homepage.json, podemos anular los datos de marcador de posición
que establecimos anteriormente. Así es como podría verse:
"héroe" : {
"headline": "Personas en movimiento",
"img": {
"src": "/images/hero_beyonce.jpg",
"alt": "Beyoncé"
}
}
Al anular los datos predeterminados, el titular del héroe ahora dice "Personas
en movimiento" en lugar de "Lorem Ipsum". Y en lugar de apuntar a una imagen
de héroe en escala de grises solo para ubicación (FPO), ahora estamos apuntando
a una imagen de Beyoncé ubicada en "/images/ hero_beyonce.jpg".
78 DISEÑO ATÓMICO
Este proceso de establecer valores predeterminados para los datos
dinámicos y luego reemplazarlos con contenido específico de la página continúa
para cada sección del sitio web. Además de reemplazar cadenas simples como
encabezados, también podemos establecer dinámicamente variables en verdadero
o falso, recorrer una serie de elementos y más. Incluso podemos alterar drásticamente
la interfaz de usuario con solo unos pocos cambios en un archivo JSON, del que
hablaremos a continuación.
Articulación de variaciones de
patrón con pseudopatrones
Históricamente, los diseñadores que trabajan con herramientas estáticas
han tenido una tendencia a diseñar solo los mejores escenarios. Sabes de lo que
estoy hablando: el nombre del usuario es Sara Smith y siempre encaja perfectamente
en una línea; su foto de perfil parece sacada de una revista; su perfil está
completamente lleno; las dos columnas del contenido de su perfil tienen exactamente
la misma altura.
Por supuesto, estos mejores escenarios rara vez ocurren en el mundo real.
Para crear diseños más robustos y resistentes, debemos tener en cuenta
simultáneamente las mejores y las peores situaciones, y todo lo demás.
¿Qué pasa si el usuario no sube una foto de perfil? ¿Qué sucede si el usuario
tiene 87 artículos en su carrito de compras? ¿Qué pasa si el producto tiene 14
opciones? ¿Qué sucede si el título de la publicación del blog contiene 400 caracteres?
¿Qué pasa con un usuario que regresa? ¿Usuario primerizo? ¿Qué pasa si el artículo
no tiene comentarios? ¿Qué pasa si tiene siete capas de comentarios anidados?
¿Qué pasa si necesitamos mostrar un mensaje urgente en el tablero?
Articular estas variaciones de la interfaz de usuario en una herramienta de diseño
estático es un ejercicio de tedio y redundancia, lo que puede explicar por qué rara vez
se diseñan. Pero si queremos crear sistemas que aborden todas las variables y
realidades de nuestro contenido, debemos tener en cuenta esas preguntas de 'qué
pasaría si'.
¿Cómo abordamos todo tipo de variación de la interfaz de usuario sin agotarse en el
proceso? Pseudopatrón de Pattern Lab característica
nos permite articular escenarios a veces muy diferentes con solo unos pocos cambios
en nuestros datos.
Digamos que estamos creando una aplicación cuyo tablero muestra una lista
de colaboradores del proyecto. La interfaz de usuario podría verse así:
Una lista de colaboradores del proyecto en
nuestra aplicación hipotética.
Para crear el contenido dinámico dentro de cada uno de estos bloques,
definiremos nuestra lista de colaboradores como una matriz dentro de dashboard.json:
"colaboradores": [
{
"img": "/images/muestra/avatar1.jpg",
"nombre": "Steve Boomshakalaka",
"título": "CIA"
},
{
"img": "/images/sample/avatar2.jpg", "name": "Gingersnap
JujubeesDaniels",
"title": "Presidente de la empresa más longeva
Nombre en la Corporación Mundial, División Global"
},
{
"nombre": "Sarunus Marciulionis",
"título": "Guerreros del Estado Dorado"
},
{
80 DISEÑO ATÓMICO
"nombre" : "Sara Smith",
"título" : "Título corto"
}
]
De manera predeterminada, nuestro diseño asume que el usuario es un usuario normal
y no un administrador, pero ¿qué pasaría si quisiéramos brindarles a los administradores
la capacidad de administrar a los colaboradores del proyecto desde el tablero? Esa interfaz
de usuario podría verse así:
La interfaz de usuario del panel del
administrador presenta acciones adicionales
de edición y eliminación.
Para mostrar acciones adicionales de edición y eliminación de administradores en el tablero
en Pattern Lab, podemos crear un pseudopatrón, un nuevo archivo en la carpeta /
pages que se ve así:
tablero ~ admin.json
El símbolo de tilde (~) indica un pseudopatrón. dashboard~admin.json heredará todos los
datos contenidos en dashboard.json, pero también nos da la oportunidad de agregar o anular
datos adicionales. Eso significa que la lista de colaboradores que definimos anteriormente en
dashboard.json todavía está disponible, pero podemos agregar datos adicionales dentro de
dashboard~admin.json así:
"esAdmin" : verdadero
Estamos definiendo una variable llamada isAdmin y estableciéndola en verdadero.
Ahora podemos usar eso para incluir condicionalmente las acciones adicionales dentro del
patrón de bloque.
<div clase="bloque">
<img src="{{ img }}" alt="{{ nombre }}" /> <h3>{{ nombre }}</h3>
<h4>{{ título }}</h4>
{{# es administrador }}
{{> moléculasbloquearacciones }}
{{/ es administrador }}
</div>
Las primeras líneas muestran la imagen, el nombre y el título que definimos en
dashboard.json. Pero preste mucha atención a lo que se incluye en la sección isAdmin
Mustache. Lo que estamos diciendo aquí es: si isAdmin se establece en verdadero, incluya
un patrón de molécula llamado acciones de bloque. El patrón de acciones de bloque
contiene los botones de edición y eliminación, y solo se mostrará si isAdmin se establece en
verdadero (o cualquier cosa además de falso). En nuestro dashboard.json predeterminado,
isAdmin no está configurado, por lo que no se mostrarán las acciones adicionales. En
dashboard~admin.json, estamos configurando isAdmin en verdadero para que se muestren
las acciones adicionales. Puede extender esta técnica para alterar drásticamente toda la
interfaz de usuario (como alterar la navegación principal, mostrar paneles adicionales en el
tablero, agregar controles adicionales, etc.) simplemente cambiando una sola variable.
Cosas poderosas, de hecho.
Uf. Si has llegado hasta aquí, ¡felicidades! Ahora sabe cómo agregar y manipular
datos dinámicos en Pattern Lab.
La capacidad de Pattern Lab para diseñar con datos dinámicos brinda algunos
beneficios cruciales:
Crea una clara separación entre estructura y contenido. La estructura de un patrón
y su contenido se influyen mucho entre sí. Sin embargo, los sistemas de diseño
resilientes se esfuerzan por establecer patrones agnósticos y flexibles que pueden
contener una variedad de contenido.
Separar la estructura del patrón y los datos nos permite mantener las cosas SECAS
(que, de nuevo, significa no repetirse) y realizar cambios en el contenido sin afectar
la estructura del patrón.
Del mismo modo, podemos realizar cambios en un patrón sin tener que
actualizar cada instancia de ese patrón simplemente porque cada instancia contiene
datos diferentes. Esta separación da como resultado un gran ahorro de tiempo y
esfuerzo. Establece un CMS ad hoc. Establecimiento predeterminado y página
los datos específcos sirven como un sistema de administración de contenido ad hoc.
82 DISEÑO ATÓMICO
Como se mencionó anteriormente, las herramientas de diseño estático no están bien
equipadas para manejar datos dinámicos, pero también es excesivo instalar WordPress,
Drupal o algún otro CMS solo para demostrar las variaciones de la interfaz de usuario.
Pattern Lab logra un equilibrio ya que permite que los equipos trabajen
con datos dinámicos pero no requiere configurar ninguna base de datos MySQL
loca.
Sirve como modelo para los desarrolladores de backend responsables de integrar la
interfaz de usuario de frontend en un sistema de administración de contenido real. Los
desarrolladores de backend pueden mirar la interfaz de usuario creada en Pattern Lab,
comprender qué bits son estáticos y dinámicos y luego traducirlos al sistema de backend.
Permite que escritores, personas de contenido, diseñadores y otras personas que
no son desarrolladores contribuyan al sistema de diseño que vive y respira. Como
desarrollador frontend, no puedo contar la cantidad de veces que tuve que corregir
errores tipográficos, intercambiar nuevas imágenes, traducir cubiertas de copias y realizar
otras ediciones relacionadas con el contenido del código frontend.
Es la muerte por un millón de cortes de papel, y estoy seguro de que la mayoría de los
desarrolladores estarían de acuerdo en que hacer cambios menores en las copias no es
un uso efectivo de su tiempo. Al separar la estructura y los datos, Pattern Lab permite que
los miembros del equipo que no son desarrolladores administren de manera segura los
aspectos del diseño relacionados con el contenido, lo que libera a los desarrolladores para
que se centren en construir la estructura del sistema de diseño.
Ahora hemos cubierto la funcionalidad principal de Pattern Lab, ¡pero aún no hemos
terminado! A continuación, cubriremos algunas características adicionales que deben tenerse
en cuenta, independientemente de la herramienta que utilice para crear su biblioteca de
patrones.
Herramientas de ventana gráfica para patrones flexibles
La multitud de dispositivos que ahora acceden a la web ha obligado a los
diseñadores a volver a adoptar la fluidez intrínseca del medio.
Afortunadamente, técnicas como el diseño web receptivo nos permite crear diseños que se ven
y funcionan maravillosamente en cualquier pantalla.
Es obvio que necesitamos establecer patrones de interfaz de usuario flexibles si queremos
crear diseños receptivos, pero la creación de patrones fluidos tiene ventajas adicionales.
Cuanto más fluido es un componente de la interfaz de usuario, más resistente y versátil se
vuelve. Imagine poder tomar un componente, digamos un control deslizante de galería de
fotos, y colocarlo
en cualquier lugar que lo necesitemos. A veces, es posible que necesitemos que sea un
elemento de sangrado completo que ocupe toda la ventana gráfica. Otras veces puede que
necesitemos incluirlo en el contexto de un artículo. Y aún otras veces nos
puede querer incluirlo en la barra lateral. El sueño es construir nuestros componentes de
forma fluida y adaptarán sus estilos y funcionalidades para adaptarse a cualquier contenedor en el
que los coloquemos.
De hecho, esta es la promesa de las consultas de contenedores. Las consultas de contenedores
permiten que los elementos se adapten en función de sus contenedores principales en lugar
de toda la ventana gráfica, que es la forma en que manipulamos los elementos mediante
consultas de medios en este momento. Si bien aún se está desarrollando como una capacidad
nativa del navegador, las consultas de contenedores nos permitirán a los diseñadores y
desarrolladores enloquecidos por patrones crear e implementar fácilmente sistemas de interfaz de usuario Fuid.
Entre el diseño receptivo, las consultas de contenedores y el buen sentido común a la
antigua, ahora entendemos por qué es imperativo crear patrones de interfaz de usuario flexibles.
Pero cómo hacemos eso? ¿Y cómo pueden ayudarnos nuestras herramientas de biblioteca de
patrones a pensar y actuar con flexibilidad?
Muchas de las primeras herramientas de prueba de diseño receptivo se centraron en ver
diseños en anchos de dispositivos móviles populares, como 320 px (un iPhone 4 en modo
vertical), 480 px (un iPhone 4 en modo horizontal), 768 px (un iPad en modo vertical), etc. . Pero,
por supuesto, la web es mucho más diversa que una vista móvil, una vista de tableta y una vista de
escritorio.
Para ayudar a los diseñadores a considerar mejor todo el espectro de resolución al probar
sus diseños receptivos, creé una herramienta llamada ish.
La herramienta se llama ish. porque seleccionar el botón pequeño da como resultado una
ventana de visualización pequeña. Seleccionarlo de nuevo proporciona una ventana de
visualización pequeña diferente. Seleccionar el botón medio le da una ventana de visualización
mediana. Y el botón grande da como resultado una ventana de visualización grande. Estos
valores aleatorios ayudan a los diseñadores y desarrolladores a considerar mejor todo el espectro
de resolución en lugar de un puñado de dimensiones de dispositivos populares.
Ish. está integrado en Pattern Lab, lo que significa que podemos ver nuestras interfaces de usuario
y sus patrones subyacentes en todo el espectro de resolución.
Mientras que ish. ayuda a los diseñadores y desarrolladores a descubrir errores a lo largo del
continuo de la ventana gráfica, he descubierto que es más útil como herramienta educativa para
clientes y colegas. Al crear una herramienta de cambio de tamaño de la ventana gráfica
independiente del dispositivo directamente en la biblioteca de patrones, los clientes y los colegas
84 DISEÑO ATÓMICO
pueden llegar a apreciar el hecho de que su sistema de diseño debe verse y funcionar bien sin importar el tamaño de la
ventana gráfica.
Pattern Lab mostrando un diseño en una pequeña ventana gráfica.
Pattern Lab mostrando un diseño en una ventana gráfica mediana.
Pattern Lab mostrando un diseño en una ventana grande.
Un vistazo bajo el capó con vista de código
Una característica común de la biblioteca de patrones es la capacidad de mirar debajo del capó y
ver el código subyacente que conforma un componente en particular. Exponer el código de un
patrón de interfaz de usuario acelera el tiempo de desarrollo (me encanta copiar y pegar tanto como
al próximo codificador) y ayuda a los líderes de equipo a hacer cumplir la sintaxis del código y las
convenciones de estilo. Esto se vuelve especialmente gratificante cuando muchos desarrolladores
están trabajando en el código base de una organización.
Los tipos de código que se destacan en una biblioteca de patrones varían naturalmente de una
organización a otra, para cumplir con los requisitos de la amplia gama de entornos, tecnologías y
convenciones utilizadas. La mayoría de las bibliotecas de patrones disponibles en la naturaleza
demuestran el HTML subyacente de un patrón, mientras que otros también incluyen CSS y JavaScript
específicos del patrón. El sistema de diseño Lightning de Salesforce, por ejemplo, muestra el HTML
de un patrón, así como todo el (S)CSS relacionado con ese patrón.
86 DISEÑO ATÓMICO
El sistema de diseño Lightning de Salesforce muestra el código HTML y SCSS de los componentes de la interfaz de usuario.
Incluir el código frontend hace que los autores lo escriban de manera más consistente, pero eso no
garantiza la perfección. Todavía hay espacio para que los desarrolladores se vuelvan deshonestos y escriban
código descuidado e incongruente, razón por la cual algunas organizaciones han ido más allá para establecer sistemas
de diseño increíblemente sofisticados. Empresas como Lonely Planet han logrado el santo grial de las bibliotecas de
patrones, es decir, su biblioteca de patrones y el entorno de producción están perfectamente sincronizados. Discutiremos
el santo grial con más detalle en el capítulo 5, pero vale la pena mencionarlo en esta sección para demostrar cómo
afecta eso al código expuesto en el contexto de una biblioteca de patrones.
En lugar de ofrecer HTML y CSS, la guía de estilo Rizzo de Lonely Planet muestra el código de inclusión para que
los equipos extraigan el componente de interfaz de usuario adecuado.
La biblioteca de patrones del sistema de diseño Rizzo de Lonely Planet muestra el uso de la plantilla.
Esta configuración permite que el equipo central de desarrollo mantenga una única
fuente de verdad para el código de frontend de todos los patrones. Para que los
desarrolladores se pongan en marcha, la biblioteca de patrones solo necesita
proporcionar el código para incluir un patrón en particular.
Pattern Lab brinda la capacidad de ver tanto el código HTML subyacente de un patrón
como el código de plantilla utilizado para generar el HTML. También se puede ampliar
para mostrar el código CSS y JavaScript que lo acompaña.
La vista de código de Pattern Lab demuestra tanto el código de plantilla de un patrón como el HTML compilado.
En última instancia, cualquier herramienta de biblioteca de patrones que decida usar
debe tener algún tipo de vista de código. Quizás lo más importante es que las bibliotecas
de patrones que cree deben mostrar los tipos de código que le permiten a usted y a su
equipo de desarrollo ser lo más efectivos posible.
88 DISEÑO ATÓMICO
Documentación viva y anotaciones
En un proceso de diseño tradicional en silos, es típico ver largos documentos de estructura
alámbrica y especificaciones creados, debatidos y aprobados.
Estos documentos generalmente toman la forma de archivos PDF gigantes, lo cual es
desafortunado si se tiene en cuenta que a menudo contienen todo tipo de información valiosa,
instrucciones y documentación sobre el sistema de diseño.
Lamentablemente, estos artefactos voluminosos a menudo se arrojan a un bote de basura (virtual)
cuando el proyecto llega a la etapa de producción.
Este no debería ser el caso. La documentación de una interfaz de usuario debe contener
conocimientos de todas las disciplinas involucradas en su creación y, esto es clave, debe
integrarse en el sistema de diseño de vida y respiración. Las bibliotecas de patrones efectivas
crean un espacio para definir y describir los componentes de la interfaz de usuario, articulando
consideraciones que van desde la accesibilidad hasta el rendimiento, la estética y más.
Pattern Lab proporciona varias formas de agregar descripciones de patrones y anotaciones
a un sistema de diseño. Las descripciones de patrones se pueden agregar creando un archivo
Markdown que corresponda al nombre de un patrón (p. ej., patternname.md), que mostrará la
descripción del patrón en la vista de lista de la biblioteca.
Pattern Lab muestra documentación de patrones importante junto con los ejemplos de patrones vivos,
lo que ayuda a los equipos a comunicar definiciones, usos, ejemplos, recursos externos y más.
Pattern Lab también proporciona una característica genial (me atrevo a decir) que le
permite adjuntar anotaciones a cualquier elemento de la interfaz de usuario y ver
esas anotaciones en el contexto del diseño vivo y respirable. Cuando las anotaciones
están activadas, cada elemento anotado recibe un número que, al hacer clic, lo lleva
a la anotación correspondiente. Esto permite a los equipos ver las consideraciones
de patrones dentro del contexto de la interfaz de usuario completa. ¡Con buena pinta!
La función de anotación de Pattern Lab es interactiva y está integrada en la interfaz de usuario viva.
Proporcionar contexto con linaje de patrón
Al mirar varios patrones en una biblioteca, me he preguntado: "Genial, pero
¿dónde se usa realmente este componente?"
Definir y describir las características de los patrones es una cosa, pero existe
la oportunidad de proporcionar información contextual adicional sobre los patrones
de la interfaz de usuario.
90 DISEÑO ATÓMICO
Gracias al enfoque de inclusión de muñecas rusas descrito anteriormente,
Pattern Lab puede mostrar qué patrones componen un componente determinado
y también mostrar dónde se emplean esos patrones en el sistema de diseño.
La función de linaje de Pattern Lab muestra qué patrones componen cualquier componente y también muestra
todos los lugares donde se emplea ese componente.
En el ejemplo anterior, tenemos un patrón de molécula llamado bloque
multimedia, que contiene una imagen, un título, un texto y un grupo de botones.
Si observamos el linaje del patrón, podemos ver que contiene un patrón llamado
átomoscuadrado, que es la imagen en miniatura, así como moléculasbotónbarra,
que es el grupo de botones.
También podemos ver dónde se usa exactamente este patrón: el organismo de
la lista de bloqueo de medios.
Esta información contextual es increíblemente útil para diseñadores y desarrolladores;
Sé que uso la función de linaje todo el tiempo en mi propio flujo de trabajo. Digamos
que quisiéramos hacer cambios en un patrón en particular, como duplicar el tamaño
de una imagen o agregar un elemento adicional: sabríamos de inmediato qué
patrones y plantillas necesitarían volver a probarse y someterse a control de calidad
para asegurarnos de que nada se rompa.
los cambios. La función de linaje también ayuda a señalar patrones redundantes
e infrautilizados para que los equipos puedan eliminarlos de la biblioteca de patrones
a medida que se acerca la fecha de lanzamiento.
A cada cual lo suyo
Así que ahí lo tienes. Pattern Lab proporciona varias características útiles para que
los equipos creen sistemas de diseño deliberados y reflexivos. Pero como mencioné
antes, ninguna herramienta individual será perfecta para todos y para todas las
situaciones. Hay un montón de herramientas geniales disponible para ayudarlo a crear
bibliotecas de patrones efectivas, y las herramientas que elija sin duda se verán
influenciadas por el entorno, las tecnologías, el flujo de trabajo y la cultura de su
organización.
Al elegir herramientas para crear su biblioteca de patrones, debe estar atento a estas
cualidades y características de las bibliotecas de patrones efectivas:
Proporcionar descripciones de patrones y anotaciones.
Mostrar el patrón relevante HTML, plantillas, CSS y/o
Código JavaScript.
Visualización de patrones en todo el espectro de resolución.
La capacidad de mostrar variaciones de patrones, como activo o
pestañas deshabilitadas.
La capacidad de agregar dinámicamente contenido representativo real en las
estructuras de los patrones.
Proporcionar información contextual, como qué patrones conforman un componente
en particular, así como dónde se usa ese componente.
Al final del día, no se trata de las herramientas que usamos para crear
bibliotecas de patrones, sino de cómo las usamos. Crear y mantener un
sistema de diseño efectivo significa cambiar drásticamente la cultura, los
procesos y los flujos de trabajo de su organización. Si eso te suena difícil, es porque
lo es. ¡Pero no temas! El resto del libro detallará todo el proceso de creación y
mantenimiento de un sistema de diseño exitoso para configurar su organización para
el éxito a largo plazo.
92 DISEÑO ATÓMICO
Capítulo 4
el atómico
flujo de trabajo
Personas, procesos y hacer que los sistemas
de diseño sucedan
Hablar es barato. Y hasta ahora, hemos estado hablando mucho. ¡Eso no
quiere decir que no haya sido una charla productiva! Después de todo, hemos
discutido la importancia del pensamiento modular, hemos aprendido una
metodología para crear sistemas de diseño de interfaz de usuario deliberados y
hemos presentado herramientas para crear bibliotecas de patrones efectivas.
Pero aquí es donde el caucho se encuentra con la carretera. Donde nos
arremangamos y ponemos toda esta teoría en práctica. Donde hacemos las
cosas. Este capítulo abordará todo lo relacionado con la venta, creación y
mantenimiento de sistemas de diseño efectivos. ¿Estás listo? Vamos.
¡Su gente!
El secreto no tan secreto sobre la creación de sistemas de diseño efectivos (o
hacer un gran trabajo, en realidad): todo se reduce a que las personas realmente
colaboren y se comuniquen entre sí.
Si esto es de conocimiento común, ¿por qué no escuchamos
constantemente miles de historias de éxito de todo el mundo? Dejaré que Mark
Boulton explique:
El proceso de diseño es raro y complicado, porque las
personas son raras y complicadas.
Mark Boulton
Puede tener todas las tecnologías correctas en su lugar, usar las mejores y
más recientes herramientas, e incluso tener personas extraordinariamente
talentosas a bordo, pero si todos los involucrados no cooperan y se comunican
entre sí, entonces no va a crear un gran trabajo. . Es tan simple como eso. Eso
no quiere decir que no pueda crear un buen trabajo, pero la mayoría de las veces
creará uno de los muchos matices decepcionantes del mal trabajo.
Establecer y mantener sistemas de diseño de interfaz exitosos requiere un
esfuerzo de toda la organización, y este capítulo discutirá cómo superar las
muchas peculiaridades de los seres humanos para hacer que sucedan.
CAPÍTULO 4 / EL FLUJO DE TRABAJO ATÓMICO 95
Cuándo establecer un sistema de diseño
Entonces, ¿cuándo es el mejor momento para establecer un sistema de diseño de interfaz?
Respuesta corta: ahora.
Los sistemas de diseño y las bibliotecas de patrones que los acompañan a menudo
se crean junto con un nuevo diseño o un proyecto de rediseño, un esfuerzo de reforma
de plataforma u otra iniciativa. Aprovechar otro proyecto es una excelente manera de
introducir una biblioteca de patrones en su organización.
Dicho esto, la creación de un sistema de diseño y una biblioteca de patrones no
necesariamente tiene que coincidir con otro proyecto. Si puede convencer a sus clientes y
partes interesadas de que aporten el dinero y los recursos para un proyecto de sistema de
diseño dedicado, ¡bien por usted!
¿Cómo vende exactamente un sistema de diseño a sus clientes, jefes, colegas y partes
interesadas? ¡Ponte tu sombrero de negocios, porque vamos a abordar eso en la siguiente
sección!
patrones de lanzamiento
Introducir una nueva forma de hacer las cosas no es tarea fácil, ya que requiere cambiar las
mentalidades y comportamientos existentes de las personas. Lograr que las partes interesadas
y los clientes participen en el establecimiento de un sistema de diseño implica una educación
constante, además de un poco de experiencia en marketing.
Primero lo primero. Es necesario presentar el concepto de sistemas de diseño de interfaz a sus
clientes, colegas y partes interesadas.
Explique qué son estos sistemas de diseño y las muchas formas en que pueden ayudar a la
organización. Hemos discutido estos benefcios a lo largo del libro, para que pueda explicar
cómo los sistemas de diseño promueven la coherencia y la cohesión, aceleran la productividad
de su equipo, establecen un flujo de trabajo más colaborativo, establecen un vocabulario
compartido, brindan documentación útil, facilitan las pruebas y sirven como una fundación amiga
del futuro. ¿Quién puede decir que no a todo eso?
Desgraciadamente, descubrí que puedo exagerar los sistemas de diseño hasta que me pongo
azul, pero los trajes no siempre ven las cosas a través de la misma lente que las personas en el
terreno. Una simple reformulación de la pregunta ayuda
96 DISEÑO ATÓMICO
inmensamente. Es mucho más efectivo simplemente preguntar, “¿Te gusta ahorrar
tiempo y dinero? ¿Sí o no?" Si la respuesta a esa pregunta es no, me temo que tiene
problemas mucho mayores que vender un sistema de diseño. Si la respuesta es afirmativa,
puede presentar los benefcios a través de la lente del tiempo y el dinero. Probemos esto,
¿de acuerdo?
Los sistemas de diseño conducen a experiencias cohesivas y consistentes. Eso significa
que los usuarios dominan su interfaz de usuario más rápido, lo que genera más
conversiones y más dinero en función de las métricas que les interesan a sus partes
interesadas.
Los sistemas de diseño aceleran el flujo de trabajo de su equipo. En vez de
Al reinventar la rueda cada vez que llega una nueva solicitud, los equipos pueden
reutilizar las piezas del rompecabezas de la interfaz de usuario ya establecidas para
implementar nuevas páginas y características más rápido que nunca.
La centralización de los componentes de la interfaz de usuario en una biblioteca de patrones establece un
vocabulario compartido para todos en la organización y crea un flujo de trabajo más
colaborativo en todas las disciplinas. Dado que todos hablan el mismo idioma, se dedica
más tiempo a hacer el trabajo y se dedica menos tiempo a lidiar con reuniones y
comunicaciones superfluas de ida y vuelta.
Los sistemas de diseño facilitan las pruebas de accesibilidad, rendimiento y navegadores
cruzados, lo que acelera enormemente el tiempo de producción y permite que los
equipos inicien trabajos de mayor calidad con mayor rapidez. Además, incluir cosas
como la accesibilidad en un sistema de diseño vivo escala esas mejores prácticas, lo
que permite que sus interfaces lleguen a más usuarios y reduce el riesgo de que lo
demanden.
Una vez que se establece un sistema de diseño (con la biblioteca de patrones que
lo acompaña), sirve como una base amigable para el futuro para que la organización
modifique, modifique, amplíe y mejore con el tiempo.
¿Haciendo algunas pruebas A/B? Transfiera las lecciones de esas pruebas al sistema de
diseño vivo. ¿Hiciste algunas grandes optimizaciones de rendimiento?
¡Enróllalos en el sistema de diseño vivo! La parte viva de los sistemas de diseño vivo
significa que siempre pueden adaptarse para satisfacer las necesidades futuras de la
organización, ahorrando tiempo y dinero todo el tiempo.
Enmarcar las cosas en términos de tiempo y dinero ayuda a las personas que
controlan los hilos de la bolsa a comprender por qué un sistema de diseño es una
búsqueda que vale la pena. Con un poco de suerte, estas conversaciones se traducirán en
un compromiso concreto por parte de la organización (léase: asignar tiempo real y dinero)
para hacer realidad un sistema de diseño.
Muestre, no cuente: el poder de los inventarios de interfaz
Ojalá conseguir la aceptación fuera tan fácil como tener algunas conversaciones
oportunas con las personas adecuadas. Tal vez sea lo suficientemente inteligente
como para sellar el trato solo con puntos de conversación, pero para nosotros, simples
mortales, las palabras no son suficientes. A veces necesitas más. A veces es necesario
hacerles sentir el dolor.
Introduzca el inventario de la interfaz.
Muchos están familiarizados con el concepto de un inventario de contenido. Las
auditorías de contenido generalmente se realizan en las primeras etapas del proceso
de rediseño de un sitio web para evaluar todo el contenido del sitio. Es un proceso
tedioso que involucra hojas de cálculo y cafeína, pero todo ese trabajo duro vale la pena.
Al final del ejercicio, el contenido de la organización se presenta sobre la mesa, lo
que brinda a los equipos información valiosa sobre cómo manejar su contenido a
medida que abordan el proyecto.
Un inventario de interfaz es similar a un inventario de contenido, solo que en lugar de
filtrar y categorizar el contenido, está haciendo un inventario y categorizando todos los
componentes que conforman su interfaz de usuario. Un inventario de interfaz es una
colección completa de los elementos que componen su interfaz de usuario.
Aquí hay una colección de todos los estilos de botones únicos que se encuentran en la página de inicio de
United.com. Un inventario de interfaz redondea y categoriza todos los patrones únicos que componen una interfaz.
98 DISEÑO ATÓMICO
Realización de una auditoría de interfaz
¿Cómo se hace para realizar una auditoría de interfaz? ¿Cómo redondea todos los
componentes que componen su interfaz de usuario? La respuesta simple es capturas
de pantalla. ¡Muchos de ellos! La creación de un inventario de interfaz requiere capturas
de pantalla y una categorización general de todos los componentes únicos que componen
sus interfaces de usuario. Si bien es un esfuerzo relativamente sencillo, hay algunas
consideraciones importantes a tener en cuenta para que el inventario sea lo más útil
posible. Repasemos el proceso para crear un inventario de interfaz exitoso.
Paso 1: reunir a las tropas Me he
encontrado con muchos diseñadores y desarrolladores ambiciosos que se han
encargado de comenzar a documentar los patrones de interfaz de usuario de su
organización. Si bien ciertamente aplaudo esta ambición individual, es absolutamente
esencial lograr que todos los miembros del equipo experimenten el dolor de una interfaz
de usuario inconsistente para que comiencen a pensar sistemáticamente.
Para que el inventario de interfaces sea lo más efectivo posible, los
representantes de todas las disciplinas responsables del éxito del sitio deben estar juntos
en una sala para el ejercicio. Reúna a las tropas: diseñadores de UX, diseñadores visuales,
desarrolladores frontend, desarrolladores backend, redactores, estrategas de contenido,
gerentes de proyectos, propietarios de negocios, control de calidad y cualquier otra parte
interesada. ¡Cuantos más, mejor! Después de todo, uno de los resultados más cruciales de
este ejercicio es establecer un vocabulario compartido para todos en la organización, y eso
requiere el aporte de todo el equipo.
Paso 2: Prepárese para la captura de pantalla
El ejercicio de inventario de la interfaz genera un montón de capturas de pantalla, por
lo que, naturalmente, necesitará un software para capturar y mostrar esas capturas
de pantalla. Algunas herramientas posibles incluyen:
PowerPoint o Keynote
Photoshop o Sketch
Recortador web de Evernote
Documentos de Google o Microsoft Word
Es importante que todos los participantes capturen capturas de pantalla usando el mismo software para que puedan
combinarse más tarde. Creé una plantilla de inventario de interfaz de Presentaciones de Google para que los equipos la usen
como punto de partida.
Presentaciones de Google (si está interesado, he creado una plantilla de inventario de
la interfaz de Presentaciones de Google )
En última instancia, realmente no importa qué herramienta use, pero todos deben ponerse
de acuerdo sobre una sola herramienta para que sea más fácil de combinar al final del
ejercicio. Descubrí que el software de creación de diapositivas en línea como Google Slides
es muy eficaz, ya que proporciona un lienzo para el posicionamiento de imágenes de forma
libre, se dividen en diapositivas para facilitar la categorización y están basadas en la web, por
lo que se pueden compartir. con facilidad.
Paso 3: ejercicio de captura de
pantalla ¡ Prepara tus dedos para capturar capturas de pantalla porque es hora del
evento principal! El ejercicio de auditoría de la interfaz implica capturar capturas de pantalla
y categorizar todos los patrones de interfaz de usuario únicos que componen su experiencia.
Tenga en cuenta que este ejercicio no significa capturar cada instancia de un patrón de IU en
particular, sino capturar una instancia de cada patrón de IU único.
Asigne a cada participante una categoría de interfaz de usuario. Es posible que deba
emparejar personas o hacer que los participantes documenten varias categorías,
dependiendo de cuántas personas participen en el ejercicio. Una vez más, es útil tener
tantos participantes como sea posible, ya que más personas tomando capturas de pantalla
darán como resultado una documentación más completa.
100 DISEÑO ATÓMICO
Qué patrones capturar
¿Qué categorías de elementos de la interfaz deben capturarse? Obviamente, las categorías
variarán de una interfaz a otra, pero aquí hay algunas categorías para comenzar:
Elementos globales: componentes como encabezados, pies de página y otros elementos
globales que se comparten en toda la experiencia. Navegación: navegación principal,
navegación de pie de página, paginación, migas de pan, controles de componentes interactivos y,
esencialmente, cualquier cosa que se use para navegar por una interfaz de usuario.
Tipos de imágenes: logotipos, imágenes destacadas, avatares, miniaturas,
fondos y cualquier otro tipo de patrón de imagen que aparezca en la interfaz de usuario.
Iconos: los iconos son un tipo especial de imagen digno de su propia categoría. Capture
lupas, íconos sociales, flechas, hamburguesas, giradores, favicons y todos los demás
íconos de la interfaz.
Formularios: entradas, áreas de texto, menús de selección, casillas de verificación, interruptores,
botones de radio, controles deslizantes y otras formas de entrada del usuario.
Botones: los botones son el elemento de interfaz de usuario por excelencia. Capture todos los
patrones de botones únicos que se encuentran a lo largo de la experiencia: botones primarios,
secundarios, grandes, pequeños, deshabilitados, activos, cargando e incluso botones que
parecen enlaces de texto.
Encabezados: h1, h2, h3, h4, h5, h6 y variaciones de tipografía
encabezados
Bloques: también conocidos como anuncios publicitarios, leyendas, resúmenes, anuncios o
unidades destacadas, los bloques son colecciones de encabezados tipográficos y/o imágenes
y/o texto de resumen (consulte el artículo de Nicole Sullivan sobre el objeto multimedia como
ejemplo de un bloque).
Listas: desordenadas, ordenadas, por definición, con viñetas, numeradas,
rayados, rayados, o cualquier grupo de elementos presentados en formato tipo lista.
Componentes interactivos: acordeones, pestañas, carruseles y otros módulos funcionales con
partes móviles.
Medios: reproductores de video, reproductores de audio y otros medios enriquecidos
elementos.
Componentes de terceros: widgets, iframes, cotizaciones bursátiles, botones sociales, scripts de
seguimiento invisibles, y cualquier otra cosa que no esté alojada en su dominio.
Publicidad: todos los formatos y dimensiones de anuncios.
Mensajería: alertas, éxito, errores, advertencias, validación, cargadores, ventanas emergentes,
información sobre herramientas, etc. Esta puede ser una categoría difícil de capturar, ya
que los mensajes a menudo requieren la acción del usuario para exponerlos.
Colores: captura todos los colores únicos presentados en la interfaz. Esta categoría
puede ser asistida por fantásticas herramientas de arranque de guía de estilo como
CSS Stats y Estilízame.
Animación: la animación es un aspecto elemental de las interfaces de usuario y, por lo
tanto, debe documentarse. Esto requiere el uso de un software de grabación de
pantalla, como QuickTime, para capturar cualquier elemento de la interfaz de usuario
que se mueva, se desvanezca, se agite, haga transiciones o se tambalee por la pantalla.
pantalla.
Un ejemplo de patrones de botones únicos capturados en un inventario de interfaz para el sitio web de un banco importante.
Nuevamente, estas categorías no están escritas en piedra y variarán según la naturaleza
de la interfaz de usuario con la que esté tratando. Por supuesto, es importante agregar,
restar o modificar estas categorías para que se ajusten mejor a las necesidades de su
organización.
Un ejemplo de varios elementos de formulario capturados en un inventario de interfaz para el sitio web de un banco importante.
Tiempo lo es todo
Es importante establecer límites de tiempo en el ejercicio de captura de pantalla para
evitar caer en una madriguera de conejo que termine durando todo el día. La cantidad de
tiempo que asigne variará dependiendo de cuántas personas participen, pero considero
que entre 30 y 90 minutos son suficientes para una primera pasada de un inventario de
interfaz. ¡Configura un cronómetro, lanza algo de Jeopardy! música (bueno, tal vez no música
de Jeopardy!, sino alguna otra música que establezca un ambiente optimista para el ejercicio),
y haga que los participantes se concentren en tomar capturas de pantalla de los patrones
únicos de la interfaz de usuario que encuentran.
Cavar profundo
¿Qué partes del sitio deben capturar los participantes en el inventario de la interfaz?
Respuesta corta: todo. Cualquier parte de la interfaz de usuario que sea o pueda ser
administrada por su organización debe documentarse.
Esto es difícil ya que las organizaciones tienden a favorecer ciertas partes de la
experiencia (tos página de inicio tos ) sobre otras. Por ejemplo, las personas que
trabajan en un sitio web de comercio electrónico tienden a centrarse en la experiencia
de compra principal, aunque áreas como atención al cliente, preguntas frecuentes,
tablas de tallas, páginas 404 y términos legales también son extremadamente importantes
para la experiencia del usuario. Recuerde, los usuarios perciben su marca como una
entidad singular y no se preocupan por su estructura organizativa, pila tecnológica o
cualquier otra cosa que pueda causar disparidades en la interfaz de usuario. Anime a
los participantes de la auditoría de interfaz a ser lo más minuciosos posible durante el
ejercicio.
Paso 4: Presente los hallazgos
El ejercicio de captura de pantalla puede ser un poco abrumador, así que asegúrese
de que el equipo tome un descanso después de completar el ejercicio. Consigue algo de
comida, toma un poco de café y estira un poco las piernas. Una vez que todos se sientan
renovados, es hora de discutir lo que capturaste.
Haga que cada participante dedique cinco o diez minutos a presentar cada categoría
de interfaz de usuario al grupo. Aquí es donde comienza la diversión. Presentar al
grupo permite que el equipo discuta la lógica detrás de los patrones de interfaz de
usuario existentes, inicia una conversación sobre las convenciones de nomenclatura y
entusiasma al equipo para establecer una interfaz más consistente.
Nombrar las cosas es difícil. Es fascinante escuchar los nombres inconsistentes
que los diseñadores, desarrolladores, propietarios de productos y otras partes
interesadas tienen para el mismo patrón de interfaz de usuario. "Oh, a eso lo
llamamos la barra de servicios". "Oh, lo llamamos la navegación del administrador".
"¡Oh, lo llamamos el área de acción flotante!" Este ejercicio es una oportunidad para
descubrir y eliminar las disparidades entre las etiquetas de patrones y también para
establecer nombres para patrones que no estaban etiquetados anteriormente. No
sienta que necesita llegar a un consenso sobre los nombres finales de los patrones
en el transcurso de diez minutos; este ejercicio simplemente pretende abrir una
discusión más amplia.
Una vez que se haya presentado y discutido cada categoría, todos los
participantes deben enviar sus diapositivas al líder del ejercicio. El líder luego
combinará todo en un überdocumento gigante, que pronto se convertirá en una bola
de demolición de verdad y justicia.
Paso 5: Reagrupar y establecer los próximos
pasos Con el súper documento en la mano, es hora de que toda la
organización participe en la elaboración de un sistema de diseño de interfaz.
¿Alguna vez has querido ver llorar a un CEO? ¡Dejar al descubierto todas las inconsistencias
de la interfaz de usuario es una excelente manera de hacer que eso suceda! Uno de los
beneficios más poderosos de los inventarios de interfaz es que puede mostrárselos a
cualquier persona, incluidos los que no son diseñadores y los desarrolladores, y entenderán
por qué las IU inconsistentes son problemáticas.
No necesita ser un diseñador para reconocer que tener 37 estilos de botones únicos
probablemente no sea una buena idea. Esta es su oportunidad para dejar en claro a las partes
interesadas que abordar su interfaz de usuario de una manera más sistemática tiene mucho
sentido tanto para sus usuarios como para su organización.
Además de vender la idea a las partes interesadas clave, todo el arduo trabajo y la
discusión que se realizaron en el ejercicio de inventario de la interfaz inicial deben traducirse en
las semillas de su futuro sistema de diseño y biblioteca de patrones.
Es muy probable que el ejercicio inicial no capturó cada patrón de IU único, por lo que
es posible que deba realizar otro ejercicio de auditoría de interfaz para capturar una
imagen más completa de sus patrones de IU.
Esto puede involucrar a un grupo grande nuevamente, pero en realidad un equipo
interdisciplinario más pequeño revisará el überdocument y establecerá los próximos pasos
para el sistema de diseño.
Una vez que se hayan llenado los vacíos en el inventario de la interfaz, el grupo de
trabajo puede tener algunas conversaciones importantes sobre los próximos pasos para el
proyecto del sistema de diseño. Algunas preguntas clave que este grupo debe cubrir incluyen:
¿ Qué patrones deben permanecer, cuáles deben desaparecer y cuáles pueden fusionarse?
¿ Qué nombres de patrón deberíamos elegir? ¿ Cuáles
son los próximos pasos para traducir el inventario de interfaz en
una biblioteca de patrones vivos?
Beneficios de un inventario de interfaz
Crear un inventario de interfaces puede ser una gran tarea, pero los beneficios de
hacerlo son muchos:
Captura todos los patrones y sus inconsistencias: una interfaz
inventario redondea todos los patrones únicos que componen su interfaz de usuario.
Ver todos esos patrones similares, pero aún diferentes, uno al lado del otro
expone la redundancia y subraya la necesidad de crear una experiencia coherente
y cohesiva.
Obtiene aceptación organizacional: tener un grupo grande y diverso de
disciplinas participan en el ejercicio ayuda a todos a comprender el valor de crear
y mantener una interfaz de usuario coherente. Además, el súper documento de
inventario de interfaz puede ser una herramienta tremendamente poderosa para
convencer a las partes interesadas, jefes y clientes de invertir en un sistema de
diseño de interfaz.
Establece un alcance de trabajo: un inventario de interfaz ayuda a los equipos de
diseño a determinar el nivel de esfuerzo necesario para diseñar y construir cada
patrón de interfaz de usuario como parte de un proyecto de diseño o rediseño.
¿Qué componentes serán relativamente fáciles o difíciles de convertir en un
entorno receptivo? ¿Cuáles son las consideraciones de contenido, diseño y
desarrollo en torno a cada componente? Un inventario de interfaz permite a los
equipos tener conversaciones importantes que ayudan a establecer el alcance y el
cronograma realistas de un proyecto.
Sienta las bases para un sistema de diseño de interfaz de sonido: el inventario
de interfaz es un primer paso importante para configurar una biblioteca de
patrones completa. Es esencial capturar todos los patrones de interfaz de usuario
existentes para determinar qué patrones harán el corte final en el sistema de diseño
vivo. El ejercicio de auditoría de interfaz también ayuda a los equipos a establecer
un vocabulario compartido, que será crucial para el éxito del sistema de diseño final.
Pide perdon, no permiso
Así que discutió los benefcios de establecer un sistema de diseño vivo con sus
partes interesadas, e incluso creó un inventario de interfaz para mostrarles el choque
de trenes inconsistente que es la interfaz de usuario actual. Y, sin embargo, a pesar de
todos tus esfuerzos, siguen derribando el
buena idea de establecer un sistema de diseño de interfaz y una biblioteca de patrones. ¿Qué debe
hacer un equipo web responsable?
Hazlo de todos modos.
Así como construimos cosas como el rendimiento, la accesibilidad y la capacidad de
respuesta en nuestros productos y procesos de forma predeterminada, también debemos crear sistemas
de diseño de forma predeterminada. No necesita obtener la bendición del cliente para seguir las mejores
prácticas de su oficio. Cuando le da a las partes interesadas la opción de decir no a algo, lo harán. Así
que simplemente no les des esa oportunidad. Nuestro trabajo es crear un gran trabajo para nuestros
clientes y organizaciones, y los sistemas de diseño de interfaz son un medio para ese fin.
De hecho, para crear el todo, necesitas crear las partes de ese todo. Nuestras interfaces consisten
en piezas más pequeñas, ya sea que le preste atención a esas piezas más pequeñas o no.
Tiene que tomar una decisión: concéntrese únicamente en crear el todo mientras ignora las
partes, o dedique algún tiempo a organizar las partes para ayudarlo a crear el todo de manera más
eficiente. En su libro Multiscreen UX Design, Wolfram Nagel articula maravillosamente estos enfoques
usando ladrillos Lego como analogía.
Una forma de abordar un proyecto de Lego es simplemente sacar las piezas de la caja sobre una
mesa, arremangarse y luego comenzar a construir su creación.
Una forma de abordar un proyecto de Lego es simplemente tirar las piezas sobre una mesa y hurgar
en la pila para encontrar las piezas que necesita. Imagen adaptada de "Multiscreen UX Design" de
Wolfram Nagel.
Este enfoque de un proyecto de Lego es sin duda una estrategia viable, incluso si es sin
disculpas al azar. La única vez que prestaría atención a la pila de ladrillos es cuando la esté
examinando para encontrar la pieza específica que necesita.
Esto no es diferente a la cantidad de proyectos digitales que se abordan.
El cliente necesita un sitio web, por lo que nos lanzamos a diseñarlo y construirlo. El cliente
necesita una aplicación móvil, por lo que inmediatamente comenzamos a construir las
pantallas de la aplicación. Nuestra mirada permanece fija en el producto final, y rara vez, si
es que alguna vez, echamos un vistazo a los patrones subyacentes que componen nuestras
interfaces de usuario finales.
Por supuesto, hay otra forma de abordar sus proyectos Lego y digitales. En lugar de
sumergirse de lleno en la construcción del trabajo final, puede tomarse el tiempo para
hacer un inventario de las piezas disponibles y organizarlas de tal manera que sean más
útiles.
Tomarse el tiempo para organizar las piezas que componen sus creaciones finales le permite abordar
el trabajo de una manera más deliberada y eficiente. Imagen adaptada de "Multiscreen UX Design" de
Wolfram Nagel.
Sin duda, organizar requiere tiempo, planificación y esfuerzo. No viene gratis. El hecho
de que esta configuración no esté visiblemente representada en el producto final puede
tentarnos a decir que sirve como una distracción para el trabajo real que debe hacerse. ¿Por
qué molestarse?
Al tomarse el tiempo para organizar las partes, ahora puede crear el todo de una
manera más realista, deliberada y eficiente.
La creación de una biblioteca de sus materiales disponibles le permite abordar el proyecto
de una manera más metódica y ahorra una gran cantidad de tiempo en el proceso. En lugar
de hurgar en un desordenado
pila de ladrillos y tiempo de combustión reinventando patrones, puede crear un
sistema organizado de componentes que ayudarán a producir un mejor trabajo
en un período de tiempo más corto.
Tomarse el tiempo para organizar las piezas que componen sus creaciones finales le permite trabajar
de una manera más deliberada y eficiente. En lugar de revisar una pila desordenada de ladrillos, un
inventario organizado de componentes puede producir un trabajo mejor y más rápido. Imagen adaptada
de "Multiscreen UX Design" de Wolfram Nagel.
En lo que respecta a sus clientes y partes interesadas, el producto final
aún se está produciendo. Siempre que muestre progreso en el trabajo final,
puede decidir cuánto de su proceso interno está dispuesto a exponer. El hecho
de que estés creando un sistema de diseño para producir el producto final
realmente no les preocupa; es simplemente una decisión que su equipo está
tomando para crear un mejor trabajo.
Si está tratando con partes interesadas adversas al cambio, le digo
que haga lo que debe hacer y que no preste atención a lo que sucede detrás
de escena. Una vez que haya lanzado con éxito el proyecto y se haya servido el
champán, puede abrir el telón y decir: “Ah, por cierto, establecimos un sistema de
diseño y una biblioteca de patrones para que el equipo pudiera colaborar y
trabajar juntos de manera más eficiente. ” Sería extremadamente difícil para ellos
argumentar en su contra ahora, especialmente si el proyecto llegó a tiempo y
dentro del presupuesto. Si tiene mucha suerte, puede convertir el éxito del
proyecto inicial en una iniciativa más oficial dentro de la organización para hacer
evolucionar su sistema de diseño.
Por supuesto, es preferible que sus clientes, colegas y partes interesadas se
entusiasmen con la creación de un sistema de diseño de interfaz o, al menos, obtener
su aprobación para llevar a cabo el proyecto de forma modular. Pero creo que es importante
encontrar formas de seguir las mejores prácticas de su oficio, incluso cuando se enfrenta a
una resistencia organizativa extrema.
(Re)establecer expectativas
Ha trabajado mucho para vender el concepto de un sistema de diseño, pero aún
necesita establecer las expectativas de las partes interesadas y del equipo antes de
arremangarse y ponerse a trabajar.
Cuando digo "establecer expectativas", en realidad estoy diciendo "restablecer expectativas".
Verá, todos aportamos nuestras propias experiencias, opiniones y sesgos a un
proyecto. Nuestra industria aún es increíblemente joven, por lo que muchas personas
que trabajan en proyectos web provienen de otras industrias con sus propias formas de
hacer las cosas ™ establecidas. Incluso las personas que han trabajado exclusivamente
en el mundo digital han sentido el bagaje de las industrias del pasado. Además, los
principios rectores, las mejores prácticas y las tácticas del diseño digital todavía se están
codificando.
Es ridículo que alguien pronuncie la frase: “Así es como siempre hemos hecho las
cosas” en una industria que solo tiene 25 años.
Desafortunadamente, los humanos somos criaturas de hábitos, y salir del cálido
abrazo de la familiaridad es incómodo. No nos gusta sentirnos incómodos. Debemos
superar nuestras predisposiciones existentes si vamos a adoptar las mejores prácticas de
nuestra industria en constante cambio y crear un trabajo digital exitoso.
redefiniendo el diseño
Hemos recorrido un largo camino desde el simple trasplante de archivos PDF impresos a
la World Wide Web, pero el diseño de impresión aún proyecta una larga sombra y sigue
influyendo en cómo se hacen las cosas en línea.
El diseño en el mundo de la impresión se centra en gran medida en la estética visual.
Después de todo, no puedes hacer mucho más con un póster que mirarlo. Para ser claros,
ciertamente no estoy insinuando que el diseño de impresión sea fácil o unidimensional; el
mundo de la impresión está lleno de matices y artesanía. Lo que digo es que la naturaleza
bidireccional e interactiva de la web agrega muchas más dimensiones a lo que constituye
un buen diseño. Velocidad,
El tamaño de la pantalla, el entorno, las capacidades tecnológicas, el factor de forma, la ergonomía, la
facilidad de uso, la accesibilidad, el contexto y las preferencias del usuario deben tenerse en cuenta si
queremos crear un gran trabajo para este valiente nuevo mundo digital.
Estas consideraciones de diseño adicionales son vitales para crear un excelente trabajo digital, pero con
demasiada frecuencia están ausentes de nuestros procesos y flujos de trabajo. El diseñador Dan Mall
explica:
Como industria, vendemos sitios web como pinturas. En cambio, deberíamos
vender un acceso hermoso y fácil al contenido, independientemente del
dispositivo, el tamaño de la pantalla o el contexto.
Centro comercial Dan
¿Cómo llegamos al punto en que vendemos y diseñamos sitios web como si fueran imágenes
estáticas? Durante los años de formación de la web, creamos experiencias destinadas a ser consumidas
únicamente por computadoras de escritorio, lo cual es comprensible ya que las computadoras de escritorio
eran realmente el único juego en la ciudad. El espacio que brindan las pantallas de escritorio hizo que la idea
de simplemente traducir un PDF a la web fuera factible y atractiva. Así que eso fue lo que hicimos, ¡y durante
un tiempo realmente funcionó!
Érase una vez, la web se consumía principalmente en pantallas de escritorio, de ahí esta vieja máquina de
aspecto crujiente.
Sin embargo, esto no vino sin consecuencias. Esta perspectiva de impresión de la
web reforzó la noción de que los diseños web, al igual que sus contrapartes en línea,
podrían y deberían tener el mismo aspecto en todos los entornos. También mantuvo
el enfoque en cómo se veía un diseño web en lugar de cómo funcionaba, ignorando
todas las características únicas de este nuevo y rico medio. Además, reforzó la creencia
de que podíamos aplicar los mismos procesos lineales utilizados para crear trabajos
impresos a nuestro trabajo digital.
Pasó el tiempo, por supuesto, y los dispositivos móviles explotaron, la
tecnología mejoró y la web se convirtió en el paisaje increíblemente grande y
diverso que conocemos hoy. Atrás quedaron los días de antaño solo de escritorio, y
en su lugar está la época de los teléfonos inteligentes, teléfonos tontos, tabletas,
phablets, netbooks, notebooks, lectores electrónicos, dispositivos portátiles,
televisores, consolas de juegos, tableros de automóviles y mucho más.
Así es la web: un popurrí de dispositivos, tamaños de pantalla, capacidades, factores de forma, velocidades de
red, tipos de entrada y más.
La diversidad del panorama web actual ha hecho añicos la alucinación consensuada .
de la web de escritorio, donde simplemente podríamos conectar las mentalidades y los
procesos de impresión a este nuevo medio. Simplemente
mirar un teléfono inteligente, una tableta y una computadora de escritorio uno al lado del otro
rápidamente erosiona la suposición de que un diseño web debe verse igual en todos los
entornos.
Todavía estamos al comienzo del Big Bang de los dispositivos conectados. Sin duda, el
panorama web y de dispositivos del mañana será aún más grande y diverso que el
actual. Además de los dispositivos actuales y las tecnologías emergentes que ya se vislumbran
en el horizonte, la web del futuro incluirá tecnologías e ideas que aún no se han concebido.
Además de todos los dispositivos con capacidad web que nos preocupan hoy en día, debemos
entender que el panorama web y de dispositivos es cada vez más grande y diverso.
He encontrado que las tres imágenes anteriores son una abreviatura tremendamente útil para
ayudar a los clientes, colegas y partes interesadas a comprender la realidad del panorama web.
Con esta nueva comprensión, todo el mundo se vuelve mucho más receptivo a la actualización de
sus procesos y flujos de trabajo para crear un gran trabajo para este medio único.
Nuestro trabajo es crear excelentes experiencias para las personas que utilizan una diversidad
de dispositivos, tamaños de pantalla, velocidades de red, capacidades de dispositivos,
características del navegador, tipos de entrada, factores de forma, contextos
y preferencias. Sin duda, es una tarea hercúlea, pero todas estas variables
realmente subrayan la necesidad de ir mucho más allá de la estética visual al crear
sistemas de diseño de interfaz.
Además de crear experiencias visualmente bellas y consistentes, debemos:
Adopte la ubicuidad de la web mediante la creación de sistemas de diseño accesibles y
resistentes. Reconozca que una gran cantidad de personas con un amplio espectro
de capacidades accederán a nuestras experiencias, por lo tanto, construya sistemas
de diseño para que sean lo más inclusivos posible.
Cree diseños y componentes flexibles para que nuestras interfaces se vean y
funcionen a la perfección, independientemente de cualquier dimensión de
dispositivo o tamaño de pantalla en particular.
Tratar el rendimiento como un principio de diseño esencial y crear experiencias de
carga rápida que respeten a los usuarios y su tiempo. Mejorar progresivamente
nuestras interfaces estableciendo
Experiencias que luego superponen mejoras para aprovechar las capacidades únicas
de los dispositivos y navegadores modernos.
Cree sistemas de diseño amigables para el futuro destinados a resistir el paso del
tiempo y anticipar los cambios inevitables en el dispositivo y el panorama web.
Por supuesto, hay muchas otras consideraciones de diseño que deben incluirse en
nuestros sistemas de diseño de interfaz (ergonomía, tipo de entrada, cumplimiento de
la Sección 508, legibilidad, etc.), pero la conclusión clave aquí es ampliar la definición
de lo que constituye una buena comunicación digital. diseño más allá de la estética
visual.
Como es de esperar, es necesario que se produzcan cambios sustanciales en nuestros
procesos para que podamos abordar adecuadamente todas estas consideraciones de
diseño exclusivamente digitales. Por lo tanto, se convierte en nuestra responsabilidad
establecer las expectativas de los clientes, colegas y partes interesadas para que todos
sepan que el proceso de creación será diferente esta vez.
muerte a la cascada
Dime si has escuchado esto antes. Un equipo tiene la tarea de hacer un sitio
web. Una vez que el polvo de la reunión se haya asentado, un UX
El diseñador se va, baja la cabeza y finalmente emerge con un documento PDF
gigante que detalla toda la experiencia. Este documento de estructura alámbrica
monolítica se pasa a las partes interesadas del proyecto, quienes lo firman
después de algunos comentarios y sugerencias.
El diseñador de UX luego pasa los wireframes al diseñador visual, quien salta a
Photoshop o Sketch para aplicar color, tipografía y textura a los wireframes
estructurados pero estériles. En la reunión de revisión de diseño, las partes
interesadas se sientan ansiosamente mientras el proyector se enciende y el gerente
del proyecto sale corriendo para imprimir copias de la plataforma de diseño para
todos. El director de arte toma su posición al frente de la sala y revela el diseño. He
aquí, un diseño de sitio web! Una vez finalizada la presentación, la sala bulle
rápidamente con comentarios y conversaciones. Después de que las reacciones
iniciales y los elogios se calman, una parte interesada clave habla.
“Esto se ve fantástico, y creo que realmente da en el blanco de lo que estamos
tratando de lograr con este proyecto. Pero…"
Expresan su deseo de ver algo tal vez con un diseño alternativo, algo que
capte una cierta vibra, tal vez algo que use una fotografía diferente, algo que
simplemente... destaque.
Con los foodgates abiertos, las otras partes interesadas de repente se dan
cuenta de que ellos también tienen opiniones y críticas constructivas que les
gustaría compartir. Para cuando la reunión llega a su fin, todos han divagado
en su lista de deseos de lo que les gustaría que lograra el diseño.
Ligeramente derrotado pero decidido a dar en el clavo, el diseñador visual
vuelve a sus herramientas para trabajar en las sugerencias de las partes interesadas.
En la próxima reunión de revisión de diseño, se repite la misma escena, con las
partes interesadas expresando a partes iguales aliento y anhelo por más. “Siento
que ya casi llegamos. ¿Podríamos simplemente…”
Pasan las semanas y cambian las estaciones. Los nervios se desgastan y la fecha
límite se cierne sobre la cabeza de todos. Es con un sentido de urgencia que
homepage_v9_fnal_forreview_FINAL_bradEdits_forhandof.psd finalmente obtiene
la aprobación de las partes interesadas.
El diseñador visual, aliviado de que finalmente haya completado su trabajo,
camina de puntillas muy silenciosamente hasta la entrada de Code Cave. Deslizan
el diseño aprobado por debajo de la puerta, y mientras se alejan corretean
gritar: “¿Puedes terminar esto en tres semanas? ¡Ya estamos atrasados y no
tenemos presupuesto!”.
El diseñador visual ya ha desaparecido en la noche cuando el desarrollador
frontend elige el diseño del piso. Con una mirada a la composición, una extraña
sensación, una combinación de desconcierto, rabia y pavor, los inunda. ¿Qué
tiene de malo el diseño, exactamente? Tal vez sean los siete tipos de letra y los
nueve estilos de botones únicos salpicados a lo largo de las composiciones. Tal
vez sea el diseño centrado en el escritorio, imposible de ejecutar. Tal vez sea el
contenido perfecto pero improbable generado por el usuario.
El desarrollador frontend intenta en vano plantear sus preocupaciones al grupo
más amplio, pero rápidamente se le descarta por ser inepto o cascarrabias. Por
desgracia, es demasiado tarde para realizar cambios significativos en el diseño,
especialmente porque ya ha sido aprobado por las partes interesadas.
Entonces, el desarrollador hace todo lo posible para hacer limonada con las
composiciones estáticas de limón. Se esfuerzan al máximo para crear diseños
receptivos que aún conservan la integridad de las composiciones estáticas,
normalizan algunas de las inconsistencias de componentes más flagrantes,
establecen estados de patrones (como estados de botón, activo y deshabilitado)
que no estaban articulados en los diseños, y tomar algunas decisiones sobre la
marcha con respecto a los aspectos interactivos de la experiencia. Las discusiones
con los diseñadores son tensas, pero todos se dan cuenta de que necesitan
resolver estos problemas para terminar el proyecto.
Después de conectar el código frontend en un CMS, finalizar frenéticamente el
contenido del sitio y realizar algunas pruebas de control de calidad de última hora,
el equipo finalmente lanza el sitio. Si bien nadie lo dice en voz alta, hay un tinte de
decepción en el aire junto con la alegría y el alivio de sacar el proyecto por la puerta.
Después de todo, el sitio en vivo carece del pulido brillante que los borradores
prometieron a las partes interesadas, y la fricción entre disciplinas ha dañado
algunas relaciones.
Espero que esta historia te parezca una obra de ficción, pero basándome
en mis propias experiencias y conversaciones con muchos otros, supongo que
has experimentado esta historia de aflicción en un momento u otro.
Incluso puede golpear a casa como un puñetazo en el estómago. Ya sea
que haya soportado este proceso de primera mano o no, es importante
reconocer que el proceso de cascada al estilo de Henry Ford cada vez menos
probable que resulte en un gran trabajo digital.
El proceso en cascada, en el que las disciplinas pasan de una a otra en orden secuencial, probablemente no
resulte en un gran trabajo digital.
El proceso en cascada puede tener sentido para la impresión, la arquitectura,
la fabricación y otros medios físicos, ya que los errores y los cambios son
extraordinariamente costosos. Si un equipo pasa por alto un error cometido al
principio del proceso, lo pagará muy caro más adelante. Sin embargo, el mundo
digital no está limitado por las mismas limitaciones que el físico. Los píxeles son
baratos. Los cambios pueden ocurrir en un instante, las hipótesis se pueden probar
rápidamente y los diseños y el código se pueden repetir una y otra vez.
El proceso en cascada se basa en la premisa de que el trabajo debe fluir en un
orden secuencial: el trabajo del diseñador de UX debe completarse antes de que
pueda comenzar el diseño visual; el diseñador visual debe terminar su trabajo
antes de que pueda comenzar el desarrollo de frontend. Esto simplemente no es cierto.
Hay mucho trabajo que puede y debe ocurrir en paralelo. Para crear sistemas
de diseño de interfaz de usuario sólidos, debemos restablecer las expectativas
de nuestros interesados y hacer que se sientan cómodos con un proceso más
borroso y colaborativo.
Que el trabajo se lleve a cabo en paralelo no implica que todos estarán disparando
durante todo el proceso. Por supuesto, la mayor parte de la investigación, la
arquitectura de la información y otros aspectos elementales del diseño de UX
tenderán a ocurrir antes en el proceso, pero ese trabajo no debería retrasar el
inicio de sus trabajos de otras disciplinas.
E incluso cuando la mayor parte del trabajo activo de una persona ya está
hecho, nunca debería simplemente desaparecer del proyecto. es crucial para
cada disciplina para continuar consultando con los demás para garantizar
que su visión se convierta en el producto final. Entonces, en lugar de un
proceso de cascada rígido y secuencial, un proceso más colaborativo a lo largo
del tiempo se parece a esto:
Un flujo de trabajo más colaborativo involucra a un equipo interdisciplinario que trabaja en conjunto durante
todo el proceso. Si bien el trabajo activo tendrá altibajos, cada disciplina continúa consultando con los otros
miembros del equipo para asegurarse de que sus ideas estén presentes en el trabajo final.
El desarrollo es diseño.
Cuando un empleador anterior descubrió que escribía HTML, CSS y
JavaScript de presentación, me convencieron de que me sentara con los
ingenieros y los desarrolladores de backend. En poco tiempo me preguntaron:
“Hola, Brad. ¿Cuánto tiempo llevará construir ese middleware?” y "¿Puedes
normalizar esta base de datos muy rápido?"
Aquí está la cosa: nunca he tenido una clase de informática en mi vida, y
pasé mi carrera en la escuela secundaria pasando el rato en la sala de arte.
Baste decir que esas solicitudes me hicieron sentir extremadamente incómodo.
Hay un malentendido fundamental de que toda la codificación es una
programación ultra geek, que simplemente no es el caso. HTML no es un
lenguaje de programación. CSS no es un lenguaje de programación. Pero
debido a que HTML y CSS siguen siendo código, el desarrollo frontend es
a menudo se colocan en el mismo cubo que Python, Java, PHP, Ruby, C++ y
otros lenguajes de programación. Este malentendido tiende a dar a muchos
desarrolladores frontend, incluido yo mismo, una grave crisis de identidad.
Desde el punto de vista organizativo, a menudo existe una gran división entre
diseñadores y desarrolladores (o marketing y TI, o creatividad e ingeniería, o
algunas otras etiquetas divisorias). Los diseñadores y desarrolladores a
menudo se sientan en diferentes pisos, en diferentes edificios, en diferentes
ciudades y, a veces, incluso en diferentes países en diferentes continentes.
Si bien parte de esta separación organizacional puede estar justificada,
crear una división entre diseñadores y desarrolladores frontend es una idea
absolutamente terrible.
El hecho es que HTML, CSS y JavaScript de presentación crean interfaces
de usuario, sí, las mismas interfaces de usuario que esos diseñadores
están creando meticulosamente en herramientas como Photoshop y
Sketch. Para que los equipos construyan juntos sistemas exitosos de diseño
de interfaz de usuario, es crucial tratar el desarrollo frontend como una parte
central del proceso de diseño.
Cuando muestra a las partes interesadas solo imágenes estáticas de sitios
web, naturalmente solo pueden comentar y firmar imágenes de sitios web.
Esto establece las expectativas equivocadas. Pero al introducir el diseño
en el navegador lo más rápido posible, confronta a las partes interesadas con
las realidades del medio final mucho antes en el proceso. Trabajar en HTML,
CSS y JavaScript de presentación permite a los equipos no solo crear diseños
estéticamente hermosos, sino también demostrar esas consideraciones de
diseño digital únicas como:
flexibilidad
impacto de la red
interacción _
movimiento
ergonomía
reproducción de color y texto
densidad de píxeles
rendimiento de desplazamiento
peculiaridades del navegador y del dispositivo
preferencias del usuario
Crucialmente, saltar al navegador más rápido también inicia la creación de los
patrones que conformarán el sistema de diseño vivo y que respira. Más sobre esto
en un momento.
Esto no quiere decir que los equipos deban diseñar completamente en el navegador.
Como con cualquier cosa, se trata de utilizar las herramientas adecuadas en el momento
adecuado para articular las cosas correctas. Tener el diseño representado en el
navegador además de otros artefactos de diseño brinda a los equipos la capacidad de
pintar una imagen más rica y realista de la interfaz de usuario que están creando.
Los equipos pueden demostrar una idea de diseño centrada estéticamente como una
imagen estática y, al mismo tiempo, demostrar un prototipo funcional de esa misma idea en
el navegador.
Un proceso iterativo iterativo iterativo iterativo Creo que un
proceso de diseño digital exitoso es bastante similar a la escultura de piedra
sustractiva. Al comienzo del proceso de escultura, el artista y su patrocinador tienen
una idea general de lo que se está creando, pero esa visión no se realizará
completamente hasta que la escultura esté completa.
El escultor comienza con una losa gigante de roca y comienza a tallarla. Comienza a
formarse una forma tosca después de la primera pasada, y la forma se vuelve más
pronunciada con cada pasada subsiguiente. Después de algunas rondas de golpes en la
roca, queda claro que el tema del escultor es una forma humana.
Con la forma general de la escultura esbozada, el artista comienza a enfocarse en secciones
específicas de la pieza. Por ejemplo, pueden comenzar con la cara, acercándose para tallar
la forma de los ojos, la nariz y la boca. Después de varias pasadas, pasan a los brazos y
luego comienzan a detallar las piernas. A intervalos regulares, el artista da un paso atrás
para ver cómo su trabajo detallado afecta la escultura en general. Este proceso continúa
hasta que se completa la escultura y todos están satisfechos con los resultados.
Nuevamente, creo que la escultura de piedra sustractiva es una gran analogía para un
proceso digital exitoso, aunque a diferencia de la escultura, ¡tenemos el poder de
deshacer!
Un proceso digital iterativo es similar a la escultura de piedra sustractiva, donde la fidelidad se construye a lo largo de
muchas iteraciones. Crédito de la imagen: Mike Beauregard en Flickr
Es esencial que las partes interesadas se sientan cómodas con la revisión de los
trabajos en curso en lugar de diseños y códigos completamente elaborados. Como
mencioné en el capítulo 1, todas las organizaciones en estos días quieren volverse
más ágiles, y la iteración es una parte clave para ser ágil. Es más importante dar pasos
en la dirección correcta que agotar un montón de esfuerzo pintando imágenes poco realistas
de lo que quieres que sea la pieza final. Un sistema de diseño de sonido no sale de una
línea de montaje, sino que se esculpe en bucles iterativos, aumentando la fidelidad a
medida que avanza el proyecto.
Si todo esto suena un poco desordenado, ¡es porque lo es! Para consternación de
algunos directores de proyectos, el proceso de diseño no se ajusta perfectamente a
los bordes rígidos de las hojas de cálculo de Excel y los diagramas de Gantt. La verdadera
colaboración entre disciplinas es confusa y caótica, y eso no es malo. La comunicación
constante, los estrechos circuitos de retroalimentación y la verdadera colaboración se
convierten, por lo tanto, en el pegamento que mantiene
el proceso juntos. Haga que todo su equipo se comprometa con una
conversación honesta y una colaboración genuina, y los detalles de su proceso
encajarán.
¿Están bien establecidas las expectativas de todos? ¡Bien! Ahora,
arremanguémonos y pongámonos a trabajar para establecer nuestro sistema de diseño.
Estableciendo dirección
Los equipos a menudo están ansiosos por saltar directamente al trabajo de
desarrollo y diseño divertido de alta fidelidad, y los clientes están ansiosos por ver y
reaccionar ante ese trabajo detallado. Sin embargo, esto conduce a distracciones,
suposiciones y todas las expectativas equivocadas antes mencionadas. Es esencial
ponerse de acuerdo sobre una dirección de diseño general y pintar primero los trazos
generales antes de pasar al diseño y desarrollo de alta fidelidad. Esto requiere
moderación y gestión de expectativas, pero da como resultado una toma de
decisiones más enfocada y un trabajo más realista.
¿Cómo es este trabajo lof? Echemos un vistazo a algunas técnicas que los
diseñadores de UX, los diseñadores visuales y los desarrolladores front
end pueden usar para comenzar a crear una dirección general sólida para
un sistema de diseño de UI.
Establecimiento de contenido y patrones de visualización.
Hay un montón de trabajo estratégico y de investigación inicial que puede y
debe realizarse hacia el comienzo de un proyecto. Los diseñadores de UX
(conocidos por otros apodos como diseñadores de información, arquitectos de
información, diseñadores de interacción, etc.) son responsables de sintetizar toda
esa información vital y traducirla en una interfaz de usuario que cumpla con los
objetivos comerciales y de usuario del proyecto.
En un proceso de cascada tradicional, muchos diseñadores de UX han
realizado esta tarea generando estructuras de alambre de alta fidelidad que
documentan cada pantalla de toda la experiencia del usuario. Estos documentos
de estructura alámbrica, repletos de rectángulos negros y anotaciones,
especifican los detalles de lo que logrará la interfaz y se utilizan para obtener
la aceptación de las partes interesadas. A pesar de lo exhaustivos que tienden
a ser estos documentos, no pintan la imagen completa y, a menudo, hacen
suposiciones peligrosas sobre el diseño visual y la funcionalidad técnica.
En lugar de saltar directamente a documentos de alta fidelidad, es mejor
comenzar con bocetos de baja definición que establezcan lo que aparece en una
pantalla en particular y en qué orden general. El establecimiento de la arquitectura
de información básica de la experiencia se puede lograr con una simple lista con
viñetas y una conversación. Para un proyecto que hice para el Banco de Alimentos
Comunitario del Gran Pittsburgh, comencé con la arquitectura de información básica
para una página en un sitio.
Estructuras HTML básicas para la página de inicio del Banco de Alimentos de la Comunidad del Gran Pittsburgh.
Nadie en su sano juicio confundiría esta página bloqueada en escala de grises
como completa, pero proporciona información más que suficiente para tener
conversaciones importantes sobre la estructura y la jerarquía de la página.
Hacer wireframes lof mobilefirst significa utilizar las limitaciones de las pantallas
pequeñas para obligar al equipo a centrarse en el contenido central y
jerarquía. Ahora puede preguntar: "¿Tenemos las cosas correctas en esta
pantalla?" "¿Están en el orden general correcto?"
Estos wireframes en escala de grises en bloques ayudan a establecer los patrones de
contenido necesarios para la pantalla, pero los diseñadores de UX también pueden articular
algunos patrones de interfaz de usuario en todo el sitio que anticipan usar para finalmente
mostrar esos patrones de contenido. Para el rediseño de TechCrunch, la diseñadora Jennifer
Brook definió algunos patrones de interfaz de usuario en todo el sitio que podrían usarse en
cualquier lugar:
Para el rediseño del sitio web de TechCrunch, Jennifer Brook definió patrones de visualización gestuales en
todo el sitio, que no hacen suposiciones sobre la estética o la funcionalidad.
De la imagen de arriba, puede deducir que el componente "isla destacada" mostrará
contenido de alguna manera. Tenga en cuenta la naturaleza gestual de este boceto y
cómo no hace suposiciones específicas sobre el diseño o la funcionalidad. Los detalles
de cómo se verá y funcionará este patrón vendrán más adelante, pero al comienzo del
proyecto es útil simplemente definirlo y articular dónde podría usarse.
Como descubrí en proyectos posteriores, el contenido y los patrones de visualización se
pueden comunicar de manera efectiva en un formato aún más simple: la sencilla hoja de
cálculo.
Una hoja de cálculo simple puede articular qué contenido y patrones de visualización van en una página
determinada mientras describe su orden y propósito.
Con unas pocas columnas simples de hoja de cálculo, podemos articular qué
patrones de visualización deben incluirse en una plantilla determinada y qué
patrones de contenido contendrán. Más importante aún, podemos articular la
jerarquía relativa de cada patrón y el papel que desempeña en la pantalla. Si lee la
columna más a la izquierda verticalmente, está mirando efectivamente la primera
vista móvil de lo que podría ser la interfaz de usuario.
“¿Qué contenido y patrones de visualización van en esta página? ¿Y en qué
orden general? son preguntas cruciales que hacer, y las técnicas que acabamos de
describir pueden ayudar a los diseñadores a discutirlas de manera efectiva sin hacer
suposiciones técnicas o de diseño.
Establecimiento de la dirección visual
El trabajo de un diseñador visual es crear un lenguaje estético y aplicarlo a la
interfaz de usuario de una manera que se alinee con los objetivos del proyecto.
Para hacer esto, es esencial que un diseñador visual descubra los valores estéticos
de las partes interesadas.
Históricamente, los diseñadores visuales han hecho esto creando
composiciones completas, a menudo muchas composiciones, para sentir los
valores estéticos de la organización. Lanza algunos borradores contra la pared y
mira qué se pega. Como puede imaginar, generar una gran cantidad de
composiciones desde cero requiere una gran cantidad de tiempo y esfuerzo, y
desafortunadamente gran parte de ese trabajo se encuentra en el piso de la sala
de edición. Debe haber una forma más eficiente.
Resulta que hay un mejor camino a seguir para llegar a los valores estéticos sin tener
que hacer una gran cantidad de trabajo de diseño inicial.
Hablemos de algunas de las tácticas para hacer que esto suceda.
La prueba de instinto de 20
segundos Un ejercicio fantástico para establecer rápidamente los valores estéticos es
la prueba de instinto de 20 segundos. Normalmente se realiza como parte de la reunión
de inicio del proyecto, el ejercicio consiste en mostrar a las partes interesadas un
puñado de sitios web pertinentes (alrededor de veinte a treinta de ellos) durante veinte
segundos cada uno. Los sitios que elija deben ser una combinación saludable de sitios
específicos de la industria y otros sitios visualmente interesantes de otras industrias.
Para mayor credibilidad, puede aplicar Photoshop al logotipo de su cliente en lugar del
logotipo real del sitio.
Para cada sitio presentado, cada persona vota en una escala del 1 al 10, donde una
puntuación de 1 significa "Si este fuera nuestro sitio dejaría mi trabajo y lloraría hasta
quedarme dormido", mientras que una puntuación de 10 significa "Si este fuera nuestro
sitio". nuestro sitio estaría absolutamente extasiado!” Indique a los participantes que
consideren las propiedades visuales que les parezcan interesantes, como la tipografía, el
color, la densidad, el diseño, el estilo de ilustración y el ambiente general.
Para el inicio del rediseño del sitio web del Banco de Alimentos de Pittsburgh, mostramos a las partes interesadas
una variedad de sitios web relevantes durante veinte segundos cada uno. Los participantes votaron sobre lo felices que
serían si el sitio en particular fuera suyo. Luego discutimos los resultados.
Cuando termine el ejercicio, sume rápidamente los puntajes y regrese al grupo para
discutir los resultados. Tenga una conversación sobre los sitios que recibieron los
cinco puntajes más bajos, los cinco puntajes más altos y los puntajes más polémicos
(sitios que algunas personas clasificaron muy alto y otros clasificaron muy bajo). Los
participantes deben explicar por qué se sintieron atraídos o rechazados por un sitio en
particular y trabajar las diferencias de opinión con el grupo.
Este ejercicio expone a las partes interesadas a una variedad de
direcciones estéticas al principio del proceso, les permite trabajar a través
de las diferencias de gusto y (con un poco de suerte) ayuda a llegar a algunos valores
estéticos compartidos. El diseñador visual puede aferrarse a estos conocimientos y
comenzar a traducir esos valores estéticos en una dirección visual para el proyecto.
Azulejos de estilo
Una vez más, el primer instinto de los diseñadores visuales suele ser saltar
directamente a la creación de composiciones completas para articular una
dirección estética para el proyecto. Este trabajo de alta fidelidad es ciertamente
tangible, pero también desperdicia mucho tiempo y esfuerzo si las composiciones no
resuenan con las partes interesadas. Además, la creación de composiciones de alta
fidelidad a menudo supone grandes suposiciones sobre la viabilidad técnica, lo que
genera expectativas poco realistas y relaciones antagónicas con los desarrolladores
de interfaz.
Es esencial establecer una dirección visual sólida para el proyecto, entonces,
¿cómo hace eso un diseñador visual sin gastar una tonelada de tiempo en
composiciones iniciales de alta fidelidad? Esa es la pregunta que respondió la
diseñadora Samantha Warren cuando creó azulejos de estilo, un resultado que es
más tangible que un tablero de ideas, pero no tan fiel como una composición completa.
Para el proyecto de rediseño del sitio web de Entertainment Weekly, los diseñadores visuales utilizaron mosaicos de estilo para
explorar el color, el tipo, la textura y más.
Mosaicos de estilo (junto con sus contrapartes en el navegador, prototipos de estilo )
Permita que los diseñadores exploren el color, la tipografía, la textura, los íconos y otros aspectos
de la atmósfera del diseño sin hacer suposiciones sobre el diseño o preocuparse por el pulido.
Se pueden diseñar mucho más rápido porque no se ven entorpecidos por las expectativas de
las composiciones de alta fidelidad, lo que significa que la retroalimentación y el debate pueden
ocurrir antes.
Los mosaicos de estilo facilitan la conversación para descubrir qué valoran las partes
interesadas y qué no. “¿Este mosaico de estilo resuena mejor contigo que este? ¿Por qué?" “¿Por
qué esta paleta de colores no te sienta bien?” "¿Qué tiene este tipo de letra que te gusta?" Puede
tener conversaciones importantes sobre el diseño estético sin tener que crear composiciones
completas.
Fundamentalmente, los mosaicos de estilo también refuerzan el pensamiento basado
en patrones al educar a las partes interesadas sobre los sistemas de diseño en lugar
de las páginas. La presentación de muestras de color, ejemplos de tipos y texturas expone
a las partes interesadas a los ingredientes que sustentarán cualquier implementación del
sistema de diseño.
Collages de elementos
Si bien los mosaicos de estilo son excelentes para explorar la atmósfera del diseño, siguen siendo
un poco abstractos. Para tener una idea de cómo se aplicarán esos ingredientes de diseño a una
interfaz, es importante pasar rápidamente a algo un poco más tangible que un mosaico de estilo.
Pero, ¿eso significa que los diseñadores visuales deben pasar de los mosaicos de estilo
directamente a las composiciones completas? No necesariamente.
En algún lugar entre mosaicos de estilo y collages de elementos en vivo de composiciones
completas , que son colecciones de exploraciones de diseño de componentes de interfaz de usuario.
Los collages de elementos brindan un campo de juego para que los diseñadores apliquen una
atmósfera de diseño a los elementos reales de la interfaz, y aún así estén libres del diseño y la
presentación altamente pulida.
Un collage de elementos para el rediseño de Entertainment Weekly aplicó color, tipografía y textura a
los elementos de la interfaz real. Estos collages permitieron conversaciones importantes sobre la
dirección estética del proyecto.
Al igual que los mosaicos de estilo, los collages de elementos están destinados a facilitar la discusión
sobre la dirección estética del proyecto. Está muy claro que estos collages no son un sitio web real,
pero las partes interesadas aún pueden tener una idea de cómo se vería el sitio. La conversación
sobre estos collages de elementos puede dar a los diseñadores visuales más ideas y direcciones
sobre dónde llevar el diseño a continuación, y debido a su naturaleza baja, los diseñadores pueden
iterar y desarrollar ideas rápidamente.
Sin duda, existen otras tácticas para establecer la dirección estética de sus proyectos, y las
técnicas que decida emplear variarán de un proyecto a otro. Pero la clave es pintar algunos
trazos más amplios antes de dedicar mucho tiempo y esfuerzo a un trabajo de diseño muy detallado.
Entablar una conversación con las partes interesadas en esta etapa exploratoria crea un proceso
más inclusivo, que es mucho mejor que un proceso en el que las partes interesadas simplemente
gruñen aprobación o desaprobación de los entregables del diseño.
Chef de preparación de frontend
Como discutimos anteriormente, los desarrolladores frontend a menudo se ven relegados a máquinas de
producción rudimentarias que se incorporan al proyecto solo después de que se toman todas las decisiones de
diseño. Este proceso arcaico hace que las disciplinas no estén sincronizadas entre sí y evita que los equipos
trabajen juntos de manera significativa. Esto es un gran error. Incluir el desarrollo frontend como una parte crítica del
proceso de diseño requiere cambios tanto en la estructura del proyecto como en las mentalidades de los miembros
del equipo.
En el negocio de los restaurantes, un papel importante pero desconocido es el del chef de preparación. Un chef
de preparación corta verduras, marina la carne y prepara ensaladas para prepararse para el trabajo del día
siguiente. Al tener los ingredientes preparados con anticipación, el personal de la cocina puede concentrarse en la
colaboración y la cocina en lugar de las tareas domésticas. Sin el trabajo inicial del chef de preparación, el flujo de los
chefs principales se vería interrumpido y el ritmo acelerado de la cocina se detendría.
Un chef de preparación corta verduras, marina carne, prepara ensaladas y prepara otros ingredientes para
que el personal principal de la cocina pueda concentrarse en cocinar y colaborar.
Los desarrolladores frontend deben ser los chefs de preparación del proceso de diseño web.
Si los desarrolladores no están programando desde el primer día del proyecto, hay algún
problema con el proceso. "Pero Brad", puedo oírte decir, "¿cómo puedo empezar a codificar
si no sé lo que se supone que debo codificar?"
Créame, hay mucho trabajo inicial que hacer sin saber nada sobre el diseño de la información o
la dirección estética del proyecto.
Además de configurar el entorno de desarrollo (como preparar repositorios Git, servidores
de desarrollo, CMS y herramientas de desarrollo), los desarrolladores pueden sumergirse
en el código y comenzar a marcar patrones.
Pero, ¿qué debería marcar si no sabe nada sobre el diseño? Eso depende del tipo de proyecto en
el que estés trabajando.
¿Estás haciendo un sitio de comercio electrónico? Puede configurar la búsqueda en el sitio,
una tabla de carrito de compras, una página de detalles del producto de marcador de
posición, la página de inicio y las páginas de pago. ¿Hacer un servicio en línea? Comience
a marcar los formularios de registro e inicio de sesión, el flujo de contraseña olvidada y el
tablero. Y, por supuesto, la mayoría de los sitios web tendrán un encabezado, un pie de página
y un área de contenido principal. Configure plantillas de shell y escriba marcas básicas para los
patrones que prevé utilizar. Este marcado inicialmente será tosco, pero proporciona un punto de
partida crucial para la colaboración y la iteración.
Este trabajo de chef de preparación de frontend libera el tiempo de los desarrolladores
para colaborar con los diseñadores, en lugar de trabajar una vez que se completa el
diseño. Con el marcado básico implementado, los desarrolladores pueden trabajar con los
diseñadores para ayudar a validar las decisiones de diseño de UX a través de conversaciones y
prototipos de trabajo. Pueden ayudar a los diseñadores visuales a comprender mejor el orden de
las fuentes y el diseño web, y pueden producir rápidamente una base de código incipiente que
eventualmente se convertirá en el producto final.
Deténgase, colabore y escuche
Repasemos rápidamente cómo se ve el establecimiento de la dirección del diseño en todas
las disciplinas:
Los diseñadores de UX pueden crear bocetos lof para establecer
arquitectura de la información y algunos patrones de interfaz de usuario anticipados.
Los diseñadores visuales pueden recopilar los valores estéticos de los equipos
realizando un ejercicio de prueba de instinto de 20 segundos, luego cree mosaicos de
estilo y collages de elementos para explorar las direcciones de diseño iniciales.
Los desarrolladores frontend pueden configurar dependencias de proyectos,
crear plantillas básicas y escribir marcas estructurales para los patrones que
el equipo prevé utilizar en el proyecto.
Este trabajo puede ocurrir al mismo tiempo, pero no debe ocurrir de
forma aislada. Claro, será necesario que haya un tiempo inicial de cabeza
abajo para configurar cada disciplina, pero todos los miembros del equipo
deben ser plenamente conscientes de las exploraciones de cada disciplina
antes de trabajar juntos para desarrollar estas ideas.
Las ideas están destinadas a ser feas.
Jason Santa María
En esta etapa temprana, es importante enfatizar la importancia de la
exploración, el juego y la generación de ideas. La naturaleza baja de las
técnicas que acabamos de discutir ayuda a fomentar esta exploración, lo
que permite a los miembros del equipo buscar ideas que los entusiasmen.
A veces, esas ideas pueden articularse mejor como un boceto en una servilleta,
un prototipo en CodePen, una exploración visual en Sketch, una conexión rápida
en Balsamiq, un concepto de movimiento en After Effects o alguna combinación
de medios y herramientas. El punto es que el equipo genere ideas y resuelva
problemas, no imponer un orden rígido de operaciones. Al abordar esta exploración
de diseño de manera interdisciplinaria, los equipos pueden encontrar el equilibrio
entre la estética, la viabilidad técnica, la facilidad de uso y la funcionalidad.
Arremangarnos las mangas
Con una dirección de diseño general establecida, el equipo puede
arremangarse para construir la interfaz y su sistema de diseño subyacente.
Pero, ¿cómo convierten los equipos un vago sentido de dirección en un
sistema de diseño hermoso, funcional, utilizable y completo?
Desde el concepto hasta el completo
Convertir exploraciones en patrones terminados es un proceso borroso e
imperfecto. Esto no debería sorprenderte en absoluto a estas alturas del libro.
Para el proyecto TechCrunch, Dan Mall se basó en las conversaciones de
diseño iniciales del equipo para crear una exploración visual para el encabezado
del sitio. Esta parte de la interfaz era un lugar lógico para comenzar, ya que el
encabezado es uno de los elementos más destacados y de marca en la página.
Después de un poco de trabajo, recibimos una llamada para discutir la exploración
con el cliente.
Dan Mall creó un collage de elementos para explorar una dirección estética para el encabezado global.
Aunque este artefacto de diseño fue una simple exploración en
progreso, pudimos tener conversaciones importantes sobre la estética, la
jerarquía y la funcionalidad sugerida del encabezado.
Debido a que el encabezado se presentó sin contexto, pudimos discutir los
problemas relacionados con el encabezado sin que las partes interesadas se
enfocaran en otros elementos de la página.
Aunque el cliente no lo sabía, había estado creando una versión HTML funcional
del encabezado entre bastidores en Pattern Lab.
Usando la exploración de Dan como referencia, creé una versión HTML del encabezado global en Pattern
Lab. Este prototipo en escala de grises nos ayudó a demostrar la interactividad y cómo se adaptaría el
encabezado en todo el espectro de resolución.
Este prototipo en escala de grises nos permitió demostrar interactividad y
capacidad de respuesta, lo que generó aún más debate. En conjunto, propusimos
cambios en el diseño y la funcionalidad del encabezado, y pude realizar cambios
utilizando las herramientas de desarrollo del navegador durante la llamada. ¡De
repente, todo el equipo y las partes interesadas estaban participando activamente
en el proceso de diseño!
Con el aporte de las partes interesadas y el equipo, iteramos sobre el patrón del
encabezado para modificar el diseño, la IA, los detalles estéticos y la funcionalidad
para llegar a la solución que finalmente lanzamos.
El encabezado con el que lanzamos fue la culminación de muchas conversaciones y decisiones sobre
el contenido, el diseño y la funcionalidad del patrón.
Obviamente, el patrón de encabezado no existe en el vacío. Dentro de Pattern
Lab, el encabezado se incluyó en cada plantilla usando el patrón de inclusión
de Moustache que discutimos en el capítulo 3.
Esto nos permitió ver el encabezado dentro del contexto del resto de
las páginas, incompletas como inicialmente eran. Entonces, mientras nos
enfocábamos en diseñar un patrón específico, al mismo tiempo teníamos en cuenta
el contexto en el que se emplearía ese patrón.
En un proceso más iterativo, habrá casos en los que algunos patrones se desarrollen más que otros.
Ver una página parcialmente terminada puede parecer inusual fuera de contexto, pero la comunicación
entre el equipo y las partes interesadas debería aliviar la confusión.
Inicialmente, los diseños en el navegador tienden a verse toscos en el mejor de los casos, lo cual
está bien. La intención es extraer la arquitectura de información básica de la plantilla en el navegador,
defnir patrones, conectar esos patrones usando include y comenzar el marcado general de los patrones.
Con ese trabajo en su lugar, el equipo puede comenzar colectivamente a diseñar patrones específicos y
refinar la estructura general.
Ver estos prototipos parcialmente diseñados puede parecer inusual para aquellos que están
acostumbrados a entregas de diseño más tradicionales y con píxeles perfectos.
Pero es mucho más importante comunicar el progreso que una falsa sensación de perfección, razón
por la cual las actualizaciones continuas son preferibles a las grandes revelaciones.
El papel de los borradores en una era postPSD
Hasta este momento hemos estado hablando de establecer una dirección estética
general y luego diseñar algunos patrones para experimentar con la aplicación de esa
dirección estética. Estas tácticas relativamente bajas permiten a los equipos explorar
libremente, iterar rápidamente y recibir comentarios antes.
Pero nunca olvidaré los comentarios de este cliente que recibimos sobre el primer
proyecto basado en patrones en el que trabajé: "Estos collages de elementos se
ven geniales, pero es como si me estuvieras pidiendo que comente lo hermosa que
es una cara mostrándome la nariz". .”
Si has llegado a este punto de tu proceso, ¡felicidades!
Comentarios como este significan que están ansiosos por más, por lo que ahora
que ha capturado una dirección estética general, puede poner esas exploraciones
en contexto de manera segura. Eso probablemente implica crear composiciones
estáticas completas.
Escuche la charla sobre "diseñar en el navegador" y sin duda escuchará que las
composiciones de Photoshop son la encarnación del diablo. Lo cual, por supuesto, no
es cierto. A lo largo de este libro, hemos discutido la importancia de descomponer las
cosas en sus elementos atómicos y, al mismo tiempo, construir un todo cohesivo. Las
composiciones estáticas son efectivas para pintar una imagen completa de cómo podría
verse la interfaz de usuario. El truco es saber cuándo pintar esas imágenes completas
y saber cuánto tiempo permanecer en documentos de diseño estáticos.
Dan Mall creó una composición completa para demostrar cómo sería una plantilla de artículo destacado para
TechCrunch. Este artefacto se utilizó para mostrar el sistema de diseño en contexto y obtener la aprobación
del diseño general. Las revisiones de diseño posteriores se manejarían en el navegador.
Para el proyecto TechCrunch, creamos una composición para la plantilla del
artículo solo después de que el cliente se sintiera bien con nuestras exploraciones del
collage de elementos. Crear composiciones completas requiere mucho esfuerzo, por
lo que establecimos la dirección del diseño primero para mitigar el riesgo de que todo
ese esfuerzo de composición completa vaya directamente a la basura si nos
equivocamos por completo.
Las composiciones, como cualquier otro artefacto de diseño, se utilizan para
facilitar una conversación con las partes interesadas del proyecto. Si sus
comentarios son, "Esto se siente todo mal", entonces es volver a la mesa de dibujo para
crear una nueva composición. Pero si sus comentarios sugieren: “¿Podemos mover esto
de aquí a aquí? ¿Podemos agregar un borde gris alrededor del texto del artículo?
¿Podemos aumentar el tamaño de esta imagen?” eso es una señal de que la
dirección general está en buena forma y esos problemas relativamente menores se
pueden abordar en el navegador.
iteración en el navegador
Las composiciones estáticas pueden ser excelentes para dar forma a la dirección estética
general de una plantilla, pero los usuarios finalmente verán e interactuarán con la
experiencia en un navegador. Es por eso que los diseños deben traducirse rápidamente
al entorno final y repetirse allí.
Trabajar en el navegador permite a los equipos abordar problemas de diseño en
todo el espectro de resolución, diseñar en torno a datos dinámicos (como longitudes
de caracteres variables, tamaños de imagen y otro contenido dinámico), demostrar
interacción y animación, medir el rendimiento, tener en cuenta la ergonomía y
confrontar consideraciones técnicas (como densidad de píxeles, representación de texto,
rendimiento de desplazamiento y peculiaridades del navegador). Las composiciones de
diseño estático no pueden abordar todas estas consideraciones, por lo que deben
tratarse simplemente como hipótesis en lugar de especificaciones grabadas en piedra.
Solo cuando se transfiere al navegador, cualquier hipótesis de diseño puede ser
realmente confrmada o rechazada.
Cambiemos la frase “diseñar en el navegador” por
“decidir en el navegador”.
Centro comercial Dan
Una vez que los diseños están en el navegador, deben permanecer en
el navegador. En esta etapa del proceso, el punto de producción cambia a los
miembros del equipo expertos en la elaboración de HTML, CSS y JavaScript de
presentación. Los patrones deben crearse, diseñarse y conectarse donde sea
que se necesiten. Los diseñadores pueden reaccionar a estas implementaciones
en el navegador y pueden crear composiciones puntuales en herramientas
estáticas para ayudar a eliminar las arrugas de respuesta a nivel del organismo.
Este ir y venir entre las herramientas estáticas y las del navegador establece un
ciclo saludable entre el diseño y el desarrollo, donde el código frontend se
vuelve más sólido y estable con cada ciclo iterativo.
Esta ilustración de Trent Walton de Paravel articula perfectamente un proceso de diseño y
desarrollo más iterativo. Al obtener los diseños en el navegador antes, los equipos pueden iterar sobre el
diseño y abordar las muchas consideraciones que solo se pueden abordar una vez que el diseño está en el navegador.
Lo hermoso de un flujo de trabajo basado en patrones es que a medida
que cada patrón se vuelve más completo, cualquier plantilla que incluya el
patrón también se volverá más completo.
Eso significa que el nivel de esfuerzo para crear nuevas plantillas disminuye
drásticamente a lo largo del proyecto, hasta que, finalmente, la creación de una
nueva plantilla implica principalmente unir patrones existentes.
Tráelo a casa
El sistema de diseño va tomando forma y el equipo cocina con gas para llevar el
proyecto a casa. En esta etapa, los patrones de IU están bien establecidos, el
equipo está tomando algunos pasos finales para ajustar todo y prepararse para el
lanzamiento.
Los diseñadores de UX están trabajando duro en el prototipo para asegurarse
de que los fujos y las interacciones sean todos lógicos e intuitivos. Los diseñadores
visuales están revisando la interfaz y proponiendo ajustes de diseño a la interfaz de
usuario para pulir el diseño. Los desarrolladores frontend están probando la
experiencia en una gran cantidad de navegadores y dispositivos, al mismo tiempo que
abordan los comentarios sobre el diseño. Los desarrolladores de backend están
trabajando arduamente para integrar la interfaz de usuario de frontend en el CMS
(hablaremos más sobre la relación entre frontend y backend en el capítulo 5).
Y, por supuesto, los clientes y las partes interesadas están haciendo demandas de
última hora, me refiero a sugerencias, sobre el diseño y el contenido.
Todo el equipo está contribuyendo con la documentación para la guía de estilo,
limpiando los patrones en la biblioteca de patrones y trabajando arduamente para
poner en marcha el sitio web.
Luego, aparentemente en un abrir y cerrar de ojos, se lanza el sitio web y
el sistema de diseño que lo acompaña. Se sirve champán, se intercambian cinco y,
por supuesto, se eliminan los errores posteriores al lanzamiento.
Los usuarios visitan el nuevo sitio para encontrar una experiencia hermosa,
funcional, consistente y cohesiva que sin duda los hace llorar de alegría. Misión
cumplida.
Lo que comenzó como una losa gigante de roca ahora es una escultura
finamente pulida, gracias a un montón de trabajo duro, colaboración genuina,
comunicación constante y mucha iteración. Además, además de un sitio web
completamente nuevo, el equipo deja atrás un sistema de interfaz de usuario deliberado
y flexible incluido en una hermosa guía de estilo.
Este capítulo exploró todo lo relacionado con la creación de un sistema de diseño de
interfaz de usuario eficaz. En el próximo capítulo, discutiremos cómo asegurarnos de
que el sistema de diseño continúe teniendo éxito a largo plazo.
Capítulo 5
mantenimiento
Sistemas de Diseño
Hacer que los sistemas de diseño resistan la prueba
del tiempo
Y crearon un sistema de diseño, entregaron una guía de estilo y vivieron
felices para siempre. ¿Bien?
No exactamente.
Existe un riesgo muy real de que una guía de estilo termine en la papelera
junto con todos los PSD, PDF y otros artefactos estáticos del proceso de
diseño. A pesar de las mejores intenciones de todos, todo el tiempo y el
esfuerzo que se dedicó a crear un sistema de diseño inteligente y una guía
de estilo pueden irse por el desagüe.
¿Como puede ser?
Una guía de estilo es un artefacto del proceso de diseño. Un sistema de diseño es
un producto vivo y financiado con una hoja de ruta y un trabajo atrasado, que sirve
a un ecosistema.
Nathan Curtis
Un artefacto es algo que encontraría en una excavación arqueológica o en
un museo, mientras que un sistema es una entidad viva que respira. Un estilo
CAPÍTULO 5 / MANTENIMIENTO DE SISTEMAS DE DISEÑO 143
guide puede proporcionar documentación y servir como un recurso útil, pero la
simple existencia de una guía de estilo no garantiza el éxito a largo plazo del
sistema de diseño subyacente. Un sistema de diseño necesita mantenimiento
continuo, soporte y un cuidado tierno y amoroso para que realmente prospere.
Cambiando de opinión, una vez más
Ya hemos discutido la importancia de restablecer las expectativas de todos
para establecer un flujo de trabajo más colaborativo y basado en patrones.
Para salvar nuestras guías de estilo de las entrañas de un bote de basura, una
vez más debemos reconfigurar fundamentalmente los cerebros de las personas.
¿Qué es lo que estamos haciendo de nuevo?
Creemos que simplemente diseñamos y creamos sitios web y aplicaciones. Y eso
es cierto en su mayor parte. Después de todo, para eso nos pagan nuestros clientes,
y los productos que creamos son los vehículos que generan dinero y éxito para
nuestras organizaciones. Parece natural centrarse en las implementaciones finales
en lugar del sistema subyacente. Los productos en vivo siguen siendo el foco
principal de atención de todos, mientras que cualquier biblioteca de patrones existe
como una rama que simplemente proporciona documentación útil.
El problema con esta mentalidad es que casi puedes ver que la biblioteca de
patrones se rompe y se desliza hacia el abismo. Una vez que la biblioteca de
patrones deja de reflejar el estado actual de los productos
sirve, se vuelve obsoleto. Y cuando la biblioteca de patrones que
administra el sistema de diseño ya no es precisa, el proceso de mantenimiento
del sitio web se convierte en un puñado de hotfxes y cambios ad hoc, arruinando
toda la consideración que se tomó para crear el sistema de diseño original.
Para prepararnos para el éxito a largo plazo, debemos cambiar fundamentalmente
nuestra perspectiva en torno a lo que realmente estamos creando. En lugar de
pensar en las aplicaciones finales como nuestra única responsabilidad, debemos
reconocer que el sistema de diseño es lo que sustenta nuestros productos finales
y bibliotecas de patrones.
Esta mentalidad de “diseñar el sistema primero” introduce un poco de fricción en el
proceso de mantenimiento, y esa fricción puede ser amigable. Nos obliga a dar un
paso atrás y considerar cómo las mejoras, las solicitudes de los clientes, las
adiciones de funciones y las iteraciones afectan el sistema en general en lugar de
solo una parte de todo el ecosistema.
Supongamos que está trabajando en un sitio de comercio electrónico y
ejecuta una prueba que encuentra que un menú desplegable de estilo
personalizado en la página de detalles del producto no funciona tan bien como
el menú desplegable predeterminado del navegador. Un curso de acción es
simplemente eliminar el menú desplegable de estilo personalizado de esa página
en particular y llamarlo un día. Sin embargo, considerar todo el sistema de diseño
en lugar de solo la página de detalles del producto puede hacer que retroceda
un paso y se pregunte: "Si este menú desplegable personalizado no funciona
bien aquí, tal vez no funcione bien en otros lugares". Después de profundizar
más en el problema, encuentra que el mejor curso de acción es globalmente
modifique el patrón desplegable en el sistema de diseño para eliminar el estilo
personalizado. Ahora, en cualquier lugar donde aparezca el patrón desplegable, se
reflejarán esos cambios y es probable que se observen mejoras de rendimiento similares.
Ese es solo un ejemplo de cómo el pensamiento del sistema de diseño puede
conducir a cambios más amplios y más considerados. El comportamiento roto y las
oportunidades para mejorar la interfaz de usuario a menudo se realizarán en el nivel de
la aplicación , pero esos cambios a menudo se deben implementar en el nivel del sistema .
Agregar este poco de fricción amistosa a su flujo de trabajo garantiza que las mejoras se
compartan en todo el ecosistema y evita que el sistema se vea erosionado por una serie de
cambios únicos.
Hecho y hecho
Otra expectativa que debemos revisar es nuestra definición de hecho.
Crear cosas para imprimir y otros medios físicos implica hacer objetos permanentes y
tangibles. Ese sentido de finalidad simplemente no existe en el mundo digital, lo que significa
que el cambio puede ocurrir con mucho menos esfuerzo y fricción que otros medios. Los
clientes, colegas y partes interesadas deben adoptar la naturaleza flexible del mundo digital
para crear sistemas de diseño vivos que se adapten a la naturaleza siempre cambiante del
medio, las necesidades del usuario y las necesidades del negocio.
Este cambio de pensamiento afecta fundamentalmente el alcance de nuestro trabajo.
Las personas que trabajan en el negocio de servicios al cliente a menudo están
acostumbradas a entregar un proyecto en un paquete ordenado y luego cabalgar hacia el atardecer.
A los equipos internos no les va mucho mejor, ya que tienden a flotar de una iniciativa a la
siguiente. Ya sea que forme parte de un equipo interno o sea un arma externa a sueldo,
supongo que ha experimentado las deficiencias del trabajo basado en proyectos. Tendemos
a hablar sobre un futuro que nunca llega y, en cambio, lo establecemos, lo olvidamos y luego
pasamos al siguiente proyecto brillante.
Si estamos comprometidos con la creación de un trabajo realmente útil que realmente
satisfaga las necesidades de nuestros clientes y organizaciones, debemos redefinir
fundamentalmente el alcance de nuestro trabajo. Como dice Nathan Curtis, un sistema
de diseño no debe ser un proyecto con un alcance finito, sino un producto destinado a crecer
y evolucionar con el tiempo:
Centrarse en la entrega de la guía de estilo como el clímax es una
historia equivocada para contar. Un sistema no es un proyecto con un
final, es la historia de origen de un producto vivo y en evolución que servirá a
otros productos.
Nathan Curtis
La web nunca termina, y la creación de un sistema de diseño es
simplemente el primer paso de un largo (¡y con suerte fructífero!) viaje.
Un sistema de diseño debe ser un compromiso a largo plazo con el
ambicioso objetivo de revolucionar la forma en que su organización crea
trabajo digital. Emocionante, ¿eh? Entonces, ¿cómo nos aseguramos de que eso suceda?
Creación de sistemas de diseño mantenibles
Mientras se embarca en este viaje pavimentado con patrones, hablemos
de las cosas que puede hacer para crear un sistema de diseño que
prepare a su organización para el éxito a largo plazo. ¿Cómo crea un sistema
de diseño que eche raíces y se convierta en una parte esencial del flujo de
trabajo de su organización? ¿A qué trampas debes estar atento? ¿Cómo se
asegura de que el sistema de diseño produzca grandes resultados? Para
configurar su sistema de diseño para el éxito a largo plazo, necesita:
Hazlo oficial.
Hágalo adaptable.
Hacerlo mantenible.
Hacerlo transversal.
Hágalo accesible.
Hazlo visible.
Hazlo más grande.
Hágalo independiente del contexto.
Hágalo contextual.
Haz que dure.
Profundicemos un poco más en cada uno de estos puntos.
hazlo oficial
Su guía de estilo inicial puede comenzar su vida como un proyecto paralelo,
el resultado de un hackatón de fin de semana o como la creación de uno o dos
miembros ambiciosos del equipo. Como discutimos en el capítulo anterior, su
cliente o jefe ni siquiera tiene que saber que está creando un sistema de diseño
inteligente y la biblioteca de patrones que lo acompaña.
Recuerda: ¡pide perdón, no permiso!
Los comienzos orgánicos están muy bien, pero para establecer un sistema de
diseño verdaderamente impactante que genere éxito a largo plazo para su
organización, el sistema de diseño debe evolucionar hasta convertirse en un
esfuerzo sancionado oficialmente. Eso significa pensar en él como un verdadero
producto en lugar de un simple proyecto paralelo y, en consecuencia, asignarle
tiempo real, presupuesto y personas.
Convencer a las partes interesadas para que comprometan grandes cantidades de dinero,
tiempo y recursos por adelantado para un sistema de diseño puede ser extremadamente
desafiante. Entonces, ¿qué vamos a hacer? Aquí está mi consejo:
1. Hacer una cosa.
2. Demuestra que es útil.
3. Hazlo oficial.
Analicemos estos pasos un poco más.
1: hacer una cosa
Tienes que empezar en alguna parte, y tener algo que empezar es mejor
que nada en absoluto. Elija un proyecto que sería un gran piloto para
establecer su sistema de diseño; seguir un proceso similar al discutido en el
capítulo 4; pensar en el modelo mental de diseño atómico detallado en el capítulo
2; y terminará con una base sólida para un sistema de diseño inteligente y una
biblioteca de patrones que ayude a su equipo a trabajar de manera más efectiva.
Tómese el tiempo para empaquetar sus patrones de interfaz de usuario en una
biblioteca de patrones y prepárelos para compararlos. He hablado con varios
miembros del equipo ambiciosos que han establecido la esencia básica de su
biblioteca de patrones en el transcurso de un fin de semana. Este esfuerzo marca
la diferencia en el mundo, ya que proporciona algo tangible para que las partes
interesadas reaccionen. De nuevo: muestra, no cuentes.
2: Demuestra que es útil
Con un sistema de diseño incipiente pero tangible, puede tener
conversaciones más significativas con las personas que controlan el dinero,
la programación y los recursos. Puede discutir exactamente cómo el sistema
de diseño ayudó a ahorrar tiempo y dinero (consulte “Patrones de
lanzamiento” en el capítulo 4), luego dibujar una imagen de cómo esos
benefcios aumentarían aún más si la organización invirtiera en un sistema
de diseño oficial completo.
Obtenga miembros del equipo de diferentes disciplinas para que lo
respalden y discutan el éxito inicial del sistema, y también atraiga a otros
que simpatizan con la causa y que se beneficiarían de un sistema de diseño
ampliado.
3: Hazlo oficial
Ha demostrado el valor de su sistema de diseño inicial y ha presentado una
hoja de ruta sobre cómo mejorarlo aún más. Con un poco de suerte, su
organización se comprometerá a convertir el sistema de diseño en algo
oficial.
Con la aprobación de los niveles más altos, ahora puede poner en
marcha un plan que implica: asignar o contratar personas para trabajar
en el sistema de diseño; desarrollar un plan para hacerlo más sólido;
establecer una estrategia clara de gobernanza; y diseñar una hoja de ruta
del producto.
Vale la pena señalar que es posible que las cosas no salgan como
esperabas. A pesar de demostrar un valor real y presentar un plan de
acción concreto, los superiores aún pueden derribar su iniciativa.
No te desanimes. Puede que hayas perdido la batalla, pero ciertamente
puedes ganar la guerra. Su equipo debe continuar creciendo y
extendiendo el sistema de diseño en cualquier capacidad que pueda
hasta que su valor sea innegable. A medida que más personas se beneficien
del sistema, terminará con un sistema respaldado por la base que puede
ayudar a impulsar el esfuerzo.
Establecimiento de un equipo de sistema de diseño
Con la iniciativa del sistema de diseño aprobada, ahora es el momento de poner en
marcha a las personas y los procesos adecuados para garantizar que el sistema
prospere para su organización.
Creadores y usuarios de sistemas de
diseño Lo primero es lo primero. Es importante reconocer que
inevitablemente habrá personas en la organización que ayuden a crear y
mantener el sistema de diseño, y habrá personas que serán usuarios del
sistema de diseño. Puede haber una superposición entre estos dos grupos,
pero no obstante, es importante establecer los roles de los creadores y los usuarios.
Cuando hablo de establecer un proceso más colaborativo como el que detallé en el
capítulo anterior, inevitablemente escucho a personas que trabajan en grandes
organizaciones decir: “Pero Brad, tenemos cientos (o incluso miles) de desarrolladores
trabajando en nuestros productos. Conseguir que toda esa gente colabore y
contribuya de esa manera sería demasiado difícil”.
Es probable que tengan razón. Sería ideal si toda la organización adoptara
procesos más ágiles y colaborativos, pero la abrumadora logística en torno a tal
esfuerzo lo hace improbable. Pero aquí está la cosa: no todos en la organización
necesitan contribuir directamente al sistema de diseño, pero alguien (o más
probablemente, algunas personas) deben hacerse cargo de él.
Los creadores del sistema de diseño son quienes crean, mantienen y gobiernan
el sistema, y deben trabajar en estrecha colaboración para garantizar que el
sistema sea inteligente, flexible, escalable y aborde las necesidades de los
usuarios y el negocio. Los usuarios del sistema de diseño son los equipos de toda
la organización que tomarán el sistema y emplearán sus patrones de interfaz para
aplicaciones específicas.
Creadores y usuarios del sistema de diseño.
Los creadores del sistema de diseño y los usuarios del sistema de diseño deben
mantener una estrecha relación de trabajo para garantizar que los patrones defnidos
dentro del sistema satisfagan las necesidades de las aplicaciones y que toda la
documentación sea clara. Los creadores brindan una perspectiva a vista de pájaro de todo el
ecosistema al que sirve el sistema de diseño, mientras que los usuarios brindan una
perspectiva sobre el terreno enfocada en aplicaciones específicas del sistema. Jina Bolton de
Salesforce resume muy bien la relación entre los creadores y los usuarios:
El Sistema de Diseño informa nuestro Diseño de Producto. Nuestro Diseño
de Producto informa el Sistema de Diseño.
Nombre Bolton, Fuerza de ventas
Ambas perspectivas son fundamentales para el éxito del sistema de diseño,
por lo que es tan importante que los creadores y los usuarios tengan una
relación saludable que implique comunicación y colaboración frecuentes.
Creadores de sistemas de
diseño ¿Quién actualiza el sistema de diseño? ¿Quién aprueba los cambios?
¿Quién se comunica con los usuarios del sistema de diseño para asegurarse de que
satisface sus necesidades? ¿Quién decide qué patrones se quedan, se van o necesitan
ajustes?
Las respuestas a estas preguntas dependerán en gran medida del tamaño y la
configuración de su organización.
Las grandes organizaciones pueden dedicar importantes recursos a la gestión
de los sistemas de diseño. Salesforce, por ejemplo, mantiene un equipo de
sistemas de diseño oficial, que actualmente incluye alrededor de una docena de
empleados de tiempo completo, según lo último que escuché. Ese equipo
dedicado es responsable de gobernar el sistema de diseño y asegurarse de que
satisfaga las necesidades de los equipos de productos internos, así como de los
desarrolladores externos que crean cosas en la plataforma de la empresa. Cuando un
sistema de diseño está sirviendo literalmente a miles de usuarios, es una buena idea
dedicar al menos algunos empleados de tiempo completo para administrar y expandir
el sistema.
Es muy probable que las organizaciones más pequeñas no puedan darse el lujo de
formar un equipo completo para dar servicio a un sistema de diseño. Los miembros del
equipo en organizaciones más pequeñas tienen que usar muchos sombreros (¡con
suerte, elegantes!) por necesidad, por lo que gobernar el sistema de diseño
probablemente se convierta en otra responsabilidad. Esto puede sonar como una carga
adicional ("¡Oh, genial, otra cosa más de la que soy responsable que no implica un
aumento de sueldo!"), pero este sombrero en particular debería ser un placer para
usar, ya que mejora la eficiencia y la calidad de todo otro trabajo. ¡Hurra por los
sistemas de diseño!
Por lo general, los creadores de sistemas de diseño en organizaciones más
pequeñas serán personal de alto nivel que tiene la experiencia para tomar
decisiones bien pensadas y la autoridad para hacer cumplir el sistema de diseño.
Y luego están las agencias externas, los contratistas y los consultores.
¿Cuál es el papel de un tercero cuando se trata del mantenimiento a largo
plazo del sistema de diseño de un cliente? Por un lado, externo
los socios están un poco en desventaja ya que en realidad no trabajan para la
organización de su cliente. Un sistema de diseño exitoso debe convertirse en parte del
ADN de una organización y, dado que existen terceros fuera de los muros de la
empresa, su influencia es intrínsecamente limitada.
Pero, por otro lado, las partes externas a menudo pueden proporcionar un sentido
de perspectiva que es difícil de ver cuando se trabaja dentro de una empresa.
Aquí es donde los forasteros realmente pueden brillar. En mi trabajo como consultor,
trabajo con organizaciones para establecer estrategias de mantenimiento de sistemas
de diseño a largo plazo y ayudo a implementar las personas y los procesos correctos.
Si bien el éxito a largo plazo del sistema dependerá en última instancia de la
organización, los terceros pueden enseñarles a pescar y brindar orientación estratégica
importante, retroalimentación y perspectiva.
Usuarios del sistema de
diseño ¿Quiénes son las personas responsables de usar el sistema de diseño para
crear nuevas funciones y aplicaciones? ¿Quiénes son las personas que hablan con
los fabricantes de sistemas para informar problemas y solicitar funciones?
Una vez más, las respuestas a estas preguntas dependerán en gran medida del
tamaño y la estructura de su organización.
Los usuarios del sistema de diseño pueden ser el mismo equipo que crea el
sistema de diseño, equipos de desarrollo separados dentro de su organización,
diseñadores y desarrolladores de nivel junior, agencias asociadas, talleres de
desarrollo externos u otros equipos de terceros.
La proximidad de los usuarios y la participación en la creación del sistema de
diseño sin duda variará. Puede trabajar en un producto singular en una startup
rudimentaria, por lo que su pequeño equipo podría estar creando y utilizando
simultáneamente el sistema de diseño. O puede trabajar en una gran corporación
multinacional con equipos de desarrollo y socios externos repartidos por todo el
mundo. Si este es el caso, es posible que los creadores de sistemas de diseño y los
usuarios rara vez (o nunca) se reúnan, lo que significa que la documentación útil y
una perspectiva nítida a vista de pájaro se vuelven mucho más importantes.
Existe un espectro de relaciones potenciales entre los usuarios y los creadores del sistema de diseño,
y el tamaño y la composición de su empresa sin duda darán forma a esas relaciones.
Una de las mayores ventajas de establecer un sistema de diseño reflexivo es que permite a las
organizaciones escalar las mejores prácticas. Si todas esas mejores prácticas (capacidad de respuesta,
accesibilidad, rendimiento, UX, ergonomía, etc.) se integran en el sistema, los usuarios pueden
simplemente conectar los patrones y obtener las recompensas. Esto significa que los usuarios del
sistema de diseño no tienen que ser diseñadores o desarrolladores de alto nivel para producir un buen
trabajo; el sistema de diseño sirve como un vehículo de control de calidad que ayuda a los usuarios a
aplicar las mejores prácticas independientemente del nivel de habilidad de cada individuo.
Composición del equipo del sistema de diseño.
Se debe establecer un equipo interdisciplinario para administrar, mantener y ampliar
adecuadamente el sistema. Todas las disciplinas en una organización (diseñadores de UX,
diseñadores visuales, estrategas de contenido, desarrolladores frontend, desarrolladores backend,
gerentes de productos, gerentes de proyectos, ejecutivos y otras partes interesadas) tienen perspectivas
únicas que sin duda pueden informar y dar forma al trabajo. La incorporación de estas perspectivas en
el sistema de diseño es importante, pero no necesariamente requiere que todas las disciplinas estén
constantemente involucradas en su desarrollo.
Inevitablemente, habrá disciplinas que hagan el trabajo activamente, mientras que
otras pueden asumir un papel más de asesoramiento. Los responsables de diseñar
y construir la interfaz de usuario (diseñadores de UX, diseñadores visuales,
desarrolladores frontend) probablemente servirán como las manos que hacen el
trabajo y actualizan el sistema de diseño.
Deben trabajar en colaboración (como se detalla en el capítulo 4) y coordinarse
con otras disciplinas para garantizar que el sistema refeje los valores y
consideraciones de todo el negocio.
Es posible que otras personas no sean las que realizan activamente el trabajo,
pero deben ser consultadas para asegurarse de que sus perspectivas se reflejen
adecuadamente en el sistema. Los ingenieros de backend deben informar al equipo
sobre cualquier decisión arquitectónica que pueda afectar la interfaz de usuario de
frontend; los ejecutivos deben informar al equipo sobre iniciativas importantes que
afectarán el rol y la utilidad del sistema; y, por supuesto, los usuarios del sistema de
diseño deben coordinarse con los fabricantes para garantizar que el sistema satisfaga
las necesidades de las aplicaciones individuales.
Hazlo adaptable
El cambio es la única constante, como dicen. La parte viva de un sistema de diseño
vivo significa que necesita adaptarse a los golpes, adaptarse a los comentarios,
repetirse y evolucionar junto con los productos a los que sirve.
Una idea errónea sobre los sistemas de diseño es que, una vez
establecidos, se convierten en una fuente de verdad omnipotente e inmutable.
Pensar de una manera tan rígida es una forma segura de hacer que su sistema de
diseño se esfuerce de nuevo. Si los usuarios se sienten atados y encasillados en el
uso de patrones que no resuelven sus problemas, percibirán el sistema de diseño
como una herramienta inútil y comenzarán a buscar en otra parte algo que satisfaga
mejor sus necesidades.
La creación de un plan de gobierno claro es esencial para asegurarse de
que su sistema de diseño pueda adaptarse y prosperar a medida que pasa el
tiempo. Una estrategia de gobierno sólida comienza respondiendo algunas preguntas
importantes sobre el manejo del cambio. Considera lo siguiente:
¿ Qué sucede cuando un patrón existente no funciona del todo para una
aplicación específica? ¿Se modifica el patrón? ¿Recomiendas usar un patrón
diferente? ¿Es necesario crear un nuevo patrón? ¿Cómo se gestionan las
solicitudes de nuevos patrones?
¿Cómo se retiran los patrones antiguos?
¿Qué sucede cuando se encuentran errores?
¿ Quién aprueba los cambios al sistema de diseño? ¿ Quién es
responsable de mantener la documentación al día? ¿ Quién realiza cambios en
los patrones de la interfaz de usuario del sistema? ¿ Cómo se implementan los
cambios del sistema de diseño en las aplicaciones en vivo? ¿Cómo se enterará la
gente de los cambios?
Es probable que haya muchas más preguntas específicas para responder, pero el punto
es que su equipo debe tener respuestas y procesos para abordar los cambios inevitables
en el sistema.
Como ya se mencionó varias veces, la comunicación y colaboración frecuente entre los
creadores y los usuarios es clave para gobernar con éxito su sistema de diseño. Facilite
al máximo la comunicación entre usuarios y fabricantes. Configure un sistema de diseño
de canales de Slack o Yammer, establezca horarios regulares de oficina, asegúrese de
que su software de tickets de errores ayude a facilitar la conversación y mantenga las
puertas abiertas para chats y llamadas ad hoc. Si los usuarios están atascados en algo, deben
saber exactamente dónde y a quién acudir en busca de ayuda.
Además de las conversaciones informales del día a día entre los creadores y los usuarios,
programe reuniones periódicas del "estado de la unión" para revisar el sistema de diseño
con los creadores, los usuarios y otras partes interesadas clave. Analice lo que funciona,
sea honesto con lo que debe mejorarse y revise las prioridades y la hoja de ruta para
asegurarse de que el sistema satisfaga las necesidades del negocio. Estos controles
regulares son especialmente útiles para mantener a los interesados actualizados, ya que a
menudo no participan en el día a día de las operaciones del sistema de diseño.
Hacer cambios en los patrones
Una parte fundamental del mantenimiento del sistema de diseño es garantizar que los
patrones de la interfaz de usuario se mantengan actualizados, adopten las mejores prácticas
de diseño y desarrollo en evolución y continúen abordando las necesidades reales de la
organización.
Desarrollar una estrategia para manejar los cambios de patrón es crucial, razón por la cual
Inayaili de León Persson y el equipo web de Canonical dedicaron
tiempo para trazar su estrategia a medida que creaban el marco de frontend de Vanilla.
Pensamos que sería bueno documentar el proceso que debe
seguir un patrón para convertirse en un patrón Vanilla, así que
después de un poco de lluvia de ideas, creamos un diagrama que
muestra los diferentes pasos que se deben seguir antes de enviar
un patrón. propuesta a su plena aceptación como patrón Vanilla.
Inayaili de León Persson, Canonical
El resultado es un hermoso árbol de decisiones que traza exactamente qué procesos
deben ocurrir para agregar un nuevo patrón al sistema de diseño.
El equipo web de Canonical trazó el proceso de decisión utilizado para administrar las actualizaciones y las adiciones
a los patrones en el marco de frontend de Vanilla.
Los tres tipos de cambios que pueden ocurrir en los patrones de un sistema de diseño
son la modificación, la adición y la eliminación.
Modificación de patrones
Los patrones de la interfaz de usuario pueden y deben modificarse por varias
razones: adiciones de características, correcciones de errores, ajustes de diseño
visual sutiles o importantes, mejoras de rendimiento, mejoras de accesibilidad,
refactorización de código, actualizaciones de mejores prácticas de UX, etc.
Los mantenedores del sistema de diseño deben comprender por qué y cuándo
modificar los patrones, cómo realizar esos cambios y cómo implementar esas
mejoras en aplicaciones individuales.
Mantener los patrones frescos es esencial para la salud a largo plazo del
sistema de diseño. ¡Nadie quiere usar y mantener un sistema de diseño
con aspecto de Web 2.0 lleno de biseles y código crujiente!
Agregar patrones
A pesar de lo inteligente que seguramente es su equipo, es muy posible que no
piense en todos los patrones concebibles para incluir en su sistema de diseño
desde el principio. A medida que el sistema se aplica a más productos,
inevitablemente surgirán brechas donde las necesidades de la aplicación no se
resuelvan con los patrones existentes. En tales casos, quedará claro que será
necesario crear nuevos patrones para abordar estas necesidades.
Se debe tener cuidado al agregar patrones a la biblioteca. Si cada capricho da
como resultado un patrón completamente nuevo, el sistema de diseño se
convertirá en un salvaje oeste inflado y difícil de manejar. Vale la pena preguntarse
si esta es una situación única o algo que se puede aprovechar en otras
aplicaciones.
Tal vez desee asumir un caso único hasta que un equipo diferente encuentre
un caso de uso similar. Si el equipo que trabaja en la Aplicación 2 mira la
Aplicación 1 y dice: "¡Quiero eso!" tal vez ese sea un buen indicador de que
se debe agregar un patrón uno a la biblioteca de patrones.
Eliminación de patrones
Los patrones pueden quedar obsoletos por varias razones. Quizás descubra
a través del uso que un patrón en particular es una idea terrible.
La retrospectiva es 20/20, amigo mío. Tal vez la industria se ha alejado de un
patrón por razones técnicas o de UX. Tal vez un patrón permaneció allí sin ser
utilizado por ninguna aplicación durante mucho tiempo. Tal vez los usuarios
respondieron con muchos comentarios negativos sobre trabajar con un patrón en
particular.
Tener un plan para descartar patrones es una gran idea. Pero, ¿cómo se
eliminan los patrones del sistema de diseño sin sacar la alfombra debajo de
las personas que confían en esos patrones en su
aplicaciones? Para abordar este problema, Salesforce creó una utilidad ordenada
llamada Sass Deprecate eso marca patrones que se dirigen al tajo en un futuro
cercano. Mediante un uso inteligente de las etiquetas y estilos variables de Sass, el
equipo de creadores puede avisar a los usuarios de que un patrón en particular está
obsoleto y recomendar un patrón alternativo en su lugar.
Hazlo mantenible
Con toda esta charla sobre modificar, agregar y eliminar patrones, es posible que
se pregunte: "¿Cómo diablos se supone que nuestras aplicaciones deben mantenerse
al día con todos estos cambios?" Y al hacer esa pregunta, se habrá topado con uno
de los mayores desafíos que enfrentan las organizaciones para mantener con éxito
un sistema de diseño.
La mayor amenaza existencial para cualquier sistema es la negligencia.
Alex Schleifer, Airbnb
Muchos sistemas caen en un estado de deterioro debido a que el esfuerzo
requerido para realizar actualizaciones es demasiado alto. Si es difícil y requiere
mucho tiempo actualizar los patrones, la documentación y las aplicaciones, la
gente eventualmente se sentirá tan frustrada que dejarán de hacer el esfuerzo y
el sistema de diseño comenzará a caer en el olvido.
La actualización de los patrones de la interfaz de usuario, la documentación y las
aplicaciones debe ser lo más fluida posible, por lo que reducir esta fricción debe
convertirse en una alta prioridad para el equipo de diseño del sistema. Esto implica
una cuidadosa consideración tanto desde el punto de vista tecnológico como del
flujo de trabajo.
En busca del santo grial
El santo grial del sistema de diseño implica crear un entorno en el que la biblioteca
de patrones y las aplicaciones en vivo estén perfectamente sincronizadas. La idea
es que debería poder realizar un cambio en un patrón de interfaz de usuario y ver
que el cambio se refleja automáticamente tanto en la biblioteca de patrones como
en cualquier lugar donde el patrón esté incluido en la producción.
El santo grial de los sistemas de diseño es un entorno en el que realizar cambios en un patrón de interfaz de usuario
actualiza simultáneamente la biblioteca de patrones y las aplicaciones de producción.
Esta técnica elimina cualquier duplicación de esfuerzos y garantiza que la
biblioteca de patrones y las aplicaciones que utilizan los patrones permanezcan
sincronizadas. Suena como un sueño, ¿verdad?
Resulta que este sueño puede ser una realidad. Lonely Planet, la compañía
de guías de viaje, fue una de las primeras en establecer un sistema de diseño del
santo grial llamado Rizzo. A través de una arquitectura inteligente, crearon una API
para sus patrones de interfaz de usuario que alimenta su entorno de producción y
su biblioteca de patrones. El resultado es un sistema de diseño centralizado que
garantiza que su aplicación y documentación en vivo permanezcan perfectamente
sincronizadas.
Este enfoque no es una tarea fácil, ya que requiere una arquitectura técnica
sofisticada, personas inteligentes para configurarlo todo y una cultura organizacional
relativamente centralizada. La forma en que persigue el santo grial, o incluso si
puede lograrlo, depende de una gran cantidad de factores, incluida su arquitectura
técnica y su estructura organizativa.
Lonely Planet creó una API para sus patrones de interfaz de usuario que consumen tanto su biblioteca de patrones como
su entorno de producción. Al construir su sistema de diseño de esta manera, los cambios en los patrones de la interfaz de
usuario se reflejan automáticamente tanto en la biblioteca de patrones como en el entorno de producción.
Superando obstáculos técnicos
Mantener una biblioteca de patrones sincronizada con los entornos de
producción requiere compartir el código de una manera inteligente, escalable y mantenible.
Detallar todas las diferentes estrategias y consideraciones técnicas en torno al
santo grial necesitaría su propio libro, pero cubramos algunas áreas importantes para
mantener sincronizado el código frontend.
El frontend de las cosas
Un sistema de diseño de interfaz de usuario se manifiesta como el frontend
de una experiencia web, que se compone de HTML, CSS y JavaScript. La tarea que
tenemos entre manos es cómo llevamos ese código frontend a un entorno de
producción, con una lógica de aplicación compleja y un código backend.
En su artículo “Persiguiendo el Santo Grial”, el desarrollador web Marcelo
Somers detalla varios enfoques técnicos para lograr el santo grial. Destaca los
pros y los contras de cada estrategia para alimentar a un
sistema de diseño en aplicaciones para mantener ambas bases de código al mismo tiempo.
Si bien no detallaré cada una de las estrategias de Marcelo, vale la pena señalar que hay
un espectro de enfoques para elegir: copiado y pegado de código frontend manual y crudo
en un extremo, para hornear la biblioteca de patrones directamente en el entorno de
producción en el otro.
En mi experiencia, descubrí que compartir CSS y JavaScript de presentación con
entornos de producción es relativamente fácil, mientras que compartir marcado es difícil.
Debido a que CSS y JavaScript tienden a compilarse en un solo archivo (o quizás en un
puñado de archivos), es posible colocarlos en un CDN y luego simplemente vincularlos a
esos archivos en cada aplicación. Marcelo explica cómo hacer esto teniendo en cuenta las
versiones:
Proporcionaría a los equipos de desarrollo una URL con versión
(p. ej., http://mycdn.com/1.3.5/styles.css) y la actualización es tan
simple como subir el número de versión en la URL.
Marcelo Somers
Compartir CSS y JavaScript está muy bien, pero donde las cosas se complican es
cuando desea compartir el marcado entre entornos.
¿Por qué? usted pregunta. Bueno, el marcado y la lógica de backend a
menudo se entrelazan en el código base de una aplicación, lo que tiende a dificultar
simplemente copiar y pegar el marcado entre su biblioteca de patrones y los entornos
de producción. Afortunadamente, hay formas de evitar este problema.
Cerrando la brecha del marcado con lenguajes de plantillas El uso de
lenguajes de plantillas HTML (como Mustache, Handlebars, Twig, Underscore, Jade,
Nunjucks y muchos otros) hace que el marcado sea más portátil y dinámico. Los lenguajes
de plantillas separan la estructura y los datos, y potencian nuestro HTML para evitar que
tengamos que escribir los mismos patrones de marcado una y otra vez. La buena noticia es
que muchos CMS y entornos de aplicaciones también utilizan lenguajes de plantillas para
ofrecer marcas de frontend.
El lenguaje de plantillas puede servir como puente entre su biblioteca de
patrones y los entornos de producción. Si usa un lenguaje de plantillas
para crear los patrones en su sistema de diseño (algo que discutimos
extensamente en el capítulo 3), puede compartir fácilmente esos patrones
con entornos de producción que utilizan el mismo motor de plantillas.
Un lenguaje de plantillas como Mustache, Handlebars, Underscore, Jade y otros puede servir como un puente
que permite compartir el código frontend entre la biblioteca de patrones y la aplicación de producción.
El equipo de Phase2 Technology logró el santo grial al usar Pattern Lab
como su herramienta de desarrollo de biblioteca de patrones y Drupal. como
su sistema de gestión de contenidos. Porque tanto Pattern Lab como Drupal
son compatibles con el popular Twig motor de plantillas, Phase2 puede
compartir fácilmente patrones entre los dos entornos, asegurando que las
bibliotecas de patrones de sus clientes y las compilaciones de producción
estén siempre sincronizadas entre sí.
Al usar el mismo motor de plantillas, junto con la ayuda del
módulo Drupal de bibliotecas de componentes, la herramienta le
da a Drupal la capacidad de incluir, extender e incrustar
directamente las plantillas Twig que Pattern Lab usa para sus
componentes sin ninguna duplicación de plantilla.
Evan Lovely, tecnología Phase2
¿Tu cultura es compatible con el santo grial?
Es posible que hayas leído la última sección y hayas pensado: “¡Es increíble!
¡Mi empresa necesita esto ahora!” Si bien los sistemas del santo grial son realmente
geniales, hay razones por las que es posible que no pueda mantener
automáticamente sincronizados sus entornos de producción y su biblioteca de patrones.
Quizás su organización crea toneladas de productos digitales en muchas plataformas
diferentes utilizando tecnologías muy diferentes. Tal vez seas una multinacional
gigante repartida por todo el mundo.
Tal vez su empresa tenga una cultura autónoma extremadamente descentralizada.
O tal vez eres un gobierno federal gigantesco.
El borrador de los estándares de diseño web de EE. UU. es el sistema de diseño del gobierno federal de los Estados Unidos.
El sistema de diseño del gobierno de EE. UU., llamado Borrador de estándares
digitales web de EE. UU. – es una colección de componentes de interfaz de
usuario y estilos visuales creados para ayudar a las personas que crean sitios
web gubernamentales a crear interfaces de usuario más consistentes. El sistema de
diseño proporciona marcas y estilos para que los usuarios los descarguen y entrelacen
en sus aplicaciones. Sin duda, sería increíble ver un sistema de diseño del santo grial
implementado a una escala tan gigantesca, pero como se puede imaginar, es una
tarea bastante difícil. La inmensidad y la naturaleza descentralizada de la organización.
significa que una biblioteca de patrones sincronizados no se puede lograr sin una
reestructuración drástica de cómo se construyen los sitios web del gobierno
federal.
Si una cultura relativamente dispersa y descentralizada es su realidad, ¡no se
desanime! Incluso implementar algún sistema de diseño (un puñado de patrones de
interfaz de usuario, alguna documentación útil y principios rectores) puede mostrarle
a su organización la luz que apunta hacia el grial. Como hemos discutido a lo largo
de este capítulo, estos esfuerzos deben ser continuos, y antes de que pueda correr,
primero debe aprender a gatear.
Hazlo interdisciplinario
Las guías de estilo a menudo saltan directamente a los fragmentos de código y
al uso de patrones para beneficio de los usuarios del sistema de diseño. Por
supuesto, una biblioteca de patrones debe ser útil para las personas que realmente
usan los patrones, pero tratar una guía de estilo únicamente como un recurso para
desarrolladores limita su potencial.
Una guía de estilo tiene la oportunidad de servir como abrevadero para toda la
organización, ayudando a establecer un vocabulario común para cada disciplina
que invierte en el éxito de los productos digitales de la empresa. Establecer este
vocabulario común puede conducir a un trabajo más eficiente, una mejor comunicación
y una mayor colaboración entre disciplinas en toda la organización. Es por eso que
la guía de estilo debe ser un lugar atractivo para todos, no solo para los usuarios del
sistema de diseño.
Toma el carrusel (¡por favor!). Este componente es asombrosamente complejo
desde un punto de vista organizativo. Un carrusel de página de inicio en un sitio
web de comercio electrónico requiere aportes de una gran cantidad de disciplinas
en toda la organización. Los dueños de negocios y el personal editorial deben elegir
los productos que se mostrarán en el carrusel. Los redactores deben asegurarse de
que la copia sea efectiva y se mantenga dentro de las limitaciones del diseño. Los
directores de arte deben asegurarse de que el diseño estético sea agradable y que
la fotografía del producto sea legible en todos los tamaños de pantalla. Los
diseñadores de UX deben confrmar que la funcionalidad y los controles sean intuitivos.
Las personas de frontend deben asegurarse de que el componente responda, sea
accesible y tenga un buen rendimiento. Los desarrolladores de backend deben
asegurarse de que el componente esté correctamente conectado al sistema de back
end. Entiendes la idea.
Un carrusel de página de inicio en un sitio como Walmart requiere aportes de muchas disciplinas y partes
interesadas diferentes. Una guía de estilo puede ayudar a reunir esas diferentes perspectivas bajo un mismo techo.
Una guía de estilo bien elaborada puede ayudar a administrar todas estas partes móviles y
garantizar que las muchas perspectivas que influyen en cada patrón estén debidamente
documentadas en la guía de estilo. Haga que la biblioteca de patrones sea accesible para
todas las disciplinas y piense en cómo hacer que sea fácil y atractivo para que las diferentes
disciplinas contribuyan a la documentación.
Hazlo accesible
No debería sorprender a nadie que las personas tienden a gravitar hacia las cosas atractivas.
Una gran parte de hacer que una guía de estilo sea un recurso interdisciplinario es asegurarse
de que el contenedor que alberga su biblioteca de patrones y otra documentación sea
atractivo, atractivo y fácil de navegar.
Tomarse el tiempo para crear un hogar atractivo para su guía de estilo y documentación puede
conducir a un mayor uso, ayudar a crear conciencia, ayudar a crear una inversión
organizacional y ayudar a que los ojos de los no desarrolladores se fijen en la guía de estilo.
Todo esto contribuye a ese importante vocabulario compartido que conduce a una mejor
colaboración interdisciplinaria.
Pero la creación de una experiencia de guía de estilo intuitiva y de excelente
apariencia no es algo que sucede de la nada, y esto puede ser problemático cuando se obtiene
La guía de estilo de Yelp tiene una portada atractiva y amigable que explica qué es el recurso, para
quién es y cómo usarlo.
una guía de estilo de la tierra. Si los equipos piensan que hacer una
guía de estilo útil implica hacer algo grande y oficial con una marca
personalizada y un sitio web brillante, es posible que se sientan
disuadidos de comenzar la iniciativa. Así que recuerda:
1. Hacer una cosa.
2. Demuestra que es útil.
3. Hazlo oficial.
Crear un sistema de diseño útil debe ser la primera prioridad del
equipo. Es posible que construir un hogar feliz que contenga todo no
suceda de inmediato, pero debería convertirse en una prioridad mayor
una vez que el sistema de diseño se haga oficial. Hacer una guía de
estilo atractiva no es solo diseño por el diseño; refeja el compromiso de
una organización de crear y mantener un sistema de diseño reflexivo y
deliberado.
Hazlo visible
La visibilidad es de vital importancia para la salud continua de su
sistema de diseño. Un esfuerzo tan importante no debe ser escondido
lejos en un rincón oscuro de su intranet. ¿Qué pasos puede tomar para garantizar
que el sistema de diseño siga siendo la piedra angular de sus flujos de trabajo de
diseño y desarrollo?
Evangelización del sistema de diseño
Puede crear la mejor guía de estilo del mundo, usar la tecnología más
sofisticada, tener un equipo increíble y tener usuarios entusiasmados, pero si no
promueve activamente el sistema de diseño y comunica los cambios, todo el
esfuerzo sufrirá mucho.
Los esfuerzos de evangelizar su sistema de diseño pueden y deben ocurrir
incluso antes de que el sistema esté listo. Al comienzo de su proyecto, puede
configurar lugares para documentar el progreso del proyecto para ayudar a
generar conciencia y entusiasmo por el esfuerzo del sistema de diseño. Un cliente
mío creó un blog interno para publicar actualizaciones del proyecto, así como un
canal de Yammer del sistema de diseño donde los desarrolladores y otras partes
interesadas pueden compartir ideas, abordar inquietudes, enviar comentarios y
hacer preguntas. Establecer una cultura de comunicación al principio del proceso
aumentará la probabilidad de que el sistema de diseño eche raíces.
Comunicando el cambio
Una vez que el sistema de diseño está listo y se está utilizando en aplicaciones
reales, es imperativo comunicar los cambios, las actualizaciones y una visión
continua a toda la organización.
Las tácticas para esta comunicación pueden variar desde utilidades básicas hasta
esfuerzos de marketing más abiertos. Aquí hay algunos materiales que pueden
ayudar a comunicar el cambio:
Registros de cambios: “Esto es lo que ha cambiado en la biblioteca de patrones este
mes."
Hoja de ruta: “Esto es lo que sucederá en los próximos
meses."
Casos de éxito: “El equipo X lanzó esta gran aplicación nueva utilizando el
sistema de diseño; lea más sobre cómo lo hicieron”.
Consejos y trucos: “Estas son algunas de las mejores prácticas y
consideraciones para el uso de los botones de nuestro sistema en toda su
aplicación.”
Tener una base para todos estos materiales es una gran idea, y mantenerlos
junto a (o incluso dentro) de la guía de estilo también tiene mucho sentido.
El equipo de diseño de materiales publica un práctico registro de cambios dentro de su guía de estilo para que los
usuarios puedan conocer fácilmente las últimas actualizaciones y mejoras del sistema.
Los cambios, actualizaciones y solicitudes del sistema de diseño deben
comunicarse donde sea que se encuentre su equipo. Eso puede incluir Slack,
Basecamp, GitHub, wikis, Yammer, listas de correo electrónico, blogs de la
empresa, intranets y cualquier otra herramienta interna que use su equipo para
comunicarse y colaborar. Si eso suena como mucho trabajo para
¡tú, no temas! Mantener a su equipo y usuarios actualizados no tiene por qué requerir
un gran esfuerzo manual. Gracias a la naturaleza conectada de nuestras herramientas,
los equipos pueden recibir alertas automáticas sobre los cambios a través del
software, como explica Micah Sivitz de Shyp:
Cada vez que alguien realiza una solicitud de incorporación de cambios, envía
una notificación a nuestro canal de slack #Design, anunciando al equipo que
hay un cambio en la propuesta y que se requieren comentarios.
Micah Sivitz, Shyp
Integrar esta comunicación en el flujo de trabajo diario del equipo mantiene comprometidos
a los creadores, usuarios y partes interesadas, y ayuda a asegurar a los usuarios que la
biblioteca de patrones se mantiene y mejora activamente.
Entrenamiento y soporte
No le entregarías a alguien un martillo, una sierra y un destornillador y luego dirías: “Muy
bien, tienes lo que necesitas; ahora ve y constrúyeme una casa nueva y hermosa”. Saber
cómo utilizar correctamente una herramienta suele ser incluso más importante que la
disponibilidad de esa herramienta. La documentación en forma de guía de estilo es sin
duda útil, pero por sí sola no es suficiente. Es esencial brindar una capacitación adecuada
y ofrecer soporte continuo a los usuarios de su sistema de diseño para garantizar que se
pongan en marcha con éxito con el conjunto de herramientas y continúen creando un gran
trabajo con él.
Capacitar a los usuarios sobre cómo trabajar con el sistema de diseño puede tomar
muchas formas, que incluyen:
Sesiones en pareja: No hay nada mejor que levantar una silla y trabajar juntos en
un proyecto. Si bien requiere más tiempo que otros vehículos de capacitación, es
la mejor manera de lograr que los fabricantes y usuarios colaboren juntos,
aprendan cómo funciona el sistema y expongan nuevas oportunidades y
deficiencias.
Talleres: desde sesiones inmersivas de día completo hasta caminatas rápidas
a través de, es increíblemente útil organizar talleres de capacitación cara a cara que
involucren tanto a los fabricantes como a los usuarios. Estas sesiones pueden ayudar
a aclarar cualquier concepto erróneo sobre el sistema, ayudar a subir de nivel a los
usuarios con orientación práctica y crear una relación saludable entre las personas a
cargo de mantener el sistema y las personas a cargo de trabajar con él.
Seminarios web: si no es posible realizar talleres o sesiones en pareja, o si necesita
capacitar a muchos usuarios a escala, los seminarios web pueden ser fantásticos.
Los usuarios pueden sintonizar sesiones en línea para aprender cómo
utilizar correctamente el sistema. Al realizar seminarios web, asegúrese de incluir
mucho tiempo de preguntas y respuestas para enviar preguntas, inquietudes y
comentarios tanto en audio como escritos.
Tutoriales: una serie de publicaciones de blog y screencasts pueden
encapsular los conceptos básicos del trabajo con el sistema de diseño.
Estos no solo sirven como una herramienta de capacitación, sino que también
pueden servir como una gran referencia a la que volver.
Incorporación: una excelente manera de inyectar su sistema de diseño en la cultura de
su empresa es integrar la capacitación del sistema de diseño directamente en el
proceso de incorporación para los nuevos empleados. Los nuevos colegas comprenderán
la importancia de la modularidad, la reutilización y todos los demás beneficios que brinda
un sistema de diseño.
Sin duda, los usuarios tendrán preguntas o encontrarán problemas una vez que se
pongan en marcha y comiencen a construir cosas con el sistema de diseño. Necesitan
saber que existe un sólido sistema de soporte para ayudar a responder cualquier pregunta,
escuchar sus requisitos y solucionar errores. Hay una gran cantidad de mecanismos para
brindar apoyo a los usuarios, que incluyen:
Rastreadores de problemas: las herramientas como JIRA y GitHub Issues son
excelentes para que los usuarios y los creadores informen errores y tengan
conversaciones técnicas. Los usuarios deben conocer el protocolo para enviar errores
y sentirse autorizados a contribuir. Horas de oficina: Programe horarios regulares
en los que el equipo del sistema de diseño esté disponible para responder preguntas,
abordar problemas y hablar sobre lo que sigue para el sistema de diseño.
Slack y herramientas de chat: la naturaleza en tiempo real de muchas de nuestras
Las herramientas de colaboración en el trabajo presentan una gran oportunidad
para mantener viva la conversación cargada de patrones. Gracias a herramientas
como Slack, Yammer y HipChat, los creadores y los usuarios pueden interactuar entre
sí en cualquier momento y lugar.
Foros: comunidades como Stack Overfow y GitHub han demostrado ser
extremadamente eficaces para permitir el apoyo de base impulsado por la
comunidad. En lugar de que los fabricantes de sistemas de diseño se conviertan en un
cuello de botella de soporte, puede valer la pena abrir el soporte a toda la comunidad
de usuarios.
Alcance: no todos tienen el tiempo o la personalidad para preguntar
preguntas y sugerir cambios. Los creadores de sistemas de diseño deben ser proactivos
y comunicarse con los desarrolladores que utilizan el sistema de diseño para ver si tienen
algún problema o inquietud. Este tipo de acciones pueden ayudar a construir una relación
genuina y positiva entre creadores y usuarios.
El sistema Draft US Web Digital Standards realiza un seguimiento de los problemas mediante GitHub, proporcionando un lugar para
que los usuarios y los creadores presenten errores y conversen sobre los detalles esenciales.
Gracias a herramientas como GitHub, los usuarios de sistemas de diseño no tienen que
ser relegados al papel de consumidores tontos. Las personas que usan el sistema día tras
día pueden ser contribuyentes extremadamente valiosos para el sistema de diseño si se les da
la oportunidad. Acepte el hecho de que los usuarios están ansiosos por participar y hacer que
el sistema sea lo mejor posible. Aquí hay algunas tácticas para alentar las contribuciones de
los usuarios:
Sugerencias y solicitudes de incorporación de cambios: anime a cualquiera que utilice
sistema de diseño para sugerir cambios y nuevas características. Mejor aún, invite a los
usuarios a enviar cambios en forma de solicitudes de extracción que se pueden fusionar
directamente en el código base.
Entrevistas individuales y mesas redondas: siempre es una buena idea hablar con los
usuarios, por lo tanto, programe tiempo para conversar con las personas que tocan
estos patrones de manera regular. Asómelo todo, escuche tanto lo bueno como lo malo
y determine colectivamente un plan de ataque para abordar cualquier problema y
sugerencia.
Solicitudes de comentarios: Administrar un sistema que potencialmente se
puede implementar en cientos de aplicaciones puede ser complicado. Antes
de tomar decisiones que podrían afectar a muchas personas, pida opiniones:
"Estamos considerando desaprobar nuestro patrón de carrusel y nos gustaría
saber lo que piensa".
Encuestas: si las entrevistas no son factibles, puede apoyarse en
encuestas para tener una idea de cuán efectivos son los patrones de interfaz
de usuario y la guía de estilo. Preguntas como “En una escala del uno al
cinco, ¿qué tan útil es la documentación del patrón? ¿Alguna sugerencia?"
puede ayudar a identificar puntos ciegos y hacer que los usuarios sugieran
funciones que les facilitarían la vida.
Reuniones periódicas del “estado de la unión”: programe
reuniones donde el equipo del sistema de diseño analiza la hoja de ruta del
producto, las lecciones aprendidas en el camino y las sugerencias y
comentarios. Anime a todos a unirse a la reunión y asegúrese de grabar y
distribuir estas sesiones para que todos conozcan el plan maestro.
hazlo publico
Comunicar el cambio, evangelizar y establecer la capacitación y el apoyo
adecuados son excelentes cosas para aumentar la visibilidad de su sistema. Pero
hay otra gran oportunidad para llevar su estrategia de comunicación a otro nivel:
hacer que su guía de estilo sea accesible al público.
¿Por qué? ¿No es una guía de estilo simplemente un recurso interno para ayudar
a las personas de su organización a trabajar mejor juntas? ¿De qué sirve para el
mundo exterior? ¿Y la publicación de su guía de estilo no revelaría todos sus
secretos comerciales?
Publicar su guía de estilo para que el mundo la vea aumenta su visibilidad,
aumenta la responsabilidad y sirve como una increíble herramienta de
reclutamiento.
Poner su guía de estilo detrás de un inicio de sesión o un firewall reduce la
visibilidad y agrega una carga innecesaria a su equipo y socios, lo que limita la
efectividad y el potencial del recurso. Y los temores de revelar sus secretos
comerciales son completamente infundados.
Estos son patrones de interfaz de usuario, no códigos nucleares.
Styleguides.io reúne más de 150 guías de estilo públicas de organizaciones de todo el mundo.
Además de facilitar el acceso a la documentación importante, una guía de estilo pública ayuda
a crear responsabilidad organizacional.
La publicación de su guía de estilo demuestra el compromiso de su organización con el
sistema de diseño, lo que crea un poco de presión útil para mantenerlo actualizado y como un
recurso útil.
Las guías de estilo de cara al público también son muy útiles para el reclutamiento.
Los diseñadores, desarrolladores y personas que trabajan en otras disciplinas quieren
trabajar para organizaciones que adoptan las mejores prácticas digitales modernas y (como
hemos discutido a lo largo de este libro) los sistemas de diseño se están convirtiendo
rápidamente en una mejor práctica en toda la industria.
La publicación de su guía de estilo envía una fuerte señal de murciélago que puede atraer
a personas apasionadas y con mentalidad de patrones. Por ejemplo, la experta en guías de
estilo Jina Bolton se fue a trabajar a Salesforce después de ver la guía de estilo de la empresa
para su producto Salesforce1.
Cuando vi [la guía de estilo de Salesforce] pensé que era
hermosa y por eso quise unirme a este equipo.
El nombre Bolton
Desde que se unió a Salesforce, ayudó a crear el Lightning Design System
de gran éxito y ayuda a administrar su creciente equipo de sistemas de
diseño. La historia de Jina no es aislada; casi todos los invitados que Anna
Debenham y yo entrevistamos en Styleguides Podcast discutieron cuán útil fue
su biblioteca de patrones de cara al público para atraer talento. Todo eso
significa que su guía de estilo pública hace que su organización sea más
competitiva, no menos.
Hazlo más grande
Una biblioteca de patrones visible, interdisciplinaria y accesible es una a la
que su equipo volverá una y otra vez. Usa eso a tu favor. Dado que los globos
oculares del equipo ya están fijos en ese recurso, existe una gran oportunidad
de ampliarlo para incluir otra documentación útil como la voz y el tono, la marca,
el código, los principios de diseño y las pautas de escritura que discutimos en el
capítulo 1 .
El sistema de diseño Harmony de Intuit incluye una biblioteca de patrones, principios de diseño,
voz y tono, pautas de marketing y más. Alojando esta útil documentación bajo un mismo techo ayuda a
aumentar su visibilidad y efectividad.
Ahora, es posible que su organización no necesite implementar todos los
favores de la guía de estilo, pero el punto es que la creación de un centro de
guía de estilo centralizado genera más conciencia de las mejores prácticas,
aumentando la efectividad de la documentación.
Otra forma de ampliar la funcionalidad de la biblioteca de patrones es incluir pautas para
patrones de plataforma nativa junto con patrones basados en la web. Podemos mirar el
sistema de diseño Harmony de Intuit una vez más para ver un ejemplo de cómo los patrones
nativos de la plataforma móvil para iOS y Android pueden convivir con sus contrapartes
basadas en la web.
La biblioteca de patrones Harmony de Intuit incluye botones para cambiar entre web, iOS y Android para cada patrón.
Esto le permite al equipo mantener un sistema de diseño mayormente consistente en todas las plataformas, pero
también documentar las divergencias de patrones cuando ocurren.
Hazlo independiente del contexto
La forma en que se nombran sus patrones de interfaz de usuario indudablemente dará
forma a cómo se utilizan. Cuanto más agnósticos son los nombres de patrones, más
versátiles y reutilizables se vuelven.
Debido a que tendemos a establecer patrones de interfaz de usuario en el contexto de una
página más amplia, puede ser tentador nombrar los componentes según el lugar donde se
encuentren. Pero en lugar de llamar a su componente "carrusel de la página de
inicio" (disculpe mi obsesión morbosa con los carruseles), simplemente puede llamarlo
"carrusel", lo que significa que ahora puede poner carruseles en todas partes.
(Pero por el amor de todo lo que es santo, por favor no lo hagas).
Otro desafío para nombrar patrones de visualización es que tendemos a distraernos
con los patrones de contenido que viven dentro de ellos. Por ejemplo, si trabaja en un
sitio de comercio electrónico, puede tener la tentación de llamar a un bloque que contiene
una imagen de producto y titular una "tarjeta de producto".
Pero nombrar las cosas de esta manera limita inmediatamente qué tipo de contenido
puede vivir dentro de él. Al nombrar el patrón simplemente "tarjeta", puede colocar
todo tipo de patrones de contenido dentro de él: productos, promociones, ubicaciones
de tiendas, etc.
Advertencia justa: nombrar cosas es realmente difícil. Pero existen estrategias
para ayudarlo a crear nombres sólidos para sus patrones.
Llevar a cabo un inventario de la interfaz (como se detalla en el capítulo 4) ayuda
a eliminar los patrones del contexto de la página donde residen normalmente, lo
que significa que su equipo puede crear nombres que no se distraigan con su
contexto. Realicé ejercicios de asignación de nombres con equipos en los que
desdibujamos el contenido que reside dentro de un patrón para que todos puedan
concentrarse en la estructura del patrón en lugar del contenido que vive dentro de él.
Un buen ejercicio al nombrar patrones es difuminar el contenido para que sus nombres reflejen las estructuras de
los patrones en lugar del contenido que vive dentro de ellos.
Si bien nombrar cosas siempre será un desafío, los nombres de patrones que son
independientes del contexto y el contenido serán más portátiles, reutilizables y
versátiles.
Hazlo contextual
Mostrar patrones de interfaz de usuario en una biblioteca de patrones está muy
bien, pero debe demostrar el contexto para que los usuarios del sistema de diseño
comprendan cómo y dónde usarlos correctamente. La mayoría de los patrones
Las bibliotecas muestran una demostración de cada patrón de interfaz de usuario, pero como hemos
discutido, esos patrones no viven en el vacío. ¿Dónde exactamente se utilizan estos patrones?
Una forma de demostrar el contexto podría incluir mostrar capturas de pantalla o videos
de un componente en acción. La documentación de Material Design hace un trabajo fantástico en esto;
cada componente es rico en fotos, videos y detalles de uso para brindar a los usuarios una comprensión
clara de cómo se ven estos patrones en el contexto de una aplicación y demostrar cómo se debe usar
cada patrón.
La biblioteca de componentes de Material Design no solo contiene un ejemplo de cada componente;
documenta minuciosamente el uso del componente con muchas imágenes y videos para respaldarlo.
Otra forma de mostrar el contexto es proporcionar información de linaje para cada patrón. Como discutimos
en el Capítulo 3, una herramienta como Pattern Lab genera automáticamente esta información, lo que le
permite ver qué patrones conforman un componente determinado, además de mostrar dónde se emplea
cada componente. Esto proporciona una especie de rastro de papel de patrón que ayuda inmensamente
con los esfuerzos de control de calidad, ya que resalta exactamente qué patrones y plantillas deberían
probarse si se hicieran cambios en un patrón en particular.
Herramientas como Pattern Lab brindan información de linaje, lo que permite a los equipos ver qué componentes más
pequeños se incluyen en un componente determinado, así como también dónde se usa cada patrón.
Haz que dure
Hacer un sistema de diseño es un esfuerzo increíble e importante.
Pero sin el mantenimiento adecuado, el valor de su sistema de diseño se
depreciará como un automóvil que acaba de salir del concesionario. En cambio,
su sistema de diseño debe ser como una botella de buen vino cuyo valor
aumenta con el tiempo.
Con el mantenimiento adecuado, el valor de su sistema de diseño debería aumentar con el tiempo como una botella
de buen vino, en lugar de un automóvil usado que acaba de salir del lote. Crédito de la imagen: Sabin Paul Croce
en Flickr y Ray Larabie en Flickr
Como hemos discutido a lo largo de este capítulo, hacer que su sistema
de diseño resista la prueba del tiempo requiere una cantidad significativa de
tiempo y esfuerzo. Pero, ¿no es así con todos los seres vivos? Los animales
necesitan comer y las plantas necesitan agua y luz solar para sobrevivir.
Crear un sistema de diseño vivo significa prestarle atención y cuidado para
que siga prosperando.
Todo ese esfuerzo no solo crea un mejor presente para su
organización, sino que lo prepara para el éxito a largo plazo. Establecer un
plan de gobierno claro, comunicar el cambio e implementar los demás
consejos que se encuentran en este capítulo ayuda a que el sistema de
diseño arraigue y se convierta en una parte integral del flujo de trabajo de su organización.
Crear la maldita cosa en primer lugar es la parte difícil, pero una vez
establecida, tienes una base sólida sobre la cual construir en los años
venideros. Incluso si tuviera que quemar todo y reconstruir un nuevo sistema
desde cero, encontrará que sus interfaces de usuario aún necesitarán
botones, campos de formulario, pestañas y otros componentes existentes.
Y necesitará un hogar feliz para mostrar y documentar el sistema.
¡No tires al bebé con el agua del baño!
Así que ahí lo tienes. Para hacer un sistema de diseño mantenible, debe:
Hazlo oficial asignando tiempo real, dinero y recursos a tu sistema de diseño.
Hacerlo adaptable apostando por el cambio y estableciendo un plan de
gobierno claro.
Haga que sea mantenible buscando el santo grial y facilitando la
implementación y la comunicación de cambios en el sistema de diseño.
Hágalo interdisciplinario haciendo de su biblioteca de patrones un
abrevadero en el que toda la organización pueda reunirse. Hágalo
accesible creando una guía de estilo atractiva y fácil de usar con
documentación útil que la acompañe. Hacerlo visible comunicando el
cambio, evangelizando el sistema de diseño y haciéndolo público.
Hazlo más grande incluyendo marca, voz y tono, código, diseño
principios y pautas de escritura.
Hágalo agnóstico nombrando patrones según su estructura en lugar
de su contexto o contenido.
Hágalo contextual al demostrar qué patrones forman un patrón en particular
y mostrar dónde se usa cada patrón.
Haga que dure sentando una base sólida sobre la cual construir en los años
venideros.
Ir adelante y ser atómico
Tenemos la tarea de hacer que una gran cantidad de productos, sitios y
aplicaciones funcionen y se vean bien en una vertiginosa variedad de dispositivos,
tamaños de pantalla, factores de forma y entornos diferentes. Espero que los
conceptos tratados en este libro le proporcionen una base sólida sobre la que
apoyarse mientras aborda con valentía este panorama digital cada vez más diverso.
Al crear sistemas de diseño, siendo deliberado en la forma en que construye
las interfaces de usuario, estableciendo un flujo de trabajo colaborativo y basado
en patrones, y configurando procesos para mantener con éxito su sistema de
diseño, espero que usted y su equipo puedan crear grandes cosas juntos.
¡Avanza y sé atómico!
Gracias y reconocimientos
Este libro está dedicado a mi increíble esposa Melissa, quien apoya todas
mis locas ideas y de alguna manera aguanta toda mi mierda.
Gracias. Te amo.
Me gustaría agradecer enormemente a Dave Olsen, quien tomó mi
incipiente y mal programado Pattern Lab. concepto y lo transformó en una
pieza de software legítima y sorprendente. Gracias al trabajo incansable de
Dave y Brian Muenzenmeyer, Pattern Lab está ayudando a equipos de
todo el mundo a crear sistemas de diseño atómico. Siempre estaré
agradecido por todo su excelente trabajo y me considero afortunado de
llamarlos amigos.
A Josh Clark y Dan Mall por ayudar a solidificar el diseño atómico como
metodología y por escribir el prólogo de este libro. Confiaste en mí lo
suficiente como para ejecutar este enfoque y de alguna manera convenciste
a nuestros clientes de que no era una locura total. Sin su aporte y los
cerebros locos e inteligentes de los primeros colaboradores como Jennifer
Brook, Jonathan Stark, Robert Gorrell, Kelly Shaver y Melissa Frost, este
libro no habría existido.
Gracias a Owen Gregory por corregir el manuscrito del libro y asumir la
hercúlea tarea de hacer que suene razonablemente coherente. Gracias a
Rachel Andrew por lidiar con todos los aspectos técnicos relacionados con
la creación de libros electrónicos. Y muchas gracias a Rachel Arnold Sager
por todo su trabajo al diseñar la versión impresa del libro y prepararla para
la imprenta.
A Anna Debenham por todas sus increíbles ideas sobre las guías de estilo
de frontend, su libro sobre el tema, y su voluntad de ser coanfitrión de un
podcast sobre guías de estilo conmigo. Estoy orgulloso del trabajo que
hemos hecho en Styleguides.io y estoy tan feliz de que hayamos trabajado
juntos.
A Jonathan Snook por su fantástica metodología SMACSS y por
tomarse el tiempo para guiarme a través del proceso de autopublicación
de un libro. Gracias por hacer que un esfuerzo tan aterrador sea mucho
más accesible.
A Stephen Hay, quien fue la primera persona a la que escuché articular la
necesidad de romper las interfaces en pedazos más pequeños. Gracias por
ser una fuente continua de sabiduría y sarcasmo.
A Andy Clarke, que hablaba de sistemas de diseño y átomos. antes de que fuera
lo más moderno. Gracias por escribir y pensar, pero todavía no consigues a mi
perro.
A Dave "Tiny Bootstraps" Rupert, Susan Robertson, Samantha Warren, Jina
Bolton, Nathan Curtis, Paul Robert Lloyd, Harry Roberts, Nicole Sullivan, Brett
Jankord, Tyler Sticka, Lincoln Mongillo, Nicholas Gallagher y muchos otros que
han avanzado en los conceptos. de sistemas de diseño, bibliotecas de patrones
y guías de estilo. Gracias por ayudarme a mí y a muchos otros a pensar de
manera más modular.
A Jefrey Zeldman, Eric Meyer, Marc Thiele, Vitaly Friedman y todos los demás
organizadores de la conferencia que me dieron la oportunidad de subir al escenario
para divagar sobre los conceptos contenidos en este libro.
Este libro no habría sido posible si no fuera por el increíble trabajo
realizado por algunas personas increíbles en la comunidad web.
Soy tan increíblemente afortunada de trabajar en una comunidad tan abierta,
compartida y colaborativa; todos los días espero aprender cosas nuevas de todos
ustedes.
Y por último, pero ciertamente no menos importante, muchas gracias a mi familia por
todo su amor y su increíble apoyo a lo largo de los años.
AGRADECIMIENTOS Y AGRADECIMIENTOS 183
Recursos
Capítulo 1
• Componentes de ámbito, no páginas
http://bradfrost.com/blog/post/scopecomponentsnotpages/
• Principios de diseño del W3C Diseño modular
http://www.w3.org/DesignIssues/Principles.html#Modular
• Biblioteca YUI
http://yuilibrary.com/
• jQueryU
http://jqueryui.com/
• Manifiesto Amigo del Futuro
http://futurefriendlyweb.com/
• Montar la escalera mecánica mágica del conocimiento
adquirido http://www.uie.com/articles/magic_escalator/
• El Manifiesto Ágil
http://www.manifiestoágil.org/
• Desarrollo de software Scrum
http://en.wikipedia.org/wiki/Scrum_%28software_desarrollo%29
• Desarrollo de software esbelto
http://en.wikipedia.org/wiki/Lean_software_development
• Principios detrás del Manifiesto Ágil
http://www.manifiestoágil.org/principios.html
• Proceso de
bricolaje http://cognition.happycog.com/article/diyprocess
• Por una Web Amigable para el Futuro
http://bradfrost.com/blog/web/paraunawebamigableparaelfuturo/
• Adaptarnos al contenido adaptativo http://
karenmcgrane.com/2012/09/04/adaptingourselvesto adaptivecontent
videoslidesandtranscriptohmy/
• COPE: Crear una vez, publicar en todas
partes http://www.programmableweb.com/news/copecreateonce
publisheverywhere/2009/10/13
• Aprendizaje de patrones de diseño de
JavaScript http://addyosmani.com/resources/essentialjsdesignpatterns/
libro/
• OOCSS
http://oocss.org/
• SMACSS
https://smacss.com/
• MindBEMding: familiarizarse con la sintaxis BEM
http://csswizardry.com/2013/01/mindbemdinggettingyourheadround
bemsyntax
• Un extracto de Designing Atoms and Elements
http://stufandnonsense.co.uk/blog/about/anextractfrom designing
atomsandelements
• Azulejos de
estilo http://styletil.es/
• Collages de elementos
http://danielmall.com/articles/rifelementcollages/
• BDConf: Stephen Hay presenta un flujo de trabajo de diseño receptivo
http://bradfrost.com/blog/mobile/bdconfstephenhay presentaresponsive
designworkfow/
• Diseño Web Responsivo
http://alistapart.com/article/responsivewebdesign
• Esto es receptivo http://
bradfrost.github.io/thisisresponsive/index.html
• Fundación por ZURB
http://fundacion.zurb.com/
• Arranque
http://getbootstrap.com/
• Github
https://github.com/
• Entregables receptivos
http://daverupert.com/2013/04/responsivedeliverables/
RECURSOS 185
• Guías de estilo
http://bradfrost.com/blog/post/styleguides/ • Diseño
de materiales
http://www.google.com/design/spec/materialdesign/
introduction.html
• Voz y tono: creación de contenido para humanos
http://www.slideshare.net/katekiefer/kklcsforum
• Voz y tono http://
vozytono.com/
• Escribir para la Web
http://www.dal.ca/webteam/web_style_guide/writing_for_the_ web.html
• Guías de estilo de frontend
http://maban.co.uk/projects/frontendstyleguides/
• Podcast Guías de estilo con Federico Holgado
http://styleguides.io/podcast/federicoholgado/
• Dennis Crowley: “La parte difícil es construir la máquina que construye el
producto” http://techcrunch.com/2011/03/03/founderstoriesfoursquare
crowleymachine/
• Ejemplos de guías de estilo en Styleguides.io
http://guiasdeestilo.io/ejemplos.html
Capitulo 2
• Diseño Sistémico
http://us5.campaignarchive1. com/?
u=7e093c5cf4&id=ead8a72012&e=ecb25a3f93
• Tabla periódica de elementos HTML de Josh Duck
http://smm.zoomquiet.io/data/20110511083224/index.html
• Referencia de elemento HTML
https://developer.mozilla.org/enUS/docs/Web/HTML/Element
• Principio de responsabilidad única
https://en.wikipedia.org/wiki/Single_responsibility_principle
• Estructura Primero. Contenido
Siempre. http://www.markboulton.co.uk/journal/structurefrstcontent siempre
• La forma del diseño http://
read.shapeofdesignbook.com/chapter01.html
• Sistema de diseño Predix de GE
https://medium.com/gedesign/gespredixdesign
system8236d47b0891#.uo68yjo9g
Capítulo 3
• Laboratorio de patrones
http://patternlab.io
• Dave Olsen
http://dmolsen.com
• Brian Muenzenmeyer http://
www.brianmuenzenmeyer.com/
• Documentación de Pattern Lab http://
patternlab.io/docs/
• No te repitas
https://en.wikipedia.org/wiki/Don't_repeat_yourself
• Bigote https://
mustache.github.io/
• Los pseudopatrones de Pattern Lab
http://patternlab.io/docs/patternpseudopatterns.html
• Diseño Web Responsivo
http://alistapart.com/article/responsivewebdesign
• Consultas de contenedores: una vez más hasta la brecha
http://alistapart.com/article/containerqueriesoncemore hasta la brecha
• Trabajo
http://bradfrost.com/demo/ish/
• Ejemplos de recursos de la guía de estilo del
sitio web http://guiasdeestilo.io/ejemplos.html
• Guías de estilo Rizzo
http://rizzo.lonelyplanet.com/
• Herramientas de recursos de la guía de estilo del
sitio web http://guiasdeestilo.io/herramientas.html
RECURSOS 187
Capítulo 4
• Inventario de contenido
https://en.wikipedia.org/wiki/Content_inventory
• Plantilla de inventario de la interfaz de Presentaciones de Google
https://docs.google.com/presentation/d/1GqFmiDV_
NqKi36fXAwD3WTJL5JVgHL7XVD2fVeL0M/edit?usp=sharing
• El objeto multimedia ahorra cientos de líneas de código
http://www.stubbornella.org/content/2010/06/25/themedia objectsaves
hundredsoflinesofcode/
• Elementos invisibles de superficie
http://bradfrost.com/blog/post/surfacinginvisibleelements/
• Estadísticas
CSS http://cssstats.com/
• Estilízame
http://stylifyme.com/ •
Diseño UX multipantalla http://
store.elsevier.com/MultiscreenUXDesign/Wolfram Nagel/
isbn9780128027295/
• La era posterior a la
PSD http://danielmall.com/articles/thepostpsdera/
• Alucinación consentida https://
adactio.com/journal/4443
• Modelo de cascada
https://en.wikipedia.org/wiki/Cascada_modelo
• El desarrollo es diseño
http://bradfrost.com/blog/post/desarrolloesdiseño
• Es hora de dejar de mostrar a los clientes imágenes de diseño estático
https://stufandnonsense.co.uk/blog/about/
time_to_stop_showing_clients_static_design_visuals
• Móvil primero
http://www.lukew.com/f/entry.asp?933 • Contenido
y patrones de visualización
http://danielmall.com/articles/contentdisplaypatterns/
• Jennifer arroyo
http://jenniferbrook.co/about
• La prueba de "intuición" de 20 segundos
http://goodkickofmeetings.com/2010/04/the20secondgut test/
• Azulejos de
estilo http://styletil.es/
• Prototipo de estilo
http://sparkbox.github.io/estiloprototipo/
• Collages de elementos
http://danielmall.com/articles/rifelementcollages/
• Montones de
Ideas http://jasonsantamaria.com/articles/montonesdeideas
• CodePen
http://codepen.io/
• Dan Mall sobre el proyecto de la caja de
pastelería https://thepastryboxproject.net/danmall/2012september12
Capítulo 5
• Nathan Curtis en Twitter
https://twitter.com/nathanacurtis/status/656829204235972608 • Un Sistema de
Diseño no es un Proyecto. Es un Producto, Sirviendo Productos. https://medium.com/
eightshapesllc/adesignsystem istaprojectitsaproductservingproducts
74dcfef935#.4umtnfxsx
• El modelo de equipo de Salesforce para escalar un sistema de diseño
https://medium.com/salesforceux/thesalesforceteammodel forscalingadesign
systemd89c2a2d404b
• Estructura de vainilla
http://ubuntudesign.github.io/vanillaframework/
• Preparando a Vanilla para v1: la hoja de ruta http://
design.canonical.com/2016/07/gettingvanillareadyfor v1theroadmap/
• Desaprobar Sass
https://github.com/salesforceux/sassdeprecate
• La forma en que construimos
http://airbnb.design/lamaneraenqueconstruimos/
RECURSOS 189
• Guía de estilo Rizzo
http://rizzo.lonelyplanet.com/ •
Persiguiendo el Santo Grial https://
medium.com/@marcelosomers/persiguiendoelsantogrial
bbc0b7cce365#.ay1xeej7d
• Drupal
https://www.drupal.org
• ramita
http://twig.sensiolabs.org •
Presentación de Pattern Lab Starter 8
https://www.phase2technology.com/blog/introducingpattern labstarter8/
• Borrador de estándares digitales web de
EE. UU. https://normas.usa.gov/
• Gestión de guías de estilo en Shyp
https://medium.com/shypdesign/managingstyleguidesat shypc217116c8126
• Guías de estilo con Jina Bolton http://
styleguides.io/podcast/jinabolton
• Podcasts de recursos de la guía de estilo del
sitio web http://guiasdeestilo.io/podcast
190 DISEÑO ATÓMICO 190 DISEÑO ATÓMICO
Sobre el Autor
brad escarcha es un diseñador web,
orador, consultor y músico ubicado en
la hermosa Pittsburgh, PA. Le apasiona
crear experiencias web que se vean y
funcionen maravillosamente en un flujo
interminable de dispositivos conectados, y
le encanta ayudar a otros a hacer lo mismo.
Ha ayudado a crear varias herramientas y recursos para
diseñadores web, incluido Pattern Lab. (con Dave Olsen y Brian
Muenzenmeyer), Styleguides.io (con Anna Debenham), This Is
Responsive, Web móvil WTF (con Jen Simmons) y Mejores prácticas de Web móvil.
SOBRE EL AUTOR 191
Tenemos la tarea de crear interfaces para más usuarios en más
contextos usando más navegadores en más dispositivos con más tamaños
de pantalla y más capacidades que nunca. Eso es una tarea desalentadora
de hecho. Afortunadamente, los sistemas de diseño están aquí para ayudar.
Atomic Design detalla todo lo que implica crear y mantener sistemas de
diseño robustos, lo que le permite implementar interfaces de usuario más
consistentes y de mayor calidad más rápido que nunca. Este libro
presenta una metodología para pensar en nuestras interfaces de usuario
como jerarquías reflexivas, analiza las cualidades de las bibliotecas de
patrones eficaces y muestra técnicas para transformar el flujo de trabajo de
diseño y desarrollo de su equipo.
Para ir audazmente más allá de las "páginas". Ese es el universo del diseño
moderno, y no hay mejor guía para explorarlo que Brad Frost. En Atomic Design,
reemplaza nuestros flujos de trabajo obsoletos y cerrados con nuevos y emocionantes
flujos de trabajo colaborativos, y nos enseña a diseñar no solo páginas sino también sistemas.
Recomendado para todos los diseñadores web y de interacción.
Jefrey Zeldman, autor, Diseño con estándares web
Brad está sugiriendo que seríamos mejores diseñadores web si pensáramos en lo
que estamos construyendo como un sistema. Un sistema jerárquico que encaja para
formar partes más grandes. Porque, alerta de spoiler, lo es y lo seríamos.
Chris Coyier, trucos CSS

Atomic Design

Cargado por

Copyright:

Formatos disponibles

Atomic Design

Cargado por

Información del documento

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Atomic Design

Cargado por

Copyright:

Formatos disponibles

Machine Translated by Google

También podría gustarte