Ávidos de crear soluciones para un mercado creciente, desde hace algún tiempo nos vimos involucrados en el desarrollo de productos digitales que den respuesta a necesidades propias de una era que, entre otras cosas, obliga a permanecer a la vanguardia en materia de procesos y resultados. En este contexto, nuestro principal desafío radica en el perfeccionamiento de una impronta propia que continúe sorprendiendo.

En Aerolab creemos en el trabajo y en el aprendizaje permanente. Estamos seguros de que las metas deben servir a modo de superación personal y que cualquiera puede impartir conocimiento.

Pero principalmente, creemos fervientemente en el poder de las ideas simples bien ejecutadas. Y damos por sentado que contamos con aptitudes y valores de trabajo lo suficientemente maduros como para hacer de estas premisas nuestra más sólida fuente de inspiración.

En Aerolab creemos en el trabajo y en el aprendizaje permanente. Estamos seguros de que las metas deben servir a modo de superación personal y que cualquiera puede impartir conocimiento.

Como en cualquier flujo de trabajo, todas y cada una de las partes involucradas en los diferentes procesos son fundamentales y, por ende, la falla de alguna de ellas tiene un impacto directo en el resto.

Para evitar inconvenientes y malos entendidos decidimos crear esta suerte de guía rápida que enumera recomendaciones, consejos, sugerencias y algún que otro pedido puntual, esperando optimizar un curso de acción que debería funcionar de manera aceitada asegurando eficiencia en el desempeño y buenos resultados.

No obstante, no es la intención de esta guía delimitar formas de actuar, ni tampoco moldear comportamientos.

Queremos que quede claro que podés trabajar de la manera que te resulte más práctica y útil. Nos interesa que te sientas cómodo porque sos una parte importante de nuestro equipo de trabajo y sabemos que tu aporte es sumamente valioso. Sin embargo, sea cual sea la forma en que elijas desempeñar tus actividades, vamos a necesitar que no pases por alto ciertas pautas. Simplemente con eso, nos estarás ayudando de manera significativa a mantener (e inclusive hacer crecer) el prestigio con esfuerzo ya consolidado.

En Aerolab tenemos una forma particular de atravesar el proceso de diseño, al cual dividimos en tres etapas:

• 01. Experiencia de Usuario
• 02. Diseño de interfaz
• 03. Componentes de la interfaz

La etapa de UX trabaja sobre la experiencia general del usuario asociada al uso del producto a crear. Los wireframes adquieren especial protagonismo en esta fase, no solo porque permiten delinear la estructura de las diferentes secciones del sitio o app (teniendo en cuenta arquitectura de la información, usabilidad, flow de navegación, etc.), sino porque, además, es a través de ellos que se definen las posibilidades de interacción.

Esta etapa suele ser la más larga de todo el proceso de diseño. ¡No desesperes! Es importante ser muy metódico y prolijo en la organización de archivos, principalmente cuando los proyectos adquieren grandes dimensiones. Pero más importante es considerar en cada una de tus decisiones los pedidos y/o criterios del cliente; no desde un rol de sumisión, sino más bien proactivo.

Al cliente no le gusta ser tratado como un estúpido y a menudo buscará que sus ideas se hagan valer. No obstante, nunca dejés de dar tu opinión si hay algo que pensás podría hacerse de otra manera más efectiva. Sé cauteloso respecto a la forma en que redactás tus enunciados y cuidá la ortografía. Frases como “entiendo tu punto, pero opino que…” o “me parece bien lo que decís, pero considero…” son una buena forma de dar a conocer tu postura sin sonar pedante. No busques imponer tus ideas sino sugerir o proponer cambios con argumentos. Si no estás seguro de lo que escribiste, pedile a alguien más que lo lea y te dé su opinión. Actitudes como éstas te exponen frente al cliente como una persona criteriosa y respetuosa, lo cual hará que, muy probablemente, éste busque conocer tu opinión en futuras decisiones que deba tomar.

...nunca dejés de dar tu opinión si hay algo que pensás podría hacerse de otra manera más efectiva.

Una vez que los wireframes pasaron por, al menos, 2 iteraciones y fueron aprobados por el cliente, se procede al desarrollo de UI, en el cual se define el Look and Feel que tendrá el sitio/app (enfoque conceptual y lenguaje gráfico a utilizar) para, posteriormente, estilar los wireframes. Esta etapa suele requerir menos iteraciones por parte del cliente dado que involucra meras decisiones estéticas, siempre respetando los wireframes ya aprobados.

