/Front-End-Design-Checklist

💎 The Design Checklist para Diseñadores Web creativos y Desarrolladores Front-end pacientes

Creative Commons Zero v1.0 UniversalCC0-1.0

Front-End Design Checklist

Front-End Design Checklist

The Design Checklist para Desarrolladores Front-end es una lista exhaustiva de elementos que pueden ayudar al desarrollador a analizar y entender diseños para web para asegurar la calidad del desarrollo Front-end .

PRs Welcome Join the chat at https://gitter.im/Front-End-Checklist/Front-End-Design-Checklist CC0

Tabla de contenidos


The Design Checklist para Desarrolladores Front-end es una lista exhaustiva de elementos que los Diseñadores Web y Desarrolladores Fron-end necesitan tomar en consideración para facilitar su colaboración. Los siguientes elementos son una mezcla entre mejores prácticas y elementos basados en amplia experiencia analizando diseños para web.

En caso de buscar una lista de todos los emementos que debes tener/probar antes de lanzar un sitio/página HTML a producción, dale un vistazo a → Front-End Checklist.

ÂżCĂłmo usar The Desing Checklist?

Cuando llega el momento que se les presenta a desarrolladores nuevos diseños para web, antes de convertirlos a código, se deben considerar elementos que podrían pasar desapercibidos. The Front-end Design Checklist es una herramienta para desarrolladores Front-end y Diseñadores Web que tiene el objetivo de ayudarlos a trabajar sin problemas.

Puedes compartir esta lista con Diseñadores Web para asegurar ahorrar tiempo en las entregas o puedes utilizarla para revisar todos los elementos proporcionados por el equipo creativo y asegurar que todo está correcto antes de comenzar con la integración de código.

¿Por qué necesitas usar esto?

  • Asegurar que todos los puntos son tomados en consideraciĂłn por el equipo creativo.
  • Tener un documento que los Diseñadores y Desarrolladores puedan consultar para asegurar una mejor comunicaciĂłn y coherencia en la manera en que interactuan.
  • Porque es fácil olvidar elementos importantes cuando eres presionado por tiempos de entrega cortos
  • Evitar descubrir problemas cuando el equipo creativo ya está trabajando en otro proyecto.
  • Para mostrar el trabajo complementario entre Diseñadores y Desarrolladores

1. - Requerimentos de diseño

Diseñar un sitio web o aplicación web requiere seguir algunas reglas y tomar en consideración que el proyecto no es solo un proyecto gráfico, sino también un proyecto web. La siguiente sección es crucial para cualquier proyecto web.

1.1 - Sistema de retĂ­culas

Sistema de retĂ­cula

  • Una retĂ­cula es explĂ­citamente proporcionada en el diseño y los detalles de ella están presentes en las especificaciones tĂ©cnicas (ancho, medianiles, nĂşmeros de columnas...). El Diseñador Web puede mantener una retĂ­cula en una capa transparente y utilizarla en todos el proyecto.

    ℹ️ Guide Guide es un plugin para Photoshop que puede ayudar a construir facilmente tu retícula.

    ℹ️ En Sketch, puedes usar la herramienta integrada “Make Grid” para diseñar tu retícula.

  • Familiarizate con el sistema de retĂ­cula que usarás en tu proyecto. La mayorĂ­a de las ocasiones, algunas opciones (como alineaciĂłn, offsett, anidamiento...) son ignoradas por el desarrollador y tienden a remplazarlas innecesariamente por márgenes o relleno manual.

  • Antes de trabajar en cada componente de tu sitio web, puedes construir cada plantilla usada en los diseños solo con las clases de la retĂ­cula. Construir la estructura antes que nada, te facilitará tu trabajo posterior.

<div class="container">
  <div class="row">
    <div class="col-sm">
      <!-- DĂ©jalo vacĂ­o al inicio -->
    </div>
    <div class="col-sm">
      <!-- DĂ©jalo vacĂ­o al inicio -->
    </div>
    <div class="col-sm">
      <!-- DĂ©jalo vacĂ­o al inicio -->
    </div>
  </div>
</div>

⚠️ Si quieres asegurarte que la retícula y el ancho de los dispositivos sean respetados, podrías generar una plantilla PSD que le envies al Diseñador Web

Recursos adicionales: (recursos en inglés)

⬆ volver a arriba

1.2 - Colores