Por último, en algunos casos, se realiza una compilación de todos los elementos gráficos del sitio/app en un único archivo que se extiende al cliente como guía para nuevas decisiones de diseño relativas al producto que pudiera tener que tomar.

Criterios de calidad en entregables

Como nos interesa generar una buena impresión ante nuestros clientes, es importante que prestemos atención a cada uno de los detalles que hacen a las piezas de diseño que les mostramos.

La humildad es fundamental en este proceso. Todos quienes formamos parte de Aerolab somos personas que destacamos por algo, con conocimientos y habilidades que nos hacen únicos y aportan, sin lugar a dudas, al equipo de trabajo (si, ¡sos talentoso! ¡superalo!). Pedir ayuda no te hace menos capaz o inteligente. Las ideas de otros pueden ser una bocanada de aire fresco a tu cabeza y aportarte perspectiva frente a eso a lo que no terminás de encontrarle la vuelta, principalmente en esos momentos en que sentís que ya consideraste, sin éxito alguno, todas las opciones posibles.

Pedir ayuda no te hace menos capaz o inteligente <3

Recordá:

• Usar los criterios unificados para wireframes de Aerolab cuando no te sientas preparado para crear tu propio sistema de wireframing.
• Corroborar alineación conforme a la grilla elegida para el desarrollo del trabajo. Ser consistente en el uso tipográfico (verificar coherencia entre estilos, legibilidad, etc.).
• Buscar concordancia estética con los guidelines de diseño de la empresa cliente (si existieran).
• Ser coherente con las necesidades/objetivos del cliente.
• Contemplar tipografías e imágenes a utilizar, comunicándole oportunamente al cliente que puede que tenga que comprar las respectivas licencias.
• Profundizar respecto a los estándares web y mobile al momento de realizarse el trabajo.
• Ser consistente respecto a las páginas presentadas. El cambio en alguna de las secciones compartidas (header, footer) debe repercutir necesariamente en todas las demás para no confundir al cliente.
• Trabajar los archivos a tamaño real (en pixels) de acuerdo a la resolución del dispositivo de destino.
• Esperar a que el Creative Director, el Lead UI Designer y/o el Project Manager hayan visto tu trabajo antes de subirlo a Basecamp para que el cliente de feedback.
• Tratar de no utilizar texto o contenido simulado. De no existir material, deberán buscarse textos que se aproximen en su contenido a los que vayan a incluirse finalmente. Nunca uses lorem ipsum (salvo que sea para puro relleno).
• Contemplar los diferentes escenarios posibles a la hora de plantear un diseño con contenido que será dinámico. Prestá atención en particular a casos donde el texto pueda ser mucho más largo, ya que es algo que impacta mucho en la etapa de implementación.
• Generar propuesta justificando decisiones que evidencien criterio y buen gusto.

Por otra parte, para entregas de archivos finales, además de lo mencionado anteriormente, deberías:

• Construir un archivo PSD por cada pantalla creada.
• Nombrar y organizar archivos siguiendo las pautas estipuladas.
• Corroborar que los archivos sean la versión aprobada por el cliente.
• Ordenar prolijamente los elementos que hacen a los diferentes archivos en carpetas que identifiquen propiamente cada una de las secciones diseñadas. Los nombres de los elementos/carpetas deberán estar en inglés o español, dependiendo del idioma elegido por el cliente para llevar adelante la comunicación.
• Optimizar el peso de los archivos, eliminando todos aquellos elementos que no tengan razón de ser en el diseño final aprobado por el cliente.

Documentos de especificaciones

Es un mito que los diseñadores y desarrolladores hablan lenguajes diferentes. Pueden, cuando así lo quieren, intercambiar opiniones como con cualquier otro simple mortal. Sin embargo, los desarrolladores no son adivinos. Cuando les llega la hora de hacer lo suyo necesitan que se les expliquen los pormenores vinculados a los archivos con los que deben trabajar.

Es un mito que los diseñadores y desarrolladores hablan lenguajes diferentes.

Es tu trabajo como diseñador crear un pequeño documento con especificaciones sobre funcionalidades que proporcione al desarrollador la información necesaria respecto a posibilidades de interacción, flujos o cualquier otro detalle relevante que éste necesite conocer para llevar adelante su tarea con el mismo nivel de profesionalismo que el tuyo.

Prestá particular atención para documentar animaciones, estados de hover y active para links, comportamiento del layout para diversos monitores (aclará qué tamaño tiene el diseño, si ocupa toda la pantalla o no, qué componentes quedan fijos, etc), y verificá los efectos a usar junto con un desarrollador para asegurarte de que puedan ser implementados correctamente.

Importancia de generar propuesta

Los clientes que acuden a nosotros, persiguen un diferencial basado en competencias y experiencia que no solo deseamos mantener, sino hacer crecer. En Aerolab somos muy estrictos con respecto a todo aquello que pone en juego nuestra reputación y la calidad de nuestro trabajo. Sin embargo, buscamos flexibilizar al máximo los procesos que hacen a ese producto final. Por lo tanto, sentite libre de hacer comentarios (siempre con respeto) sobre trabajos de otros. La crítica bien aceptada siempre es constructiva. Permitite, también, innovar y cambiar de perspectiva cada vez que tengas que encarar un nuevo proyecto.

Lo trendy puede ser una fuente de inspiración sumamente valiosa, pero no es la única. Pensar en grande y “por fuera de la caja” siempre es una actitud apreciada; aporta valor a tu trabajo y, sin lugar a dudas, colabora en el proceso de generar nuevas tendencias en las que podrías ser pionero. Ir a lo seguro es aburrido, ¡y para aburrirse siempre hay tiempo!

Ir a lo seguro es aburrido, ¡y para aburrirse siempre hay tiempo!

Como desarrollador front-end, tu principal responsabilidad es la de implementar la interfaz final sobre la cual van a interactuar los usuarios. Esto no es simplemente traducir un PSD a HTML y CSS, sino que es pulir la interacción con el usuario y establecer los criterios necesarios para que la UX sea lo mejor posible, creando todo desde las adaptaciones responsive hasta esos pequeños detalles (como animaciones sutiles y una excelente performance) que hacen que una interfaz pase de muy buena a excelente.

Para esto tomamos en cuenta nuestro punto de partida, que es la etapa de wireframing y diseño. En lo posible, es conveniente que te involucres temprano en el proyecto para asegurarte de que el diseño de UI/UX puede ser llevado a cabo correctamente, al igual que poder chequear el costado técnico del proyecto para marcar las cosas que hay que tener en cuenta antes de comenzar con la implementación.

...esos pequeños detalles hacen que una interfaz pase de muy buena a excelente.

Cuando termina esta etapa de diseño, ahí sí es necesario crear un pequeño documento que establezca los detalles a tener en cuenta sobre la implementación:

• ¿Cuál es el target de browsers y dispositivos? Verificá esto con las especificaciones del trabajo.
• ¿Cómo son los :hover, :active y animaciones del site? Trabajá codo a codo con los diseñadores para llegar al mejor resultado posible.
• ¿Hay componentes que tengan un funcionamiento particular? (Headers fixed, fondos con parallax, transiciones de elementos).
• ¿Cuánta libertad hay para modificar el diseño? Esto es importante en sitios donde se espera una representación pixel-perfect del diseño, por más complejo que sea. Si este es el caso, y hay que hacer un cambio, asegurate de comunicárselo al Project Manager para que no haya malentendidos.
• ¿Qué va a hacer el cliente con esta implementación? ¿Es conveniente crear una estructura que después permita adaptarla a otra app/plataforma?
• ¿Esto va sobre un framework (CodeIgniter, Laravel, Symfony, Rails, Django, etc) o sólo hay que entregar el HTML? Es conveniente en lo posible trabajar sobre la implementación final, ya que aceleramos el trabajo de integración.
• ¿Hay algún requerimiento en lo que refiere a tecnologías? Por ejemplo, usar Angular, alguna versión de jQuery en particular, evitar elementos de HTML5, entre otras. Documentalas apropiadamente para que se conozcan las restricciones del proyecto.
• ¿Cómo va a ser la integración final con el producto? ¿Quién se encarga de los merges y subida a producción?
• ¿Hay algún estándar de código que haya que seguir?
• ¿Cómo hacemos para avisar que un entregable está listo? Si tenemos un repositorio compartido con el cliente es posible que haya malentendidos de cuáles cosas están listas y cuáles no. Establecé apenas empiece el proyecto una metodología para avisar (cerrando tickets en Basecamp con un comentario que notifique al cliente, por ejemplo) para saber qué cosas se pueden dar por hechas. Recordá siempre la revisión final antes de confirmar un entregable.

Nuestras reglas principales

Performance es una feature

Queremos 60FPS. Esto es nuestra guideline principal a cumplir en nuestros dispositivos de referencia. Si tenés que usar varios polyfills, filtros lentos o plugins/componentes que arruinan el rendimiento de la interfaz (reflows excesivos, no aprovechar el GPU, etc) probablemente termines con una implementación lamentable.