Colores

  • A todos los colores usados en los diseños se les asigna un nombre ($gris-claro, $gris-oscuro, $verde), este puede ser de acuerdo a su uso ( $fondo-de-página, $texto, $tĂ­tulos...) Pueden ser exportados en un archivo ACO (si usas Photoshop o un sĂ­mbolo de página para Sketch) y compartirlo con los desarrolladores.

Muestras de color

  • Los diferentes colores de estado de algunos elementos (como botones, enlaces, campos de texto) son definidos y trabajados en el contexto de un fondo claro y oscuro con texto claro y oscuro.

  • Los colores más usados o los más importantes son accesibles(contraste entre colores adecuado) en el diseño para permitir una navegaciĂłn fluida en el sitio web/aplicaciĂłn web.

Recursos adicionales: (recursos en inglés)

⬆ volver a arriba

1.3 - Fuentes y textos

Fuentes

Las fuentes son una parte esencial de cada diseño, no deben ser elegidas sin un buen juicio. Elegir la fuente incorrecta para un proyecto puede tener consecuencias de impacto financiero y legal.

Es recomendable solicitar a tu cliente comprar estas fuentes para evitar posibles problemas a futuro y tomar en consideración las condiciones de uso. Algunas fuentes para web están limitadas en terminos de vistas por página y no pueden ser almacenadas en tu hosting. (Understanding Webfont Licensing Structures).

  • Las fuentes para escritorio (TTF o OTF) y las fuentes web, en formato WOFF, WOFF2 y TTF fueron proporcionadas (en un archivo Zip o se dio acceso al sitio web donde fueron compradas)

    ℹ️ El formato TTF para escritorio no es el mismo que el TTF para web.

    Recursos: (recursos en inglés)

  • Una fuente de respaldo fue especificada en el documento (idealmente en la GuĂ­a de estilos) para el Desarrollador Front-end.

    Recursos: (recursos en inglés)

  • El tamaño total de las fuentes no debe exceder de 1 a 2 Mb (incluyendo todas las variantes: italica, negrita, etc.)

  • Tanto como sea posible, todos los textos son proporcionados en el lenguaje adecuado en vez de textos de ejemplo (Lorem Ipsum y similares).

    ℹ️ En el caso de sitios web multilenguaje, siempre preguntate a ti mismo cómo reaccionaría el diseño si los textos fueran más largos de lo que fueron definidos anteriormente. Recuerda que los Diseñadores Web acostumbran crear diseños perfectos y no siempre piensan sobre los posibles problemas o situaciones con demasiado texto.

Recursos adicionales:

⬆ volver a arriba

1.4 - Enlaces y navegaciĂłn

Enlaces y navegaciĂłn

  • Todos los enlaces tienen los estados default, hover, focus, active y visited claramente definidos (la GuĂ­a de Estilos es el mejor documento para especificar estos)
  • Vistas alternadas de todos los estados de navegaciĂłn (hover, active, página actual).

1.5 - Imágenes / Iconos

Imágenes

  • Una imagen favicon de almenos 512px X 512px es proporcionada en formato PNG. La generaciĂłn de los demás Favicons pueden ser hechas fácilmente con herramientas en lĂ­nea.

    Recursos:

  • Todos los Ă­conos son proporcionados en formato SVG, cada uno con las mismas dimensiones, en negro y por carpetas separadas.

    Recursos:

  • El nombre de cada icono comienca con icono- y solo en minĂşsculas (sin ningĂşn espacio y usando - para separar cada palabra).

Recursos adicionales:

⬆ volver a arriba

1.6 - Formularios y botones

Formularios

  • Todos los furmularios poseen un tĂ­tulo que puede ser usado como leyenda
  • Un ejemplo de los diferentes estados de todos los campos de entrada fueron proporcionados (al menos los estados focus e inactivo/deshabilitado).
  • Todos los mensajes de error fueron proporcionados , el texto (en un documento separado), la posiciĂłn y colores son claramente identificados en los diseños y son consistentes. Algunos mensajes deben ser diferentes de acuerdo al error correspondiente. Recursos:
  • Indicadores para campos requeridos/opcionales son proporcionados.
  • Los botones primarios y secundarios son claramente identificables y son usados siguiendo prácticas comunes. Recursos:
  • Un ejemplo de los diferentes estados de un botĂłn fueron proporcionados (estados default, hover, focused, pressed e inactive)
  • Botones con indicadores de carga incorporados son proporcionados y pueden aplicarse a cualquier botĂłn.