La única excepción que podemos tener a esta regla es si existe un motivo artístico lo suficientemente importante como para reducir nuestro target a 30FPS. Por ejemplo, el sitio de JSConf 2014 o el de Xapo notarás que sacrifican performance en pos de conseguir un resultado visual impactante.

Prolijidad ante todo

Nuestras guidelines son muy simples: Usamos UTF-8 para todo, tabulado con 2 espacios, y casi siempre tomamos como base una recipe de yeoman (webapp es de las más populares internamente). Trabajamos en inglés a menos que haya una excepción para el proyecto (como este manual :P).

Tratá de que el código sea claro y modular, usando bower para dependencias y aprovechando SASS y partials para dividir el código en módulos lógicos. Como regla general no te repitas, y asumí que quien va a trabajar con vos en el proyecto es un asesino serial que sabe dónde vivís.

Show and Tell

Usamos Pull Requests para hacer una revisión de código antes de dar por finalizada una feature. De esta forma damos lugar a que nuestros compañeros de equipo puedan asegurar que se están cumpliendo nuestros estándares de calidad, al igual que nos otorga un segundo punto de vista para detectar problemas con el código.

Asimismo, en features complejas es conveniente que todos se sumen para testear y dar insights valiosos, los cuales pueden discutirse y corregirse antes de terminar cada objetivo.

Test, Test, Test

Chrome no es el único browser que existe. Desde el costado visual, nuestros estándares de compatibilidad son muy simples y sólo lleva unos minutos verificar que el funcionamiento de una interfaz es apto para la mayoría de los usuarios. A medida que aumenta la complejidad del proyecto, es recomendable incorporar unit tests y visual regression tests. Los tests no son tanto para ver si lo que acabás de terminar está bien. Es para enterarte si lo rompiste después.

Testeá siempre antes de enviar un entregable. De lo contrario te las vas a ver con un Project Manager iracundo.

En desktop, como política general soportamos las dos últimas versiones estables de los browsers principales (Chrome, Firefox, IE, Safari). Asimismo, todos nuestros sites son responsive con soporte mobile por defecto. Nuestra computadora de referencia es un Core i3 con 8GB de RAM y un GPU integrado (esencialmente una Macbook/Notebook/PC de gama media).

En mobile, dada la mayor variación y disponibilidad de hardware, tomamos como base los dispositivos de referencia de iOS y Android, que son los iPhone y Nexus disponibles comercialmente durante los últimos 12 meses, incluyendo sus sistemas operativos. Esto significa actualmente iPhone 5/6/6Plus (iOS 7 y 8) y Nexus 5/6 (Android 4.4 y 5).

Estos estándares son una guía general y deben evaluarse por proyecto para garantizar un excelente resultado final. Analizá las características del sitio en la etapa de análisis para no tomar una decisión dogmática -y seguramente incorrecta-. Recordá que no podemos ofrecer una excelente UX si la mayoría de usuarios no puede usar el sitio/app.

Además de esto, van las consideraciones que tomamos para todo proyecto.

Siempre trabajá con un repositorio

Tenés la posibilidad de crear repositorios propios (bajo el team Aerolab) en BitBucket. Creá uno (o sumate al existente) al comenzar cada proyecto y hacé commits + push frecuentemente, ya que no sólo sirven de backup, sino que tienen tooling que utilizamos con mucha frecuencia.

Usá nuestro sistema de deployment automático siempre que puedas, que te va a permitir mostrar en qué venís trabajando en un branch específico, sin necesidad de pelearte con SSH o FTP.

Usá Git Flow

Git Flow es una metodología que nos permite trabajar con mayor comodidad en un repositorio. Dale una leída al documento, pero lo que tenés que saber es lo siguiente: Usá siempre branches para nuevas features y fixes (feature/redesign), los cuales se mergean a dev para testearlos y recién una vez testeados los mandamos a master.

Comentá las cosas "raras"

Uno siempre termina usando un hack para resolver alguna issue de compatibilidad, o bien termina implementando una feature compleja de corrido sin escribir un sólo comment. Dejá un comentario explicando brevemente la solución o el porqué de la misma para evitar traumas futuros. Si no lo hacés, seguramente te des cuenta de que el código que escribiste es confuso en el momento de la code review.

Documentá todas las especificaciones

Esto viene del primer punto y consiste en responder todas esas preguntas (y las que surjan aparte) documentadas en un Text Document en Basecamp. Tenelo como referencia ante cualquier duda y si hay una consulta, efectuala por Basecamp (con copia al Project Manager / CTO / Lead Developer) para que quede guardada tanto la pregunta como la respuesta del cliente.

Evitá las entregas parciales

Usualmente los clientes asumen que lo que obtienen es una representación clara del trabajo final, y entregar cosas a medias no queda bien (termina en listas interminables de feedback que se responden con “todavía no está hecho”). Sólo entregá cosas finales y aprobadas, y si tenés que hacer una entrega parcial de todos modos, definí con mucha precisión qué cosas están listas para que sólo se evalúe eso.

Pedí la opinión de otro dev

A uno siempre se le escapan cosas o termina haciendo cosas por impulso. Siempre está bueno consultar con otra persona cada tanto para que le pegue un vistazo al trabajo a medida que va avanzando. Es algo que sólo lleva unos minutos y eleva notablemente la calidad del trabajo final, ya que terminás tomando experiencia prestada de alguien que por ahí ya se topó con el mismo problema antes.

Una comunicación aceitada es fundamental dentro de cualquier empresa. Mucho más si tenemos en cuenta el rubro al que nos dedicamos.

Queremos asegurarnos de que tengas absolutamente todas las herramientas posibles para enriquecer el diálogo interno y con clientes, en Aerolab utilizamos, a falta de una, cuatro (!) plataformas:

• Principalmente para procesos de feedback con clientes.
• Videoconferencias y llamadas con clientes.
• Mensajería instantánea interna.
• Contacto con clientes y envío de archivos.

Como verás, ¡no tenés excusas para permanecer aislado!

Todas estas alternativas guardan el historial de conversaciones y archivos compartidos minimizando tiempos de búsqueda y te permiten, además, mantenerte al día respecto a lo que sucede tanto dentro de la oficina como en lo relativo a cada proyecto en el que estés involucrado.

Por eso es fundamental que, apenas enciendas tu máquina, te loguees con todas y cada una de ellas. ¡Pero eso no es todo! Es importante, además, que permanezcas alerta ante la aparición de notificaciones para, llegado el caso, poder responder a ellas con eficiencia, aplicando los criterios de prioridad que correspondan.

Tracking de horas

El objetivo de la misma es realizar una suerte de racconto de las actividades desarrolladas a lo largo del día por cada integrante del equipo, y el tiempo dedicado a cada tarea.

* 1.30 = 1 hora 30 minutos.

Somos conscientes de que no hay nada más aburrido que completar planillas. La burocracia rara vez es divertida. No obstante, suele ser sumamente necesaria en determinadas ocasiones, y hasta que los robots capaces de realizar estas actividades por nosotros no se vuelvan commodities, dudamos acerca de la existencia de mejores soluciones. La buena noticia es que hacerlo no te tomará más de 5 minutos y ayudará sustancialmente a mejorar el rendimiento de trabajo.

Tiempos Muertos

Si en algún momento llegara a sucederte que, habiendo cumplido con todo lo que tenías para hacer y a la espera de que se te asignen otras tareas, no se te ocurre en qué emplear el tiempo libre, te invitamos a que lo aproveches aprendiendo alguna cosa que pensás podría llegar a servirte a futuro, buscando referencias que puedan inspirarte, actualizándote respecto a las últimas tendencias o colaborando en los distintos sideprojects de Aerolab.

En Aerolab nos gusta estimular la curiosidad e impulsamos al aprendizaje como herramienta primordial para combatir el aburrimiento.

Orden de Carpetas y nombres de archivos

Importante

• Los cronogramas se pautarán en conjunto entre el Project Manager y el diseñador/programador a cargo de la tarea.
• Se delimitará una fecha de entrega interna un día antes a la formalmente establecida para el cliente, dando margen a la revisión y corrección de archivos.
• No se publicarán archivos antes de que hayan sido debidamente controlados previamente por un tercero capaz de detectar fallas (Creative Director, Lead UI Designer, Lead Developer, CTO, Project Manager).
• Los archivos serán enviados directamente al Creative Director, Lead UI Designer, Lead Developer, CTO para su supervisión, con copia al Project Manager vía Mail o Slack.
• De existir dudas durante el proceso de diseño, el diseñador se comunicará directamente con el Creative Director, Lead UI Designer o Lead Developer para asesoramiento.
• De existir dudas durante el proceso de maquetado, el desarrollador se comunicará directamente con el Lead Developer o CTO para cuestiones técnicas y/o con el diseñador a cargo del proyecto para asesoramiento puntual respecto al funcionamiento de las vistas.