Recursos adicionales:

⬆ volver a arriba

1.7 - Diseño Web Responsivo

Responsive

  • La versiĂłn mĂłvil del diseño fue proporcionado antes o al mismo tiempo que la versiĂłn para escritorio.

    Si el método móvil primero no fue aplicado por el equipo creativo, algunas irregularidades e inconsistencias pueden aparecer entre la versión móvil y la versión de escritorio. Verifica y marca estos problemas antes de iniciar el desarrollo del proyecto.

  • En ciertos casos, la versiĂłn para tabletas del diseño es proporcionada.

⚠️ El concepto pixel perfecto hoy en día está obsoleto. Es imposible tener un diseño que funcione de la misma forma frente a la multitud de tamaños de pantalla existentes.

Recursos adicionales:

⬆ volver a arriba

1.8 - GuĂ­a de estilos y enfoque de componentes

Styleguide

  • Todos los componentes en cada página fueron creados con el enfoque basado en componentes (Diseño AtĂłmico). Si no es asi, pueden ocurrir problemas en terminos de rendimiendo, mantenimiento del proyecto, etc.

    Rescursos:

  • Una GuĂ­a de estilo necesita ser proporcionada listando todos los elementos, componentes, estilos y dimensiones. Algunos boilerplates como UX Power Tools pueden ayudar a ahorrar tiempo y mantener consistencia en los diseños.

⚠️ En el caso de no contar con una Guía de estilo, es recomendable construir una Guía de Estilos para facilitar tu trabajo. Algunos CMS como Drupal, tienen plugins que permiten desarrollar Guías de Estilo usando Pattern Lab.

Recursos adicionales:

En el caso de un proyecto existente:

A veces, el equipo creativo necesita añadir páginas nuevas o módulos en un proyecto existente. Ellos deben tener o crear una lista de todos los elementos existentes e intentar usar lo que ya está ahí. Tener una Guia de Estilos ya creada puede salvar horas de trabajo y asegurar la consistencia del proyecto.

⬆ Volver a arriba

1.9 - Entrega de archivos

Entrega de archivos

  • Para todos los sitios web, el diseñador web necesita proporcionar al menos 2 PSD (mĂłvil, escritorio y eventualmente tableta) o al menos 1 archivo Sketch que debe ser entregado con las medidas debajo (si usas Photoshop CC 2015 o superior, recomiendo usar artboards)

    ℹ️ Algunos diseñadores web podrían crear multiples PSD correspondientes a cada componenete usado y los importan en un solo PSD como "capas inteligentes". En ese caso, tendrás multiples PSD enlazados a uno o más archivos. En el caso de Sketch, desde que las librerias existen desde la versión 47, es posible enlazar multiples archivos con símbolos.

  • Los archivos de diseño son limpiados antes de entregar a los desarrolladores (se removieron capas innecesarias para evitar archivos grandes)

  • La página de error 404 (y eventualmente la página de error 500) fue diseñada.

  • Todos los popins, popups y cajas de alerta fueron diseñados y pueden ser habilitados a treves de capas en la composiciĂłn.

Recursos adicionales:

Reglas especĂ­ficas para archivos PSD:

  • Composiciones en capas son usadas para mostrar cada página si se proporcionan multiples vistas dentro del mismo PSD. Es una manera fácil de evitar confusiones y verificar que todos los elementos están organizados correctamente.

⬆ volver a arriba

2. - Fases de análisis y previo al desarrollo

Analysis and phases

Antes de iniciar las fases de análisis y previo al trabajo y después de recibir los archivos de diseño, necesitas verificar algunos elementos importantes:

  • ÂżCuál versiĂłn de Photoshop, Sketch es usada? Algunas funciones son especĂ­ficas de algunas versiones de Photoshop o Sketch. Es importante marcar cualquier problema que corresponda a esto tan pronto como sea posible.
  • ÂżEl ancho de cada PSD o artboard son correctos? En caso de que se añada espacios en cada lado del diseño, verifica el tamaño exacto del sitio web.
  • ÂżLos diseños usan demasiado "box-shadow", "linear o radial gradient"? No olvides que ciertas propiedades pueden tener impacto en el rendimiento del navegador.
  • ÂżExiste un mapa del sitio/breadcrumb para entender la arquitectura de todas las páginas y sus dependencias?
  • ÂżEl sitio web necesita tener imágenes retina?

⬆ volver a arriba

2.1 - Análisis en papel

Análisis en papel

Se recomienda imprimir algunas (o todas) las páginas que tengas en formato A3 (o A4 si no posees ese formato). Debido al alto de la página, probablemente necesites imprimir algunos diseños en multiples páginas.

No puedo imaginar una mejor forma de iniciar que analizando los diseños en papel con un lapiz (o diferentes lapices de colores seleccionados para resaltar diferentes tipos de información).

  1. Define la estructura de las páginas, encabezados, secciones, artículos, área principal, pie de página, destacando estos al menos en una página impresa.

  2. Encuentra todos los encabezados en la estructura de página, asegurate que la etiqueta H1no se encuentre en el logo y que el orden lógico sea seguido. La mayoría de la veces, el H1 en la página de inicio será ocultado con CSS pero necesita mantener su significado legítimo. El análisis debe ser realizado con la ayuda de un especialista en SEO en caso de contar con uno en el equipo.

  3. Intenta encontrar y reagrupar componentes similares asignandoles un nombre individual de acuerdo a su funcionalidad y no solo por su contexto.

  4. La mayoría de los elementos de diseño pueden realizarse usando CSS. Hoy en día, es recomendado no usar ningun elemento de la estructura con imágenes. Cualquier elemento gráfico simple, como botones o bordes pueden hacerse con CSS para evitar problemas de rendimiento o escalabilidad.

  5. Encuentra posibles faltas de coherencia en caso de no recibir una Guia de Estilo del equipo creativo, es tu responsabilidad asegurar que cada elemento gráfico pertenezca a una categoría (botones, tipografía, sliders,etc.). Te ayudará a crear tu propia arquitectura CSS/Sass o identificar cuáles componentes necesitarás de determinado Framework CSS.

⚠️ Despues de la fase de análisis en papel, invita al equipo creativo a usar una herramienta como InVision para facilitar la comunicación e intercambio entre el equipo creativo y los desarrolladores. La posibilidad de comentar en cada página puede ahorrar tiempo y permitir mantener un historial de modificaciones y decisiones.

2.2 - Fase antes del desarrollo

  • De acuerdo a las especificaciones, los plugins necesarios fueron definidos en una etapa temprana. Tener una lista previa de los plugins necesarios antes de comenzar el desarrollo puede ayudar al desarrollador a mantenerse enfocado y no ocupar mucho tiempo en investigar durante la fase de desarrollo. Obviamente, algunos plugins no serán adecuados y podrán cambiar.

Recursos adicionales:

⬆ volver a arriba

3. - ValidaciĂłn

La fase de validación es cuando todo parece estar listo para ser integrado. El cliente, por lo general, valida los diseños sin esperar ninguna aprovación por parte del equipo técnico. Como se expone en la Design Checklist, es esencial que los desarrolladores se aseguren de la calidad de lo entregado antes de comenzar el desarrollo.

4. - Fase de desarrollo

  • Todos los medios pueden ser separados y almacenados antes de comenzar la fase de desarrollo. Eso puede ayudar a evitar cambiar constantemente entre tus aplicaciones de diseño y tu editor de cĂłdigo.

  • La carpeta de imágenes tiene una arquitectura clara donde organices la estructura de las imágenes. Es importante permanecer consistente entre los proyectos. Definir la estructura para estas carpetas y tener una nomenclatura definida puede ser de ayuda.

    Este es un ejemplo de una posible estructura con prefijos usados para reconocer la utilidad de cada imagen.

.
└── imágenes
    ├── fondos
    ├── banners
    ├── iconos
    └── diseño
  • Se usa una nomenclatura, como añadir prefijos para diferenciar los tipos de imagen, todas las imágenes usadas para fondos pueden tener el prefijo fondo-, iconos el prefijo icono-, banners el prefijo banner- y asĂ­ sucesivamente.

5. - Antes de producciĂłn

Antes de publicar tu sitio web, asegurate de revisar todas tus páginas usando la Front-End Checklist-ES

⬆ volver a arriba


Translations

La Front-End Design Checklist estará disponible pronto en otros idiomas. No dudes en ayudar haciendo fork a este repositorio y comenzando con la traducción en tu idioma.

Support

Si tienes alguna sugerencia o pregunta, no dudes en usar Gitter o Twitter:

Autor

David Dias

Colaboradores

Este proyecto existe gracias a las personas que contribuyeron

Licencia

CC0

Iconos proporcionados por Icons8

⬆ volver a arriba