# 0. Introducción > Ya está disponible una nueva versión del handbook. Puedes encontrarla en [mendesaltaren.com/handbook](https://www.mendesaltaren.com/handbook) ## 0. Introducción ### Introducción Product Design Handbook es una guía práctica donde se refleja cómo trabajamos en equipo de forma ágil, adaptándonos al cliente y asegurando la calidad de nuestros productos. Este proyecto nace de la necesidad de crear un documento explicativo para futuros integrantes del estudio y, se hace público, gracias a nuestro espíritu divulgativo y las ganas de aportar nuestro granito de arena a la comunidad. Nuestro objetivo ante este proyecto es mejorar, sistematizar, unificar procesos internos y hacer lo más trasparente posible nuestra metodología de trabajo. El contenido está estructurado de tal forma que abarca primero lo más general y, de ahí, se parte hacia lo más específico. La idea de esto es que el aterrizaje sea sencillo y se tenga, la mayor parte del tiempo, una visión general del proceso y de nuestra organización. Por otro lado, hemos separado el proceso general de las herramientas que empleamos en nuestro día a día. Esto se debe a la naturaleza cambiante de las mismas. Y es que, además de creer que en esta profesión lo más importante es la metodología, una base cultural rica en referencias técnicas y estéticas así como una sólida formación en diseño, también pensamos que las herramientas pueden cambiar, olvidarse y aprenderse. ### Instrucciones Este documento hay que entenderlo más como una conversación que como un manual. No pretende ser paradigma de nada, sino un reflejo del proceso que seguimos en el estudio, documentando el mismo. Es una guía básica para cualquier persona que vaya a incorporarse al estudio o con la que vayamos a trabajar en algún proyecto concreto. Creemos que la mejor forma de utilizarlo es haciéndolo tuyo y asimilando aquellas partes que entren en tu flujo de trabajo. No pretendemos ser exhaustivos ni ahondar en todas las técnicas. Encontrarás algunas partes bien delimitadas y otras que no lo están tanto: obedece al hecho de que para todo proceso hay pasos, pero no para todos los pasos hay herramientas exactas que los completen. Es un proceso creativo y, como tal, siempre hay espacio para tu propio sello. ### Sobre mendesaltaren Somos un estudio de diseño de productos digitales. Co-fundamos y ayudamos a lanzar productos y empresas a través de la estrategia y el diseño. Somos el lazo perfecto entre producto y negocio. Creemos en el buen trabajo y las cosas bien hechas. Creemos que la belleza atemporal proviene de la función. Creemos en teorías y objetos con sentido. Creemos en el valor de los conceptos y el arte, todo proyecto necesita un alma. Por encima de todo, creemos en la honestidad: ponemos a nuestros clientes y a sus públicos en el centro de cada decisión que tomamos. Esfuerzo, devoción, dedicación y gloria. ### Cómo colaborar con este proyecto Siempre estamos abiertos a sugerencias acerca de como mejorar nuestro contenido. Si tienes alguna, puedes abrir un issue en GitHub y estaremos encantados de revisarlo. Para abrirlo solo tienes que estar dado de alta en GitHub y pulsar en el botón "Edit in GitHub" de la página que quieras editar. Otra forma de colaborar ayudarnos con esta iniciativa es hacer un fork y enviarnos directamente un pull request para solucionar cualquier error que encuentres o añadir algún recurso o información. Si este proceso te parece muy tedioso siempre puedes escribirnos un mail a con tus sugerencias. Cualquier tipo de ayuda siempre será bienvenida. Empresas y centros académicos que utilizan nuestro Product Design Handbook como referencia:\ ZARA, GOI, Chicfy, C14/SEAT, Packlink, Universidad Europea, Playtomic entre otros… {% embed url="" %} > 100k pasos, más de 100k pasos en mis pies\ > But the sun’s gonna rise, the sun’s gonna rise like everyday > > – Agorazein ### Licencia Esta obra está bajo una licencia de [Creative Commons Reconocimiento 4.0 Internacional](https://github.com/mendesaltaren/product-design-handbook/tree/2652cd4913656e81f5956d392148cd56b4693161/LICENSE/README.md). [![Licencia de Creative Commons](https://i.creativecommons.org/l/by/4.0/88x31.png)](http://creativecommons.org/licenses/by/4.0/) # 1. Cómo nos organizamos ## 1. Organización del equipo En este apartado compartiremos nuestra organización básica a distintos niveles. Por un lado, hablaremos de cómo organizamos el trabajo en base a los objetivos. Bajaremos un escalón para hablar de qué tipo de reuniones realizamos para coordinar y organizar nuestro caudal de trabajo y daremos pistas sobre la manera en la que organizamos un proyecto concreto. ### 1.1 **Semana, mes, trimestre, año** En el equipo trabajamos en torno a objetivos. Distinguimos cuatro tipo de objetivos en función de su dimensión: anuales, trimestrales, mensuales y semanales. Definimos estos objetivos siguiendo los principios SMART, es decir, deben ser específicos, medibles, alcanzables, relevantes y definidos en un tiempo específico. Nótese que usamos una variante diferente a la establecida por George T. Doran, sustituimos asignables por alcanzables y realistas por relevantes, ya que, para nosotros, es fundamental que esos objetivos tengan impacto y nos acerquen a las metas que queremos alcanzar. Además, es fundamental que todos los objetivos cumplan este criterio porque nos obliga a dejar a un lado los objetivos aspiracionales y reducir el autoengaño y la autocomplacencia. Cada vez que definimos nuevos objetivos o se actualizan los anteriores se comparten con todos los integrantes del estudio para hacerlos partícipes. Esto nos permite estar alineados y compartir la visión del estudio. Por último, tenemos claro que vivimos en tiempos de cambio constante. Debido a esto, cada trimestre revisamos los objetivos anuales tanto para ver si hemos perdido foco como para actualizarlos en función de las nuevas necesidades que hayan podido surgir. Esto nos permite actuar de forma más rápida ante los cambios y hacer que los objetivos anuales no pierdan sentido a lo largo del tiempo. **Objetivos anuales** Los objetivos anuales son ambiciosos. Su función es definir dónde queremos estar en un año. Estos objetivos están relacionados con nuestro rendimiento, propuesta de valor, estrategia y posición competitiva. Con los objetivos anuales marcamos la meta pero no el camino. Son abstractos, y por ello los revisamos y concretamos trimestralmente mediante objetivos más pequeños y medibles. **Objetivos trimestrales** Cada tres meses, se realiza una reunión para definir los objetivos del siguiente trimestre y sus KPIs correspondientes. En esta reunión, revisamos si hemos cumplido los objetivos del trimestre anterior, analizamos el estado actual de la empresa y hacemos un seguimiento de los objetivos anuales para ver si es necesario actualizarlos. Con este análisis obtenemos una visión más clara de los aspectos en los que debemos poner el foco y que datos determinarán si hemos cumplido las metas que esperamos. **Objetivos mensuales** Los objetivos mensuales surgen para simplificar los objetivos trimestrales, transformando estos en acciones a realizar. A principio de cada mes tiene lugar una reunión en la que organizamos el trabajo, definimos los objetivos del mes y establecemos prioridades. La planificación mensual nos ayuda a tener una visión más amplia que a una semana para eludir posibles problemas del futuro y optimizar recursos y tiempo. **Objetivos semanales** En el día a día del estudio trabajamos con objetivos semanales coordinando intereses y equipos. Para organizar y compaginar los distintos equipos y proyectos con los que trabajamos, adaptamos la metodología **Scrum** a nuestro trabajo, realizamos *plannings*, *dailies* y retrospectivas para gestionar tanto cada proyecto, como el equipo. ### 1.2 Meetings A la hora de reunirnos seguimos una metodología ágil. Establecemos objetivos claros y directos para cada reunión, y evitamos en todos los casos establecer comités. Consideramos que lo más valioso es el tiempo y nos tomamos en serio el respetarlo. ### 1.3 **Planning semanal** Reunión semanal en la que se analiza el estado de los proyectos y se fijan los objetivos a alcanzar y tareas a completar durante la semana. ***Planning*** **Equipo** Reunión que se realiza los lunes en la que están presentes todos los miembros del equipo. En la *Planning* del estudio se analiza el estado de los proyectos que se están realizando. Este análisis incluye: * Cómo fue la semana anterior * Cómo se presenta la semana que comienza * Bloqueos que puedan haber surgido ***Planning*** **Proyecto** Cada responsable de proyecto tiene una reunión con los miembros del equipo que formen parte de dicho proyecto. En ésta, se deben determinar qué tareas del Backlog se van a completar en el *Sprint* que comienza, pasando estas de *Backlog* a *Sprint Backlog.* ### 1.4 Geekbot daily meeting La *daily* se completa todos los días por todos los miembros del equipo. La *daily* es una forma de recapitular sobre todo lo que se ha hecho el día anterior, los objetivos para ese día y los posibles bloqueos que se han encontrado. Para realizarla, utilizamos el bot de Geekbot para Slack: {% embed url="" %} Geekbot nos permite realizar la daily de forma sencilla y asíncrona, mediante 4 preguntas que se envían directamente al canal #daily del [Slack](https://slack.com) que usamos en el equipo. Te pregunta cómo estás, qué se hizo el día anterior, cuáles son las tareas planteadas a completar en el día y si has encontrado algún bloqueo. Esta forma de hacer la *daily* nos aporta flexibilidad, ya que: * Cada miembro del equipo puede elegir en que momento completarla. * No es necesaria la presencia de todos los miembros del equipo para llevarse a cabo. * Al poder acceder a ella fácilmente en Slack, todos los miembros del equipo tendrán conocimiento de la daily de sus compañeros. {% hint style="info" %} Para asegurarnos que todas las personas del equipo están al tanto y conozcan en qué se está trabajando, se deben leer las *dailies* del resto de miembros del equipo. Para marcar que se ha leído la *daily* de un compañero se reacciona con un ✅ al mensaje generado por *Geekbot* en el canal #daily. {% endhint %} **Preguntas para completar la** ***daily*** {% hint style="info" %} ✏️ Estas preguntas las lanza *Geekbot* automáticamente a la hora que fijemos o al utilizar el comando`report`. {% endhint %} Para contestar a las preguntas utilizamos la plantilla que se muestra a continuación, así se consigue unificar las respuestas de todos los miembros del equipo. * **¿Qué hiciste ayer?** *Nombre del proyecto 1* ✅ Tarea completada ➕ Tarea realizada que no estaba contemplada al inicio del día anterior. ❌ Tarea no completada (Se debe explicar los motivos por los que no se completó, para dar información al resto del equipo) ⚙️ Tarea en proceso (exclusivo para tareas de larga duración que no pueden ser divididas) *Nombre del proyecto 2* ✅ ... * **¿Qué vas a hacer hoy?** *Nombre del proyecto 1* * Tarea a realizar * Tarea a realizar * Tarea a realizar *Nombre del proyecto 2* * ... * **¿Cuándo estará listo?** Al tratarse de una *daily* todas las tareas que se programan para el día deberían ser completadas. Sin embargo, puede haber tareas que requieran más de un día de realización. Esta pregunta nos da la oportunidad de concretar cuando esperamos acabarlas, de forma que el proyecto no quede bloqueado. * **¿Has encontrado algún bloqueo?** Cuéntale al equipo que bloqueos te encontraste el día anterior y menciona a las personas que te pueden ayudar a solucionarlo. {% hint style="info" %} **Recuerda:** para mencionar a una persona el Slack basta con poner el símbolo de arroba (@) seguido del nombre de usuario que utiliza esa persona. {% endhint %} ### 1.5 Retrospectivas Las retrospectivas nos sirven para analizar el trabajo realizado, nos ayudan a mejorar potenciando lo que ha ido bien y poniendo foco en lo que ha ido mal para proponer ideas que nos ayuden a solucionarlo. **Retrospectiva Proyecto** Reunión en la que participan todos los miembros de un proyecto. El responsable de cada proyecto es quien debe convocar a todos los miembros que participan en él para para analizar qué ha ido bien, qué ha ido mal y cómo se puede mejorar en el siguiente *sprint*. **Retrospectiva Equipo** Reunión que tiene lugar al final de cada mes para distinguir qué cosas han ido bien para mantenerlas y fomentarlas, qué ha ido mal para poner foco en solucionarlas, y cómo se puede mejorar. En la retrospectiva del equipo estarán presentes todos los miembros del equipo. ## 2. Organización de un proyecto ### 2.1 Líder de proyecto Consideramos que tener una persona que lidere un proyecto es muy importante al trabajar con distintos proyectos simultáneamente. Cada uno de nuestros proyectos cuenta con un líder que ayuda a que el proyecto alcance la máxima calidad. El líder de proyecto supervisa y coordina los objetivos, las tareas a realizar y a los miembros del equipo que participan en el proyecto. Es el responsable último de la producción, coordinación y el trato con el cliente y es quién fija las reuniones con él para mostrarle los avances y mantenerle al día. Su papel es fundamental. ### 2.2 Project management La organización del proyecto se realiza por parte del equipo, recayendo su gestión sobre el responsable del proyecto. Para coordinar el proyecto y sus tareas, contamos con herramientas como Asana y Notion que nos permiten documentar, organizar y monitorizar cada trabajo. Asana nos permite visualizar el *roadmap* y las tareas que hay que realizar de un proyecto, mientras que en Notion está toda la documentación necesaria para que cualquier persona del equipo pueda llevar a cabo las actividades de un proyecto. {% hint style="info" %} Puedes conocer más en **i. Herramientas** sobre cómo nos organizamos en las páginas de [Notion](/tools/notion) y [Asana](/tools/asana). {% endhint %} Aunque existe un grado de jerarquía en el estudio, intentamos que sea más o menos difusa. Todos los implicados en un proyecto tratan directamente con el cliente en mayor o menor medida. La transparencia y la transversalidad y horizontalidad son dos de las claves de nuestro enfoque. ### 2.3 Gestión de tiempos Al inicio de cada proyecto, se realiza un *Kick-off meeting* donde participa el equipo del cliente, el responsable del proyecto y las personas de mendesaltaren que trabajarán en él. En esta reunión inicial se establece el objetivo de negocio que se quiere alcanzar y qué es lo que se espera del proyecto. También se comparte un *roadmap* claro. Al trabajar con *sprints* semanales, lo normal es ir compartiendo con el cliente semana a semana nuestros avances. Esta periodicidad podrá variar en función de las necesidades del cliente y el proyecto. Es muy importante definir claramente los objetivos de una reunión o presentación, así como ir al grano. De esta forma evitaremos el diseño por comité y hacer perder el tiempo a compañeros y *stakeholders*. Habitualmente, tras cada revisión con el cliente es el momento de aplicar el *feedback* que haya surgido. ## 3. Organización de archivos ### 3.1 Introducción Dropbox es la herramienta que utilizamos en el equipo para gestionar los archivos, es el lugar donde se encuentran los entregables, los archivos y los recursos necesarios para llevar a cabo un proyecto. La estructura básica presente en Dropbox es la siguiente: * **Estudio** En Estudio se encuentran todos los recursos relacionados con el estudio. * **Proyectos** Proyectos contiene todos los proyectos activos y completados realizados por el estudio. * **Recursos** Recursos contiene todos los recursos que pueden ser de utilidad en el diseño de los proyectos, pero no están enfocados a ninguno en concreto. ### 3.2 Proyectos y estructura de carpetas Documentamos cada proyecto en una carpeta distinta. Todos los proyectos siguen la misma nomenclatura para que puedan ser ubicados fácilmente: ``` [[id]_[NOMBRE DEL PROYECTO] ``` * **id** Numeración del proyecto. Los ids están formados por dos dígitos, empezando en el 00. Los ids se generan a partir de números consecutivos, que se establecen según el orden en el que se iniciaron los proyectos, de tal forma que los proyectos más antiguos tienen un número menor y los más recientes un número más alto. 00 01 02 03 04 05 06 07 08 09 10 11 ... * **Nombre del Proyecto** El nombre del proyecto se corresponde normalmente con el nombre de la empresa. Siempre los ponemos en mayúscula y si es un nombre compuesto usamos espacios para separar las palabras. Por ejemplo: ``` - 17_SEAT - 18_CHICFY ``` {% hint style="info" %} 👆🏻 Esta nomenclatura nos facilita que los proyectos estén ordenados por la fecha en la que fueron creados. {% endhint %} **Todos los proyectos cuentan con la misma estructura y organización:** ``` ——— 00_assets ——— _archive ——— brand-assets ——— documents ——— icon-set ——— images ——— typographies ——— 01_product-definition ——— _archive ——— _briefing ——— _research ——— 02_product-design ——— _archive ——— _branding ——— _UX ——— _UI ——— _Prototype ——— _design-system ——— 03_output ——— _deliverables ——— _case-study ``` * **00\_assets** Elementos relativos a la marca. * **01\_product-definition** Documentos y archivos relacionados con la exploración y definición del producto. * **02\_product-design** Archivos relacionados con el diseño de producto. Aquí deben estar todos los documentos y archivos desde el UX (como A*rquitectura de Información*, *User Personas* y los *Wireframes*) hasta su interfaz. * **03\_output** Debe contener todos los archivos y documentos que estén listos para entregar al cliente. Todo lo que se le entrega al cliente debe estar en esta carpeta. Estos pueden ser PDFs, explicaciones, archivos de Sketch, vídeos, imágenes, etc. {% hint style="info" %} ✏️ Esta estructura sirve de base para empezar a trabajar. La organización debe adaptarse a la lógica del proyecto. Si una carpeta corresponde a un servicio que no se va a realizar, debería borrarse y adaptar el resto al nuevo orden. {% endhint %} ### 3.3 Nomenclatura Para tener los archivos organizados y saber fácilmente qué contienen, los nombramos haciendo referencia a la ruta de su directorio. Este es es el esqueleto de nuestra nomenclatura de archivos: ``` [id Proyecto][Nombre del Proyecto][id archivo][tipo de archivo][Plataforma] ``` * **id Proyecto + Nombre proyecto** Para identificar la carpeta y la ruta del archivo rápidamente. * **id archivo** Corresponde con el id de la subcarpeta que lo contiene. Puede ser: 00 para assets, 01 01\_product-definition, 02\_product-design, 03\_output. Obviamos el nombre de la subcarpeta y usamos solo el id. * **Tipo de archivo.** Corresponde con la fase que se lleva a cabo en el archivo: *UI*, *UX*, *Design System*, *Branding*, *Prototype*. * **Plataforma.** Corresponde con la plataforma para la cual se está diseñando: web (Desktop o Mobile) o app (iOS o Android). Por ejemplo: ``` - 17_SEAT_02_UI_Web - 17_SEAT_02_UI_app_Android - 17_SEAT_02_UI_app_iOS ``` {% hint style="info" %} Esta nomenclatura se puede trasladar a las distintas herramientas que utilizamos en mendesaltaren, la 💡 idea es que los archivos de todas las herramientas mantengan el mismo nombre y jerarquía para que cualquier persona del equipo pueda encontrarlo fácilmente. {% endhint %} # 2. Proceso ## Introducción **La importancia del proceso** > Sobrestimamos el evento y subestimamos el proceso; cada sueño realizado ocurrió gracias a la dedicación de un proceso > > – John C. Maxwell Un proceso bien estructurado y madurado es una de las claves del éxito de cualquier proyecto. Y aunque cada proyecto es un mundo, existen numerosos patrones que a lo largo del tiempo hemos ido madurando y asumiendo, encontrando caminos recurrentes para llegar a resultados muy distintos. Desde el primer email de contacto, o la primera conversación informal en un evento, hasta la entrega final pueden llegar a pasar meses, pero independientemente de lo que se dilate un proyecto en el tiempo, el proceso siempre está presente. La previsibilidad es la clave. Seguir un roadmap definido y tenerlo actualizado nos ayudará a reducir la incertidumbre y a hacer partícipe a nuestro cliente de todos los eventos que ocurrirán durante su proyecto. No vamos a hablar de un proceso único. En absoluto se tratará de un discurso monolítico. En realidad nuestro proceso se compone de muchos procesos: hemos decidido distinguir tres tipos de ellos, que de forma alterna se irán sucediendo en la cronología de nuestro trabajo. * **Procesos de definición estratégica**, que nos permiten vislumbrar el camino a seguir para ayudar a nuestros clientes. La estrategia parte de un mercado, contexto, objetivos, necesidades y públicos concretos, sentando las bases de todo nuestro trabajo. * **Procesos de producto,** relacionados con la solución de problemas complejos para los usuarios en base a una serie de objetivos en un contexto concreto. * **Procesos de definición gráfica**, ya que es la comunicación visual nuestra principal herramienta (que no la única) a la hora de hacer que un producto digital sea un éxito. ![Diagrama del flujo general de trabajo que usamos en el estudio](/files/-MiLrytC1ItKT6HAKOXV) ## 1. Preparación Todo proyecto nace de una necesidad de un cliente. Pero es muy común que el propio cliente no sepa bien qué quiere o por qué cuenta con nosotros. Es muy importante realizar una labor formativa antes de arrancar transmitiéndole con claridad cual es la cultura y el enfoque de nuestro trabajo de manera que el cliente entienda el valor diferencial que aportamos. **Esta formación se puede dar de varias formas:** * **Formamos al cliente.** Los clientes suelen identificarnos con su idea preconcebida sobre el diseño gráfico, centrándose solo en la parte estética. **Cuando empiezan a trabajar con nosotros les enseñamos la dimensión que tiene el diseño de producto**, aprendiendo de nuestra metodología. * Formamos diseñadores para el cliente. **Un valor muy importante, que nos diferencia**, es el servicio de encontrar talento y formarlo durante un proyecto para después incorporarlo al cliente. **¿Por qué es tan importante?** * **Compartir visión y cultura.** Es muy importante que tu cliente sepa qué va a obtener de ti y qué no. * **Evitar clientes que no encajan.** Es mejor no realizar un trabajo que no forma parte de tu foco profesional y derivarlo a otros compañeros. Mejora el sector, es honesto con el cliente y nos permite centrarnos donde realmente aportamos. * **Mejorar la valoración de nuestro trabajo.** Transmitiendo el proceso y los pormenores de otros proyectos logramos que el cliente entienda la complejidad del día a día, lo que mejora su capacidad de criticar y entender lo que hacemos. ### **1.1 Propuesta** Los proyectos nacen de las necesidades del cliente. Éste nos contacta y nos traslada sus necesidades a través de un ***Briefing***. En base a éste, se debe formalizar una **propuesta**, materializando la idea y objetivos que tiene el cliente en los servicios que podemos ofrecerle para aportar valor en su producto. **Nuestras propuestas contienen:** * Una descripción detallada de las fases que compondrán el proyecto. * Una estimación de las fechas. * Presupuesto detallado. * Condiciones del servicio. * Materiales y entregables que recibirá el cliente. * En ciertas ocasiones, ejemplos de otros proyectos. Aunque aceptar o rechazar una propuesta pueda a priori parecer una decisión racional, gran parte de la misma se basa en lo emocional. Por ello no debemos nunca descuidar el detalle, narrativa, y la calidad gráfica de nuestra propuesta: debe ser un reflejo de lo que estamos ofreciendo en ella e ir claramente alineada con la identidad y cultura de nuestro estudio. Una vez aprobada la propuesta donde se han definido los servicios que se van a llevar a cabo y los objetivos a alcanzar, se documentan en [Notion](/tools/notion) y se trasladan las tareas a [Asana](/tools/asana). ## 2. Entendimiento La fase de entendimiento es el proceso que nos permite establecer el marco de actuación de nuestro trabajo. Se trata de una serie de dinámicas y procesos que deben ser aplicados según nuestro criterio para extraer toda la información necesaria para la construcción del proyecto en fases posteriores. Las conclusiones en esta fase deben ser compartidas con el cliente como un producto más y validadas por él. Solo de esta manera conseguiremos un cimiento estable que elimine expresiones como "me gusta" del vocabulario de nuestros clientes. **Conocer el problema** Cualquier proyecto de calidad, ya engloble producto, branding, u otros servicios, se comienza a gestar durante la fase de entendimiento. Es probablemente, la parte más importante de todo el proceso. La clave es delimitar claramente el problema al que nos enfrentamos. Si dicho problema no ha sido correctamente descrito, podríamos no dar nunca con una solución adecuada. Existen numerosas vías para llegar a conocer bien el problema. No existe una receta única. Normalmente, la fase de entendimiento comienza desde la primera toma de contacto. Este es el momento de preparar el proyecto a nivel técnico. Debemos crear el proyecto en Abstract y dar acceso a todas las personas involucradas en el proyecto, para que puedan ver los avances y aportar feedback a lo largo de este. Es también el momento de preparar la estructura de carpetas así como crear y organizar la documentación en Notion y empezar a crear tareas en Asana. {% hint style="info" %} 👉 En [**Cómo nos organizamos**](/organization) aprenderás más sobre cómo crear esta estructura.\ 👉 En [**Notion**](/tools/notion) puedes conocer más sobre cómo creamos y documentamos un proyecto.\ 👉 En [**Asana**](/tools/asana) puedes ver cómo organizamos las tareas a completar del proceso.\ 👉 En [**Abstract**](/tools/abstract) leerás acerca de esta herramienta y como preparar un proyecto. {% endhint %} ### 2.1 Brief Una de las vías más comunes de comenzar a *entender* es a través de un brief, si no lo hubiera habido ya antes de la propuesta. Existen multitud de formatos. En su versión más extendida, no es más que un documento donde se detalla la solicitud de servicios por parte del cliente, pero puede ser mucho más que eso. En nuestro caso, el brief es una disposición mental que hacemos en la reunión de toma de contacto que nos permite testear qué quiere el cliente, adelantar posibles problemas o beneficios del proyecto y, en definitiva, extraer en frío toda la información posible. Se trata de realizar las preguntas y propuestas correctas durante esa primera reunión. ### 2.2 **Brand Strategy Brief** Para entender el producto y la marca y adquirir un conocimiento inicial de los mismos, solemos enviar a nuestros clientes un documento de nuestra factura al que llamamos **Brand Strategy Brief**. Es un pequeño cuestionario que invita al cliente a hacer una reflexión estratégica y conceptual sobre su organización, pasando por la visión, misión y valores, así como su público objetivo y competencia. De esta manera, el equipo mendesaltaren se alinea con el cliente, adoptando sus principios y valores a lo largo del proyecto. Este brief no es siempre necesario, pero es imprescindible si el proyecto incluye branding o si no tienen una estrategia bien definida. [Brand Strategy Brief](https://www.notion.so/mendesaltaren/Brand-Strategy-Brief-a3a812793b7843ffbe2fbb593c5a43e7) ### 2.3 Kick-Off Una vez el Brand Strategy Brief se haya completado, se realiza un **Kick-off meeting** donde se ahonda en los objetivos de negocio que se quieren alcanzar y en qué es lo que se espera de mendesaltaren. El Kick-off meeting ayuda a establecer objetivos medibles y alcanzables, así como fijar un roadmap realista. En esta sesión debemos empezar a detectar el problema, así como lanzar hipótesis de por qué ha surgido el mismo. Es interesante que surjan ideas rápidas sobre las posibles soluciones, tanto por parte de nuestros stakeholders, el equipo del cliente como de nuestro propio equipo. De esta manera, podemos testear la receptividad de los stakeholders, cómo de flexibles son, y cuan fácil podrá ser convencerles de nuestras decisiones. Un buen ejercicio a utilizar en esta fase es el **Product Canvas**, que se explica a continuación**.** ### 2.4 Product canvas El product canvas es una herramienta muy útil que nos permite tener una foto global del producto mediante el acercamiento cliente-agencia. Se parece mucho a un canvas de negocio pero enfocado a producto. Es, en última instancia, una herramienta de comunicación, que busca, partiendo del segmento de cliente de un producto, detectar sus necesidades insatisfechas así como las carencias y beneficios del producto para transformar todas ellas en una propuesta de valor sólida que posteriormente se materialice en un set de funcionalidades no priorizadas. De este set de funcionalidades, "la carta de Los Reyes Magos", podremos extraer las bases del producto. Involucra a representantes de los diferentes equipos en una dinámica de toma de decisiones en base a un proceso. Es imprescindible la figura de un facilitador que vaya tomando nota en nuestro canvas de las aportaciones de los participantes de la dinámica. Este facilitador no debe tomar partido de la toma de decisiones para así ayudar al resto a verbalizar ideas, seleccionarlas, categorizarlas y evitar bloqueos. El product canvas es también una forma estupenda de que el equipo del cliente nos conozca y entienda que estamos ahí para escucharles y ayudarles a mejorar sus procesos y productos. ![Product Canvas](/files/-MiLrytFchrAI0mjaN9G) * **Segmento de cliente** ¿Cuál es el target de nuestro producto? ¿A quién va dirigido? * **Necesidades insatisfechas** ¿Cuáles han sido las necesidades observadas en el mercado a las que se les busca solución? * **Pains** ¿Cuáles son los pains que tiene el cliente para llevar sacar el producto? → Debilidades * **Gains** ¿Cuáles son los puntos fuerte del cliente que ayudan y contribuyen a llevar a cabo el producto? → Fortalezas * **Propuesta de valor** La propuesta de valor es el último rectángulo en ser completado. Es importante que sea el último, ya que se debe nutrir de todo lo planteado en los demás. La propuesta de valor representa la ventaja competitiva del producto respecto a los que ya hay en el mercado. ¿Qué es lo que hace que los clientes elijan nuestro producto? * **Feature set** ¿Cuáles son las características del producto? * **UX** ¿Qué herramientas y ejercicios de UX se van a utilizar para conocer a nuestros usuarios?¿Cómo vamos a conseguir información de ellos? * **Canales** ¿Cuáles son los canales a través de los cuales se va a dar a conocer el producto? ¿Cuáles son los canales que utiliza el producto? * **Pricing** ¿Cómo se va a monetizar el producto? ### 2.5 Documentación Documentar el proceso que realicemos es tanto o más importante como el proceso en sí. Sin una correcta documentación, la información se ira perdiendo con el paso de los días, e incurriremos en errores o asincronías que entran en el terreno de la incertidumbre. Para documentar utilizamos varias herramientas, centralizándolo todo en Notion. Documentamos impresiones de nuestros clientes en cada reunión, aspectos de la organización tales como objetivos, roadmaps o entregables, enlaces relacionados de interés, conclusiones que obtenemos y presentaciones que vamos realizando a nuestros clientes a lo largo del proyecto. ### 2.6 Research Una vez tenemos una serie de hipótesis bien claras sobre nuestro producto o marca, pasamos a investigar acerca del mismo. Dependiendo del tipo del servicio que ofrecemos este research el plan irá cambiando. En un trabajo con un gran peso de branding, habrá una dedicación mayor a competencia y mercado que en un proyecto de definición, donde gran parte de los recursos irán más enfocados a la investigación sobre usuarios. Pero sea como sea este plan, seguirá las siguientes fases: * Recolectar información. Plantearemos aquellas dinámicas o herramientas que sean necesarias para extraer toda la información que creamos valiosa para empezar a validar hipótesis y plantear las siguientes. * Extraer conclusiones. Produciremos aquellos documentos que nos permitan establecer y comunicar aquellas conclusiones que podamos asumir en base a la data obtenida mediante la recolección de información. * Compartir y validar. Toda la información generada debe ser compartida y validada con el cliente, no solo por la utilidad que pueda reportarle, si no para dar también valor a nuestro trabajo y apoyar las decisiones que tomemos posteriormente en procesos racionales. Esta fase podría repercutir en seguir investigando. ### 2.7 **Recolectar información** A la hora de recabar información valiosa existen multitud de herramientas y dinámicas. Describimos algunas de ellas por ser las más habituales dentro del estudio. * Shadowing. Consiste en seguir y observar al usuario en el lugar y el momento en el que se hace uso de la plataforma. Conviene no interferir en su desempeño y nos permite extraer información valiosa de uso real con pocos sesgos. * Desk research. Se trata de buscar información al uso, ya sean artículos, investigaciones, entrevistas, probar productos y servicios similares... El objetivo es documentar el problema a tratar en base a la investigación que hayan hecho otros y recabar toda la información posible sobre el contexto, competencia, mercado... * Encuestas. Realizar una serie de encuestas a usuarios nos permitirá extraer información sobre nuestro producto. Son especialmente útiles a la hora de medir grupos grandes de población. Es importante no lanzar preguntas demasiado directas ni pedir juicios de valor ya que los sesgos que se ejercen suelen inclinar la respuesta hacia la complacencia. En general, es recomendable tipificar la mayoría de las preguntas en caso de que la muestra sea grande, dejando las preguntas abiertas para muestras pequeñas. * Entrevistas. Si queremos información cualitativa unas pocas entrevistas serán mucho más valiosas que un gran número de encuestas. De nuevo, es clave no coaccionar a nuestros usuarios con preguntas demasiado cerradas. La clave es generar un ambiente cómodo donde los entrevistados se sientan libres de expresarse sin ser juzgados, adoptando el entrevistador un papel pasivo como mero facilitador. Es también de gran valor realizar entrevistas a miembros clave de la organización. ### **2.8 Extraer conclusiones** Las conclusiones que extraigamos pueden ser representadas de muchas formas. Destacamos dos por ser de los más habituales en diseño producto. * Customer Journey. Muestra de forma visual el proceso que sigue un usuario durante el uso de nuestro producto o servicio. Interpreta lo que espera conseguir y cómo se siente durante el proceso con especial atención a aquellos puntos donde se genera frustración. Permite señalar aquellos procesos que provocan fricción y donde es posible una mejoría. Es ideal establecer estos journeys en base a información real. * User Personas. Existen dos tipos, protopersonas, si la información de base es inventada, y personas, si las estamos realizando en base a información real extraida previamente. Se trata de componer una personalidad realista de usuarios del producto. Nos permite destacar cuales son sus necesidades, frustraciones, gustos, herramientas... para así atacar el diseño desde la óptica adecuada. * Otros documentos tales como benchmark, investigación de mercado... {% hint style="info" %} No olvidemos documentar todos los resultados de cada fase en Notion. 👉 En [**Notion**](/tools/notion) puedes conocer más sobre cómo creamos y documentamos un proyecto {% endhint %} ## 3. Definición Durante la fase de definición, sentaremos las bases de lo que será nuestro producto o marca. En esta etapa, se debe restar toda la complejidad posible para convertir un montón de documentos, gráficas, apuntes y anotaciones en una entidad de consumo. **Los objetivos de la fase de definición son los siguientes:** * Restar complejidad al producto o marca. Esto puede incluir la definición de una nomenclatura transversal a los equipos. * Generar aquella narrativa que nos permita sostener nuestro discurso. * Cumplir con todos los objetivos marcados a alto nivel. No se trata de decir cómo será el campo de formulario concreto que vamos a medir, pero sí pensar en aquellas secciones o módulos que cumplan funciones y objetivos concretos. * Construir la arquitectura de información que será el esqueleto de nuestro producto. * Establecer una jerarquía realista de qué funcionalidades conformarán la siguiente release o MVP y por qué. * Convertir lo abstracto en concreto. ### 3.1 Ideación El objetivo de esta fase es definir y concretar las funcionalidades del producto, las cuales han de estar alineadas con las necesidades de nuestros usuarios. Una vez hemos validado y entendido el problema, empezamos a buscar soluciones. Cuantas más mejor. Priorizando la cantidad antes que la calidad. En esta fase, exploramos ideas que trascienden de la solución "obvia". Tratamos de generar muchas ideas antes de empezar con el proceso de seleccionar y desarrollar conceptos concretos. Realizamos un trabajo de divergencia para posteriormente converger. Las historias de usuario son un buen ejercicio que nos ayuda en esta fase a encontrar funcionalidades desde el punto de vista de nuestros usuarios, teniendo en cuenta sus frustraciones, problemas, objetivos y motivaciones. **Las historias de usuario:** * Nos dan contexto sobre el problema. * Nos ayudan a estar centrados en buscar soluciones para nuestros usuarios, empatizando con ellos. * Nos permiten diferenciar fácilmente entre los distintos tipos de consumidores de nuestro producto. * Nos ayudan a detectar funcionalidades. Para realizar historias de usuario utilizamos el siguiente esqueleto, teniendo en cuenta la necesidad que tiene el usuario y valor que le aporta suplir dicha necesidad. {% hint style="info" %} **Como \_\_\_\_\_\_\_\_\_\_\_ quiero \_\_\_\_\_\_\_\_\_\_\_ para \_\_\_\_\_\_\_\_\_\_\_ .** **En una aplicación de un supermercado, un ejemplo podría ser:**\ "Como cliente recurrente quiero poder buscar entre mis pedidos anteriores para realizarlos de nuevo de forma rápida." **La funcionalidad que derivaría de esta historia de usuario sería:**\ Tener una lista de pedidos realizados dentro de su perfil para poder repetir estos siempre que el usuario quiera. {% endhint %} Al realizar las historias de usuario no buscamos definir cómo va a ser la solución que satisfaga las necesidades de éste, sino únicamente detallar las funcionalidades que permiten solucionar el problema detectado. Es importante el constante feedback de los *stakeholders* y del equipo del cliente. ### 3.2 Arquitectura de contenido **Una vez tenemos claro qué** queremos hacer, **pasaremos a definir el cómo**. Antes de pensar en soluciones gráficas debemos organizar la complejidad a la que nos enfrentamos para hacerla digerible. Se trata de decidir cuál es el contenido idóneo y cuál va a ser la estructura para mostrarlo, organizando la información disponible mediante mapas conceptuales, árboles de contenido y flujos. **Realizar una arquitectura de información nos permite:** * Identificar y jerarquizar los componentes que estarán presentes en la app o web en la que estemos trabajando. * Organizar, estructurar y nombrar componentes de una forma efectiva y sostenible a lo largo del proyecto. * Identificar KPI's y darles la importancia que requieren. * Tomar decisiones de contenido de alto nivel de forma rápida, reflexionando en abstracto sobre el orden y pertenencia de secciones y objetivos funcionales. La arquitectura de contenido en su bajada a branding incluye la detección de todos los diferentes touchpoint de la marca y cómo el usuario interactúa con los mismos. ### 3.3 **Mapas conceptuales** Realizamos mapas conceptuales para organizar información de diversa índole. Se puede utilizar para organizar datos en una tabla, distribuir secciones de un producto, organizar contenidos de una sección o incluso para reorganizar las ya existentes probando diferentes disposiciones. La principal función de un mapa conceptual es **agrupar** contenido. **Los mapas conceptuales nos permiten:** * Ver de un vistazo todo el contenido que va a haber en un grupo temático. * Ordenar y comprender bloques, dando sentido a la información. * Jerarquizar y descartar. **En un mapa conceptual distinguimos entre las siguientes jerarquías:** 1. KPI: acción o contenido más importante. 2. Actions: acciones de importancia secundaria. 3. Notes: componentes que tienen una función principal. 4. Secondary notes: módulos y componentes de información de apoyo. Realizar un mapa conceptual es tan sencillo como recopilar todos los bloques de información que tenemos que organizar y disponerlos en un orden lógico en un eje horizontal o vertical. Es muy importante usar algún código para jerarquizar los distintos bloques según su importancia. Una vez tengamos varios bloques conceptuales, podemos establecer relaciones mayores organizando en un segundo paso los grupos entre sí. Una evolución lógica de un mapa conceptual podría ser un árbol de contenidos. {% hint style="info" %} **💡** Para realizar los mapas conceptuales fácilmente puedes utilizar la librería **concept maps systems**. 📎 [concept maps system.sketch](https://github.com/mendesaltaren/product-design-handbook/raw/master/assets/sketch/concept-maps-system.sketch) {% endhint %} ### 3.4 Árbol de contenido Un árbol de contenido se parece a un mapa conceptual pero tiene varias secciones y ramificaciones. Sirve para organizar y establecer las agrupaciones y dependencias de un producto digital. Es siempre de gran utilidad e imprescindible cuando creamos un proyecto desde cero o cuando el proyecto cuente con mucha información y contenido, y sea necesario llevar a cabo una reestructuración de éste. Un árbol de contenido muestra restricciones entre las páginas de la app o web y permite documentar la organización y navegación de ésta. {% hint style="warning" %} Es importante no confundir un *árbol de contenido* con un *flujo*. Un *árbol de contenido* refleja las páginas y en qué nivel se encuentran éstas, pero no refejan el orden ni las distintas casuísticas según la interacción de los usuarios. {% endhint %} Un proceso de trabajo de un árbol de contenido tipo, partiendo de unos mapas conceptuales, podría describirse así: 1. Organizar todos los bloques identificados en los mapas conceptuales en una estructura global. Esta estructura debe considerar los distintos niveles de navegación (primario, secundario, etc.). No es necesario tener presentes todos los bloques que conforman los mapas conceptuales, solamente identificarlos. 2. Organizar el contenido en páginas distintas. {% hint style="info" %} **💡** Para realizar un árbol de contenido se puede utilizar la librería de Sketch **flowchart system.** [flowchart systems.sketch](https://github.com/mendesaltaren/product-design-handbook/raw/master/assets/sketch/flowchart-systems.sketch) {% endhint %} ### 3.5 **Flujos** Los flujos muestran **cómo interactúa un usuario** con un producto o servicio, mostrando diferentes caminos en función de la interacción de los usuarios. Permiten detectar *pain points* en los distintos *funnels* de la app o web, así como reflexionar en abstracto y tomar decisiones sobre las diferentes casuísticas y opciones de uso de un servicio o producto. {% hint style="warning" %} Los flujos se pueden realizar a lo largo de toda la etapa de definición y serán siempre útiles. Antes de realizar los wireframes es importante tener creado un flujo para validar con el cliente la navegación y estructura de la app o web. {% endhint %} Existe una convención estándar para la realización de flujos denominada "flowchart system". Es muy sencilla y conocerla nos permitirá realizar flujos legibles por multitud de perfiles. Esta convención puede ser adaptada a cualquier producto o servicio. Recomendamos usar el archivo adjunto, realizado por nosotros, para la creación de tus flujos. {% hint style="info" %} **💡** Para preparar tus flujos se puede utilizar la librería de Sketch **flowchart system.** [flowchart systems.sketch](https://github.com/mendesaltaren/product-design-handbook/raw/master/assets/sketch/flowchart-systems.sketch) {% endhint %} ### 3.6 Componentización Durante la componentización ponemos en relieve todos los módulos que conforman nuestro producto final y/o todas las piezas que forman parte de una marca. La idea es encontrar patrones que nos permitan resolver todos los problemas que se nos plantean con el número mínimo posible de soluciones. Dependiendo del punto de partida del proyecto esta labor puede realizarse, bien separando en componentes todo el producto del que partimos, o bien partiendo de lo que vayamos generando durante la fase de wireframing. Una forma de hacerlo podría ser separando todos los módulos de un wireframe de baja fidelidad, de manera que podamos identificar qué objetivos y problemas resuelven cada uno de ellos, con la idea de encontrar patrones que nos permitan reducir al mínimo las soluciones de diseño, encontrando formas versátiles de resolver dichos problemas. Más que una herramienta propiamente dicha, la componentización es una forma de pensar que nos permite simplificar un producto o marca en cualquiera de sus fases. ### 3.7 Conceptualización **Concepto** Representación mental de un objeto, hecho, cualidad, situación, etc. Conceptualizar es la única forma que entendemos de dotar de alma un producto. Un concepto es la base sobre la que se articula su narrativa. Conceptualizar es absolutamente imprescindible en un trabajo de Branding. Sin un concepto sólido sobre el que apoyarnos una marca será frágil y dificilmente reflejará los objetivos que se persiguen a nivel estratégico, ya que estará desnuda a la hora de encontrar maneras de abordarlos. Es importante tratar de ser simples en cuanto a un concepto. Un error habitual es tratar de ser rebuscados. Suele desembocar en una incapacidad posterior de expresar dicho concepto en recursos gráficos o narrativos. Una obviedad bien llevada puede ser un valor seguro a la hora de conceptualizar. Durante el proceso de crear, ya sea una marca, producto o cualquier otra pieza, hemos de ser conscientes de que partimos de un lugar alejado del mundo de las ideas. Si conseguimos asociar el trabajo que realicemos con alguna de esas ideas, el público podrá asimilar aquellos valores o adjetivos que pretendemos expresar. Solo siendo conscientes de esa limitación podremos darnos cuenta del esfuerzo que conlleva que nuestro trabajo se identifique con un concepto claro. Es común que la conceptualización quede escorada en trabajos de producto digital puro y duro. Pero si trabajamos en base a un concepto, dotaremos a nuestro producto de un hilo conductor. Y dicho hilo conductor puede verse reflejado desde una splash screen hasta el último copy de un botón. Para no limitarnos y ampliar la riqueza narrativa de una marca, solemos trabajar con dos tipos de conceptos complementarios: narrativos y gráficos. **Concepto narrativo** Un concepto narrativo articula el lenguaje de un producto o marca. Por ejemplo, si el concepto narrativo fuera "esfuerzo", podríamos usar expresiones donde se pone en valor la dificultad o lo arduo de llevar a cabo una acción. **Concepto gráfico** Un concepto gráfico debe permitirnos encontrar recursos visuales simples que apoyen la narración. Partiendo del ejemplo anterior, para complementar "esfuerzo" podríamos buscar el concepto de "tensión" visual. Esto nos permitiría usar, p.e., geometrías estiradas, a punto de colapsar, o en escorzo. Una forma interesante y práctica de testear las posibilidades de expresión de nuestro concepto sería usar la siguiente fórmula: {% hint style="info" %} **Si nuestro concepto es \_\_\_\_\_\_\_\_, nuestros recursos gráficos serán/estarán \_\_\_\_\_\_\_\_.** {% endhint %} Y continuando con el ejemplo anterior: Si nuestro concepto es **esfuerzo**, nuestros recursos gráficos estarán en **tensión**. ## 4. Producción Este es un punto clave dentro del proceso. En él vamos a **materializar la propuesta de valor** que hemos estado gestando en los pasos previos. A estas alturas del proceso, las funcionalidades del producto deben estar ya acotadas. Haber hecho un buen trabajo anteriormente y tener las ideas claras, se traducirá en una una mayor velocidad y fluidez en el desarrollo de esta fase. Para proceder a la producción del producto, trabajaremos de lo más abstracto y general a lo más concreto y particular. A grandes rasgos, los pasos de esta fase serían: *wireframing* → prototipado → diseño. Pasamos a explicar cada uno de ellos. ### 4.1 Wireframing Un *wireframe* es un **boceto** donde se representa visualmente y de forma **esquemática** la estructura de un producto digital o de alguna de sus partes. Son realmente útiles para validar las ideas e hipótesis con el cliente y realizar iteraciones sobre nuestras teorías. Estos bocetos pueden hacerse indistintamente a mano o de forma digital. Lo importante es mantenerse alejado de los acabados visuales finales, pues sería una pérdida de tiempo preocuparse de ellos en este estadio. El **objetivo de la fase** de *wireframing* es definir desde el flujo de navegación y los bloques de contenido del producto, hasta la posición y el funcionamiento de los distintos componentes que los formarán. Para ello, delimitamos dos tipos de *wireframes*: * **Lo-fi**. Como diseñadores, son nuestro punto de partida para traducir la propuesta de valor en un *layout*. Deben proporcionarnos una imagen muy sencilla de cómo se va a estructurar la información a nivel general. Se trabaja en base a bloques que cumplen objetivos, sin ahondar en como funciona cada bloque por dentro. Sirven para validar la distintos módulos que conformarán cada sección, las relaciones entre ellos, reducir al mínimo el número de componentes, y generar una estructura bien definida de forma rápida. * **Hi-fi**. Los wireframes en alta son la evolución natural en la cual empezamos a ver cómo funciona cada módulo y componente. La idea es validar la funcionalidad final del producto antes de preocuparnos por el visual. {% hint style="info" %} **💡 Tip**: Para crear los wireframes utilizamos la librería **wireframes system**. ​[wireframes system.sketch](https://github.com/mendesaltaren/product-design-handbook/raw/master/assets/sketch/wireframe-system.sketch) {% endhint %} ### 4.2 Prototipado Prototipar proporciona la versatilidad de poder testar el producto con usuarios en etapas tempranas y detectar problemas a nivel de navegación y contenido. Cuando hablamos de prototipo nos referimos a: diseños en mayor o menor medida cercanos en fidelidad al producto final, que nos permiten interactuar con las funcionalidades que proponemos. **El prototipo permite:** * Entender y experimentar la navegación de un manera visual. * **Validar con el cliente** la estructura de contenido, componentes y módulos que irán finalmente en cada página. El prototipo proporciona una idea rápida y fiel al cliente de cómo será el producto final. * **Testar con los usuarios** la estructura de contenido, componentes y módulos que irán finalmente en cada página. * **Validar con el equipo de desarrollo** que se va a encargar posteriormente de la implementación. El prototipo tiene que dejar clara la propuesta de valor y proponer la solución a los problemas planteados. ### 4.3 **User tests** Como hemos mencionado, es muy interesante testear el prototipo con usuarios para obtener ***insights*** cuanto antes. Este testeo con usuarios nos permite ver si realmente se ha resuelto el problema planteado satisfactoriamente. Al igual que ocurre con las entrevistas o encuestas, es de suma importancia tratar de sesgar lo mínimo a los usuarios. Preguntar por su opinión sobre el trabajo o pedirles valoraciones y juicios solo traerá respuestas complacientes y poco críticas. La clave es plantearles problemas reales y observar si los resuelven y cómo. Es vital ejercer de facilitador y no de guía, así como manejar el entorno para que se sientan cómodos: lo ideal es que usen el producto en un entorno lo más parecido a la realidad para no sesgarles. {% hint style="info" %} Para poder testar con usuarios es necesario tener un ***checklist*** **de tareas** **a completar por los mismos. En la sesión en la que se realice el testeo,** es recomendable recordarle al usuario que no se le está juzgando a él, sino a la aplicación o web con el objetivo de mejorar. Se le comentará también cuáles son las tareas que debe completar. Cuando se complete una tarea la marcaremos en el *checklist*, esto nos servirá de guía para ver si el problema se ha resuelto con éxito o es necesario iterar sobre él. {% endhint %} ### 4.4 Moodboard Un *moodboard* nos es de gran ayuda en los primeros estadios de la exploración visual de un producto o marca. Nos permite traducir a un lenguaje visual **conceptos e ideas complejas** que aparecen reiteradamente ligadas al producto durante el proceso de definición. También es una buena forma de **trasladar al cliente nuestra visión** sobre su producto o marca para que ambos estemos alineados en ese sentido. Este *moodboard* debe ser **evocador**, pues nos servirá como punto de partida inspiracional. Normalmente preferimos no centrarnos únicamente en referencias directamente relacionadas con lo que podríamos entender por diseño gráfico e interfaces. El arte plástico, la fotografía, la arquitectura, la escultura y, en general, cualquier campo relacionado con la representación de ideas y conceptos, son buenos puntos de partida para buscar inspiración. **Es importante que tu** ***moodboard*** **sea conciso**. Una posibilidad muy interesante, es la de crear pequeñas secciones centradas en aspectos concretos como el color, la forma, la textura, la tipografía, el tono comunicacional, etc. De este modo, maximizamos la potencia evocativa de la combinación de imágenes, evitando que se diluya en un mar de elementos visuales luchando por el protagonismo. ![Vista de ejemplo del tipo de moodboards que utilizamos en nuestras presentaciones](/files/-MiLrytKqytpo2EDk9DY) ### 4.5 Branding El branding, junto al diseño de producto, es uno de los servicios más importantes que ofrecemos en el estudio. Son, de hecho, prácticamente indivisibles. No se puede entender un producto sin su marca ni al contrario. No es una fase como tal, ya que en un proyecto ideal la marca se desarrollaría paralelamente a muchas de las fases ya tratadas, bebiendo de algunas de ellas (entendimiento, definición, conceptualización o componentización) y alimentando otras (producción, diseño visual, narrativa). Es por todo esto que hemos decidido crear una sección específica para realizar una breve introducción al proceso que seguimos para la creación de marca en el estudio. {% hint style="info" %} 👉 Consulta una introducción a nuestro proceso de [**branding**](/branding). {% endhint %} ### 4.6 Diseño visual Una vez hemos definido y testado todos los aspectos funcionales y estructurales de un producto digital, llega el momento de dotar a estos de unos acabados visuales finales que nos ayuden a potenciar una **buena experiencia de usuario**. > "El buen diseño es estético" > > – Dieter Rams En sus 10 principios del buen diseño, Dieter Rams argumenta que **la calidad estética de un producto es parte integral de su utilidad**. Desde nuestro punto de vista, entre usuario y producto se establece una relación de uso que puede ser análoga a la que se crea en arquitectura entre edificios y personas. Del mismo modo que recorrer una construcción agradable repercute en nuestro bienestar y estado de ánimo, utilizar un producto digital creado de forma armoniosa, beneficia a esta relación establecida entre usuario y producto. Habitualmente, los elementos y códigos visuales de los que necesitamos hacer uso cuando creamos un producto digital, se enmarcan dentro de un contexto determinado: tienen que representar a una marca. Por ello, una parte importante de esta fase es la relativa a delimitar un ecosistema que los englobe. Este ecosistema es la **identidad de marca** o ***branding***. Antes de materializar el producto a un nivel visual final, y aunque ya tengamos definidas las funcionalidades del producto, será imprescindible concretar esa identidad de marca. Este proceso es de cierto modo independiente al de desarrollo de producto. Por eso, en este punto definimos todo el proceso de [*branding*](/branding). Con la identidad de marca ya definida, podremos pasar a desarrollar el **sistema de diseño**. En él estableceremos unos **patrones** que facilitarán el uso de elementos comunes de forma recurrente, potenciando la recursividad. definiremos unas **reglas** que articularán el uso del mismo y también sentaremos las bases de un **lenguaje claro y consistente**, a partir del que crear y desarrollar productos. En este otro punto desarrollamos en profundidad todo lo relativo al [sistema de diseño](/design-systems). {% hint style="info" %} 👉 Consulta una introducción a nuestro proceso de [**branding**](/branding). {% endhint %} {% hint style="info" %} 👉 Consulta una nuestra aproximación a los [**sistemas de diseño**](/design-systems). {% endhint %} ## 5. Entrega Los resultados de cada parte del proceso deben compartirse con el cliente y su equipo a medida que se van realizando. Esto elimina la incertidumbre y permite que el proyecto vaya avanzando y el feedback se aplique a su debido tiempo, evitando tener que rehacer partes enteras. Dándole acceso a nuestros clientes a [Abstract](/tools/abstract) (o [Figma](/tools/figma) en su caso) o compartiendo avances poco a poco en herramientas como InVision o Marvel permitirá que los clientes puedan ver qué se está haciendo, añadir comentarios y dar *feedback* sobre el trabajo. Trabajar con transparencia agiliza el proyecto haciendo a los stakeholders partícipes de todos los avances. ### 5.1 Cómo y qué entregar La mejor forma de entregar un proyecto es un link a la carpeta de Google Drive o Dropbox donde tengamos el entregable. Esto nos evitará, en el caso de que hubiera cualquier modificación, tener que enviar de nuevo archivos comprimidos, o subirlo a plataformas como Wetransfer. Es de suma importancia que el cliente comprenda qué, pese a estar cerrado, es posible corregir posteriormente cualquier error que hayamos cometido. ### 5.2 Organización A la hora de preparar un proyecto entregable es muy importante establecer una organización que el cliente pueda entender a través de convenciones. Se debe seleccionar aquellos archivos que sean valiosos para el cliente, no olvidando en ningún caso aquellos que hayan sido definidos como mandatory por el cliente en la fase de preparación. Creamos una estuctura de carpetas dentro de la carpeta "deliverables" con todos los recursos acordados con el cliente. Será esta subcarpeta la que compartiremos con el cliente. {% hint style="info" %} Los entregables del proyecto serán aquellos definidos previamente con el cliente y estarán en todo momento documentados en Notion. {% endhint %} **¿Cómo preparar archivos de sketch para entregar?** 1. Mergear todas las posibles ramas que haya en el proyecto de Abstract a la rama *Master*. 2. Exportar los archivos de la rama *Master*. 3. Guardarlos en Dropbox {% hint style="info" %} ✏️ Consulta la documentacion sobre como usamos Abstract más en el apartado de [Abstract](/tools/abstract). {% endhint %} ### 5.3 Handoff Para trasladar el diseño a desarrollo, utilizamos [Zeplin](/tools/zeplin). Nos permite reducir el gap entre diseño y desarrollo, facilitando la implementación de del diseño. Únicamente subimos a Zeplin aquellos archivos que estén en la rama *Master* de Abstract, para tener un control de qué se sube. {% hint style="info" %} 👉 Si quieres saber más sobre cómo preparar tus archivos para el handoff puedes consultar el artículo sobre [Zeplin](/tools/zeplin). {% endhint %} ## 6. Seguimiento ### 6.1 Formación Una vez acabado el proyecto, se realizan sesiones de formación con cliente. En estas sesiones, se traslada el conocimiento adquirido a lo largo del proceso al cliente. Formamos al cliente para darle a conocer el alcance que tiene el sistema de diseño creado y el trabajar en base a componentes para que su producto sea escalable, mantenible y consistente en el tiempo. ### 6.2 Soporte Al realizar la entrega del proyecto, realizamos un seguimiento con el equipo de front-end que desarrollará el proyecto. Gracias a este soporte podremos asegurar que cualquier duda que pueda surgir quede resuelta. En caso de darse alguna complicación con respecto al diseño, se buscan vías para proporcionar una solución mediante este. ### 6.3 Valoración interna Cuando se entrega un proyecto, el responsable y los miembros del equipo que han formado parte de él realizan una retrospectiva del proyecto. En esta reunión, se analizará qué ha salido bien y qué puntos del proyecto se pueden mejorar, de cara a siguientes proyectos. Este conocimiento adquirido se traslada al resto del equipo, para que el aprendizaje se vea reflejado en todos los proyectos del estudio. A los tres meses de la entrega de un proyecto, nos ponemos en contacto con el cliente para ver cómo está funcionando el producto, obtener métricas y poder compararlas, si se tuvieran al inicio del proyecto. Gracias a obtener esta información podremos analizar qué ha funcionado a nivel de producto, y cómo nuestro trabajo ha contribuido a ello. Realizar una retrospectiva en este punto fomenta la mejora de los proyectos futuros. # 3. Branding El *branding* es, en la mayoría de los casos, **inherente al diseño de producto**. Sin embargo, su proceso de definición, se solapa en ciertos momentos con el de creación del producto. En ocasiones incluso es un proceso que transcurre en paralelo. Por ello, hemos querido dedicarle un apartado propio en el que cubrimos de manera independiente los pasos que creemos que se deben de seguir para llegar a buen puerto. Puesto que cada proyecto tiene unas características, en función de las necesidades del cliente, los tres escenarios que se pueden distinguir son: * El cliente cuenta con un *branding* depurado. * El cliente necesita un rediseño. * El cliente necesita un *branding* nuevo. ## **El cliente cuenta con un** ***branding*** **depurado** Este cliente tiene una marca consolidada. Lo único que hay que hacer es adaptar los nuevos componentes que aparezcan en el proyecto a su lenguaje gráfico. ## **El cliente necesita un rediseño** Al enfrentarnos a un rediseño, el proceso será igual al de realizar un *branding* desde cero, con la particularidad de que tendremos que identificar los problemas que arrastra la marca. En el siguiente apartado definiremos todo el proceso. ## **El cliente necesita un** ***branding*** **nuevo** Este escenario es el más completo, por lo que es el que vamos a desarrollar. Requiere de una visión general del proyecto y consta de 3 fases. ### 1. Toma de contacto Investigar al cliente, su producto, sus principios y sus valores para entender su marca. Detectar qué puede necesitar y fijar una estrategia. Este punto es especialmente importante. **Sentar unas buenas bases** establece una relación sana con el cliente y ayuda a tomar decisiones con fundamento y de forma ágil. **1.1. Antes de la primera reunión:** Investiga al cliente y sus perfiles internos. Genera una idea previa de lo que va a querer/necesitar en base a los *insights* adquiridos de los **problemas** identificados. **1.2. Durante la reunión:** * Escucha activamente en base a la investigación realizada. * Sé proactivo. Propón vías para saber cómo respira el cliente. * Crea un ambiente distendido y de entendimiento. Somos su aliado. * Genera confianza: explica el proceso al cliente hará que todo salga bien. **1.3. Tras la reunión:** * Gestiona las expectativas del cliente. * Checklist de necesidades. Debes mandar un mail al cliente para que valide las necesidades establecidas. ### 2. Investigación y plataforma de marca Tras la toma de contacto, es momento de **investigar sobre el mercado** de nuestro cliente con la intención de identificar competidores y referentes. Por otra parte, es importante que en este punto hagamos con él una **reflexión sobre su marca**, su propuesta de valor, y qué mensaje quiere transmitir. Para esto último, le facilitamos un documento que le guíe en ese proceso de reflexión: el [*Brand Strategy Brief*](https://www.notion.so/mendesaltaren/Brand-Strategy-Brief-V2-58f760341b144236baa58303c11e2e83). Con todo lo recogido en esta etapa se debe realizar una propuesta al cliente. Estos son los pasos a seguir: **2.1. Benchmark.** * Busca referentes que ofrezcan servicios similares a los del cliente y analízalos para extraer conclusiones sobre buenas prácticas y patrones de la industria a la que pertenece. **2.2. El cliente completa el *****Brand Strategy Brief.*** * Facilítale acceso a una copia en blanco del documento a través de Notion. * Explícale la dinámica y el objetivo de este ejercicio. Insiste en la importancia del mismo para que podamos obtener información de calidad a través de él. **2.3. Realizamos una lectura crítica del *****Brand Strategy Brief***** con el cliente.** * Revisa el ejercicio con el cliente. De este modo podrás entender en toda su dimensión las respuestas que ha dado. Es interesante identificar aquellos puntos que no entendió o le causaron dudas para, de forma colaborativa, dar respuesta a esas preguntas. **2.4. Primera presentación/puesta en común.** * Genera una presentación con las claves de toda esta fase. Incluye: punto de partida, necesidades, piezas a realizar, plataforma de marca y *benchmark*. * Haz un resumen y llega a un acuerdo consensuado con el cliente. ### 3. Exploración gráfica y concepto Buscar referentes que ayuden a traducir toda la información y conocimiento adquirido a un **lenguaje gráfico**. En esta etapa se debe invertir todo el tiempo que sea necesario. Para empezar a diseñar se deben tener las ideas claras y para llegar a ello es necesario investigar y buscar referencias. **3.1. Investigación:** * Busca referencias y prepara un *moodboard*. * Piensa en 2 conceptos globales que aglutinen todo lo que la marca necesite. * Piensa en cómo materializar el concepto gráfica y narrativamente. * Piensa en titulares y *copies* que expresen los valores que transmite la marca. Ten en cuenta su tono y personalidad. **3.2. Segunda presentación / puesta en común.** * Llega a un consenso de referencias gráficas y **conceptuales**. **3.3. Producción gráfica. Crea 1 o 2 líneas gráficas en base a:** * Identificador primario. * Identificadores secundarios. * Paleta cromática. * Tipografía principal y auxiliar. * Crea aplicaciones de marca para testar el funcionamiento de la línea gráfica. Papelería básica, piezas digitales, conceptuales, de comunicación, etc. **3.4. Tercera presentación / puesta en común.** * Presenta la identidad con un resumen de las fases anteriores. * El cliente debe seleccionar la vía elegida. ### 4. Producción de AAFF y *brandbook* Tener unos entregables bien estructurados y documentados ayuda al cliente a manejar su marca de forma autónoma una vez finalice el proyecto. Durante esta etapa, es necesario realizar: **4.1.** ***Brandbook*****.** Prepara un documento que explique detalladamente qué elementos componen la marca, cómo deben usarse y en qué contextos. Al menos debe constar de: * Introducción e índice. * Identidad: logotipo, tipografía y paleta de color. * Uso de marca: espacio de seguridad, tamaños mínimos, uso del color, uso de las fotografía, recursos visuales, etc. * Elementos de marca tales como: papelería, pegatinas, ilustraciones, etc. * Aplicaciones *online*: firmas de email, redes sociales, *landing*, etc. **4.2. Producción** * Realiza todos los materiales acordados con el cliente. Por ejemplo, tendrás que exportar el logotipo en sus diferentes versiones en todos los formatos que puedan ser requeridos (AI, SVG, EPS, PNG, JPG, PDF). * Prepara los materiales para imprenta, si el proyecto los requiere. **4.3. Entrega final.** * Agrupa y estructura en carpetas todos los archivos producidos y guarda el empaquetado en la carpeta ***04\_deliverables*** del proyecto correspondiente en Dropbox. # 4. Sistemas de diseño Esta es la herramienta central en torno a la que gira nuestra metodología. Por ello, hemos creído oportuno dedicar un capítulo entero a explicar: **qué entendemos por sistema** de diseño, **qué principios** de diseño nos guían a la hora gestionarlo, y **qué elementos** componen nuestros sistemas a nivel morfológico. ## 1. ¿Qué es un sistema de diseño? Esta herramienta permite al equipo **establecer patrones** y contar con una serie de elementos que se pueden, y deben, reutilizar para crear funcionalidades. La **modularidad** del sistema es lo que permite crear desde una unidad mínima hasta componentes más complejos. Establece **reglas** que nos ayudan a trabajar en equipo de forma alineada a través de principios. Además, el sistema de diseño refleja el punto de unión entre el equipo de diseño y el de desarrollo. Gracias a él, conseguimos implementar un l**enguaje claro y consistente** a partir del cual crear y evolucionar productos. **Un sistema de diseño podría entenderse como:** * Un lenguaje común. * Una balanza entre el control estricto y el caos que produce la libertad. * Una colección de elementos reutilizables guiados por una documentación clara. * Un conjunto de patrones y prácticas que se comparten dentro de un equipo de forma coherente y organizada. Cada patrón describe un problema que ocurre con frecuencia y describe y propone una solución para este. El sistema de diseño tiene que ser flexible y mantenerse vivo a largo plazo. Un sistema de diseño no es estático, sino dinámico. Evoluciona con el producto y su diseño. ### 1.1 ¿Qué valor aporta? Utilizar un sistema de diseño garantiza la **consistencia** de nuestros productos. Esto repercute de manera positiva en la experiencia del usuario y acorta significativamente los tiempos de ideación, desarrollo y elaboración de productos. Por otra parte, los sistemas de diseño son una herramienta especialmente útil para conseguir crear productos digitales capaces de **escalar y crecer** rápidamente de una forma controlada. Por último, pero no menos importante, un valor que aporta es que permite dedicar menos tiempo a pensar en detalles superfluos y más a pensar en producto. Si bien presenta algunas similitudes, el sistema de diseño no es ni un manual de marca ni una guía de estilos, ni sustituto de los mismos. Puede convivir con ellos y cada uno aporta valores distintos. La principal diferencia, es que el sistema de diseño no es un documento estático de consulta que se limita a explicar cómo debe ser el aspecto de los elementos. Como ya hemos mencionado, el sistema de diseño es una entidad viva que contiene un lenguaje común, principios y herramientas que ayudan a construir productos coherentes. ## 2. **Principios** A la hora de tomar decisiones relacionadas con la gestión de sistemas de diseño, nos guiamos por una serie de **principios** que compartimos todos los miembros del equipo. Gracias a ellos conseguimos sentar las bases de lo que consideramos un buen producto. En nuestra opinión, el diseño de sistemas debe ser: * **Sistémico.** El diseño visual se sirve de patrones y reutiliza elementos. Esto da coherencia y cohesión al producto y agiliza los procesos de creación y mantenimiento. * **Reticular.** El diseño debe utilizar un sistema de proporciones definido, para armonizar y organizar el conjunto. * **Racional.** El diseño visual se debe basar en decisiones lógicas y razonadas. * **Estético.** La calidad estética del diseño repercute directamente en la utilidad y usabilidad de los productos. * **Comprensible.** Nuestro reto es realizar productos autoexplicativos. Estos principios tienen también una influencia clara a lo largo de nuestro proceso productivo. ### 2.1 Principios específicos Más allá de las reglas generales que nos sirven como premisa a la hora de utilizar un sistema de diseño, también dotamos a cada uno de una serie de **principios particulares**. Estos tienen el fin de proporcionar una personalidad única y propia al sistema. Por ejemplo, un sistema de diseño para una entidad pública podría establecer como principio la imparcialidad. Quien maneje este sistema debería ceñirse a esta máxima a la hora de crear funcionalidades que no influencien la toma de decisiones del usuario. ## 3. **Estilos** ### 3.1 Color El color es un elemento muy importante de la comunicación visual, por ello, es necesario hacer un **uso inteligente e intencional** del mismo. A la hora de crear sistemas de diseño distinguimos los siguientes tipos de colores: *\*\** * **De marca.** Colores normalmente asociados al *branding*, que definen y dan personalidad a la marca del producto*.* La función principal de estos colores es acentuar*.* *Todos los colores primarios se agruparan en la paleta primaria.* * **Complementarios.** Grupos de colores con la riqueza suficiente como para funcionar a la hora de crear aplicaciones tales como ilustraciones, fotografías o generar colores de fondo. *Todos los colores secundarios definidos se agruparan en la paleta secundaria.* * **Tipográficos.** Como mínimo se deben establecer un color oscuro y otro claro para utilizar en la tipografía. También se pueden establecer otros estilos de texto que tengan un color distinto a los mencionados. *Todos los colores tipográficos se agruparan en la paleta secundaria, excepto cuando el color del texto corresponda con algún color primario.* ### 3.2 Layout Para organizar el espacio **nos servimos de la retícula o \*grid**.\* Esta es una herramienta de trabajo que nos ayuda a distribuir los elementos documentados en el sistema de diseño. Se debe utilizar de forma estructurada para crear los componentes funcionales que articularán el producto. Esta retícula debe definirse matemáticamente proporcionando, así, las reglas que definen el tamaño y la posición de los elementos colocados sobre ella. De este modo, acotamos las posibilidades y agilizamos la toma de decisiones en base a un armonioso sistema de medidas proporcionales. En nuestro caso, establecemos dos **variables que definen la retícula**: * **Columnas**. Nos ayudan a estructurar el espacio **horizontalmente**. En función de las necesidades del proyecto, suele establecerse un número par de columnas entre 2 y 12. Es necesario establecer: el ancho de cada columna, el espacio entre estas, y el margen del grupo de columnas respecto a los bordes. * **Línea base**. Sirve para organizar el espacio **verticalmente**. Debe ser equivalente a la altura del interlineado del cuerpo de texto principal. De este modo, todos los elementos estarán alineados al mismo y transmitiremos sensación de orden. ### 3.3 **Regla del 8** Si bien la unidad mínima de una retícula digital es el píxel individual, nuestro sistema se basará en una cuadrícula de **incrementos verticales y horizontales de 8 píxeles**. Debido a la importancia que tiene para nosotros esta forma de organizar la retícula, hemos decidido dedicarle su propio apartado. Cada medida de la página debe ser múltiplo de 8. Eso incluye tanto anchos de columna, márgenes, textos, iconos, imágenes, etc. Sólo procediendo rigurosamente de esta manera lograremos que todos los elementos estén perfectamente alineados. Al aplicar la regla del 8 a la **tipografía**, hacemos una excepción y nos tomamos la licencia de establecer la línea base en múltiplos de 4. De este modo ganamos versatilidad a la hora de establecer interlineados acordes al tamaño de la tipografía que generen una mancha de texto cómoda de leer. Por ejemplo, si nos ceñimos a múltiplos de 8, para una tipografía con un tamaño de 12 píxeles, 16 de interlineado podría ser insuficiente y 24 demasiado. Hay **casos puntuales** en los que no es fácil tener claro cómo utilizar el grid de 8 puntos. Por ejemplo: en los elementos con una línea en el borde. En este caso, esta línea deberá estar definida de tal manera que ocupe espacio hacia el interior del botón. No contabilizaremos su grosor a la hora de medir el espaciado. **Excepciones a la regla** Hay proyectos y situaciones en las que **la retícula de 8 es demasiado grande**. En estos casos, el equipo estudia la posibilidad de utilizar una retícula global de 4 píxels. De este modo disponemos de más versatilidad a la hora de definir espaciados, proporciones y jerarquías en interfaces con mucha densidad de información. ### 3.4 Tipografía Puesto que la letra escrita es la principal forma de comunicación visual, el **buen uso** de la tipografía es muy importante. Este buen uso facilita el proceso de lectura y hace fluida la experiencia del usuario. Además, la tipografía es una herramienta genial para dotar de una **personalidad** concreta a los diferentes proyectos y para establecer un **tono comunicativo** acorde a esa personalidad. Cada tipografía tiene sus particularidades, y establecer dogmas sobre los valores numéricos que deben seguir no siempre funciona. Sin embargo, unas premisas generales que nos pueden ayudar a estructurar la información y componer los textos podrían ser las siguientes: * **Establece jerarquías** bien diferenciadas entre los distintos tipos de información. Para ello, puedes valerte de diferentes tipografías, pesos, tamaños, colores, etc. Una interesante forma de definir las distintas jerarquías para un sistema, es establecer en primer lugar los valores del cuerpo de texto, para a partir de ahí definir el resto. * Un **interlineado** entre 1,4 y 1,6 veces el tamaño de la tipografía suele funcionar para cuerpos de texto. Para destacados y titulares reducimos ese rango a 1,2-1,4. * Controla **el largo de la línea** del cuerpo de texto. Lo recomendable para una buena experiencia de lectura, son entre 45 y 75 caracteres. Puedes encontrar más información sobre este tema [aquí](http://webtypography.net/2.1.2). * Cíñete a **una o dos tipografías** y utiliza la menor cantidad de variaciones posibles de pesos de la misma. Esto es principalmente por cuestiones de rendimiento en webs y apps. ### 3.5 Iconografía La iconografía representa de forma visual conceptos complejos que, de un vistazo, trasladan **información útil al usuario**. Debe ser usada con mesura y de forma clara, sin dar lugar a mensajes ambiguos. Dentro del sistema de diseño, **agrupamos los iconos en función de su tamaño**. Partimos de unas medidas mínimas de 16px y escalamos hacia arriba en múltiplos de 8px en función de las necesidades de cada sistema. Para asegurar que todos los iconos de un tamaño determinado tienen las mismas proporciones, los insertamos sobre un fondo cuadrado transparente con esas medidas totales. Es importante definir las **propiedades formales** de los iconos para que exista un código de unidad visual entre ellos. Pueden existir tanto iconos a línea, como creados a partir de formas sólidas. Ambos comparten propiedades visuales que se pueden definir: * **Grosor de línea**. Es importante establecer un grosor estandarizado para todo el grupo de iconos. Incluso aquellos creados a partir de formas sólidas podrían llegar a hacer uso de líneas en algún momento. * **Terminaciones**. Por norma general, pueden ser rectangulares o redondeadas. * **Esquinas**. Normalmente pueden ser: angulares, redondeadas o con bisel. ### 3.6 Estilos de capa Clasificamos dentro de este apartado ciertas características que, por su **naturaleza global**, están presentes en muchas de las piezas que componen el sistema y ayudan a dotar al mismo de un tono y una voz propias. Como estilos definimos: * **Estilos de color**. Aquí incluimos tanto colores relacionados con el *branding*, como aquellos con un carácter más funcional, como aquellos usados en CTAs, mensajes de error, etc. * **Estilos de forma**. En esta categoría encontramos una miscelánea de valores que podemos aplicar, como por ejemplo la redondez de los bordes de las formas, la opacidad, sombras que proyectan, desenfoques, etc. ## 4. **Tipos de elementos** Todo sistema está por definición compuesto de elementos que lo articulan y le dan sentido. Para hacer viable el trabajo en equipo con los sistemas de diseño, es indispensable utilizar un **lenguaje común y autoexplicativo** para nombrar los distintos elementos. **Basándonos en su naturaleza**, nosotros proponemos la siguiente clasificación: * Fragmentos * Componentes * Módulos * Plantillas {% hint style="warning" %} Es importante destacar que aunque los nombres aquí los hemos reflejado en español normalmente, en las aplicaciones y a la hora de trabajar con ellos, usaremos siempre su traducción en inglés. Esto lo hacemos porque, así, se adapta mejor a todos los proyectos y porque luego será más sencillo que tengamos un mismo idioma con el equipo de desarrollo (que suelen escribir todo el código en inglés). Por lo tanto, a la hora de diseñar utilizaremos como nombres: * Fragments * Components * Modules * Templates {% endhint %} ### 4.1 01 Fragmentos Un fragmento, como su nombre indica, es algo incompleto que sólo cobra sentido cuando se asocia con otros fragmentos para generar un significado o con un componente para añadírselo. Por poner un ejemplo más bajado a tierra, un fragmento podría ser un icono de error dentro de una alerta debido a que en el diseño nunca va a ir solo, siempre irá acompañado por otro elemento, el texto, de ir solo, carecería de sentido o estaría mal aplicado. Otro ejemplo de fragmentos serían los items que forman parte de un conjunto y no deben nunca incluirse por separado (celdas de una tabla, pestañas de un grupo de pestañas, enlaces de una navegación, opciones de un selector, etc.). Por lo tanto, formarán parte del grupo de fragmentos los siguientes elementos: * Iconos * Contenedores * Items (como lista, tabla o pestañas) ### 4.2 02 Componentes Un componente sería un elemento que tiene sentido en sí mismo, es decir, está completo y no necesita acompañarse de otros elementos. Se sirven de ellos mismos para cumplir una función específica. Es importante que un componente deba cumplir una única función, en el caso de que cumpla más de una función, en el momento en que se incumple esta regla ese componente no debe ser considerado como tal y pasará a ser parte de una categoría de elementos más compleja como módulos o plantillas. Por poner un ejemplo, un componente sería un botón. Un botón no necesita de otro elemento para cumplir su función y podemos colocarlo en una interfaz y no se vería incompleto o ausente de significado. Los componentes más comunes son: * Bloques de texto * Botones * Links * Campos de texto * Selectores * Barras de navegación * Imágenes * Ilustraciones * Grupos de pestañas * Listas * Tablas ### 4.3 03 Módulos Un módulo o sección es un conjunto de componentes que se unen para adoptar una función a un nivel más global, por ejemplo, un campo de texto permite introducir datos (tiene sentido por si mismo) pero en el momento de combinarse con otros datos, botones, etc. puede generar un módulo que adquiere una función más global, como un formulario de registro. Otro ejemplo sería un pie de página, a menudo se conforma de enlaces que en si mismos tienen sentido como links a otras páginas pero en su unión adoptan una funcionalidad más global que es la de navegación. Algunos ejemplos de módulos: * Formularios * Modales * Artículos * Cards * Calendarios * Galerías * Buscadores ## 5. Nomenclatura La nomenclatura de nuestro sistema está basada en los grupos diferenciados en el punto anterior. Esto nos permite que los elementos estén ordenados y sean fáciles de encontrar. Tener los mismos principios de nomenclatura en los distintos proyectos del equipo nos ayuda a conseguir consistencia y eficiencia. A continuación se muestran algunos ejemplos como lista de referencia ante la creación de un nuevo sistema de diseño en un proyecto. Hay proyectos en los que no aparezcan todos los componentes que se listan a continuación, y otros proyectos en los que surjan nuevos. La idea es adaptar las bases, y que producto y sistema de diseño evolucionen juntos. ### 5.1 01 Fragmentos * Iconos 01 Fragments / Icon / \[Tamaño]px / \[Nombre del icono] Nosotros trabajamos con los iconos contenidos en cajas de dimensión cuadrada. Esta dimensión hace referencia al tamaño, que siempre tiene que ser múltiplo de 8px, respetando así nuestra retícula. Definimos el nombre del icono de forma que describa a este y a su funcionalidad. Esto nos permite encontrar y distinguir un icono sin necesidad de verlo. * Contenedores 01 Fragments / Container / \[Tipo de contenedor] ### 5.2 02 Componentes * Botones 02 Components / Button / \[Tipo de botón] / \[Estado] **Tipo de botón** * Primary → CTA's primarios que deben hacer referencia a la acción principal * Secondary → CTA's secundarios que deben hacer referencia a acciones secundarias * Tertiary * Social → botón Facebook, Google, Twitter, ... **Estado** Siempre deben estar disponibles todos los posibles estados que tiene el botón. Para ello, su nomenclatura debe seguir: * 01 Active * 02 Hover * 03 Pressed * 04 Disabled **Un ejemplo seria:** ``` - 02 Components / Button / Primary / 01 Active - 02 Components / Button / Primary / 02 Hover - 02 Components / Button / Primary / 03 Pressed - 02 Components / Button / Primary / 04 Disabled - 02 Components / Button / Secondary / 01 Active ``` * Links 02 Components / Link / \[Estado] **Estado** Encontrando los cuatro tipos de estados que disinguimos para los botones: active, hover, pressed y disabled. **Un ejemplo seria:** ``` - 02 Components / Link / 01 Active - 02 Components / Link / 02 Hover - 02 Components / Link / 04 Disabled ``` * Campos de texto 02 Components / Text Field / \[Estado] **Estado** Para un campo de texto siempre distinguimos cuatro estados, los cuales reflejamos en nuestro sistema como: * 01 Empty * 02 Focus * 02 Focus Typing (Opcional) * 03 Filled * 04 Error **Un ejemplo seria:** ``` - 02 Components / Text Field / 01 Empty - 02 Components / Text Field / 03 Filled ``` * Selectores 02 Components / Selection controls / \[Tipo] / \[Estado] **Tipo** Nosotros solemos distinguir entre cuatro tipos de selectores, que son: * Dropdown * Radio button * Checkbox * Picker **Estado** Es importante, que siempre estén disponibles el estado de elemento seleccionado y del elemento sin seleccionar, para ello utilizamos: * Selected * Unselected **Un ejemplo seria:** ``` - 02 Components / Selection Controls / Dropdown / Selected - 02 Components / Selection Controls / Dropdown / Unselected - 02 Components / Selection Controls / Radio button / Unselected ``` * Barras de navegación 02 Components / Navigation / \[Tipo de navegación] **Tipo de navegación** Los tipos de navegación más comunes que distinguimos en los proyectos son: * Navbar * Tabbar * Footer * Header **Un ejemplo seria:** ``` - 02 Components / Navigation / Header - 02 Components / Navigation / Navbar - 02 Components / Navigation / Footer ``` * Imágenes 02 Components / Image * Ilustraciones 02 Components / Illustration / \[Nombre de la ilustración] **Nombre** Como ocurría anteriormente con los iconos, tener un nombre de ilustración descriptivo nos permite distinguirla fácilmente. * Listas 02 Components / List / \[Tipo de lista] **Tipo de lista** El tipo de lista hace referencia a la funcionalidad de la lista, distinguiendo aquella o aquellas características que la diferencia. **Un ejemplo seria:** ``` - 02 Components / List / Default - 02 Components / List / Default + Avatar - 02 Components / List / Comment ``` * Tablas 02 Components / Tables / \[Tipo de tabla] ### 5.3 03 Módulos * Modales 03 Modules / Overlay / \[Tipo de modal] **Tipo de modal** El tipo de modal lo describe de forma funcional, para que sea fácilmente reconocible e identificable. * Cards 03 Modules / Cards / \[Tipo de card] * Calendarios 03 Modules / Calendar ### 5.4 04 Plantillas Todas las plantillas siguen la misma nomenclatura, no distinguimos en subgrupos o elementos más pequeños. Lo hacemos de esta forma porque únicamente consideramos como plantilla aquellas vistas que se utilizan de forma recurrente. 04 Templates / \[Nombre de la vista] **Nombre de la vista** El nombre de la vista es el indicativo de la funcionalidad u objetivo de la misma, el cual nos permite identificarla fácilmente. ### Estilos * Color Color / \[Tipo de paleta] / \[Tipo] / \[Nombre del color] **Tipo de paleta** Los proyectos suelen tener dos tipos de paletas, una paleta primaria y otra secundaria. * **Primary** → para la paleta primaria. Esta debe contener los colores que definen y dan personalidad a la marca del producto, estos suelen ir asociados al *branding.* Siendo su función principal acentuar*.* * **Secondary** → para la paleta secundaria. Esta contiene tanto los colores complementarios como tipográficos. **Tipo** Distinguimos dos tipos de estilos de color que se puedan aplicar sobre una capa, estilos con relleno y estilos de borde. Diferenciando así entre: * **Full** * **Outline** **Nombre color** Cada color debe tener un nombre de referencia. Este nombre no debe ser descriptivo del color, sino de la funcionalidad. **Un ejemplo seria:** ``` - Color / Primary / Outline / Primary - Color / Primary / Full / Secondary - Color / Secondary / Outline / Light - Color / Secondary / Outline / Dark ``` * Texto \[Tipo de tipografía] / \[Tamaño] / \[Color] / \[Peso] / \[Alineación] **Tipo tipografía** * Primary → tipografía principal * Secondary → tipografía secundaria. Utilizar esta nomenclatura, en lugar de utilizar el nombre de la tipografía nos permite que en el caso de que esta cambie no sea necesario renombrar los estilos. **Tamaño** Agrupamos los textos por tamaño. Para que en todos los proyectos, se siga una misma nomenclatura, independientemente los tamaños utilizados, aplicamos la siguiente escala: * XXXL * XXL * XL * L * M * S * XS * XXS * XXXS Siendo XXXL el grupo que contiene los textos con un tamaño mayor, y XXXS los de menor. **💡** Nosotros tomamos como referencia el tamaño M, siendo el que más se repite y se utiliza en un proyecto. En función de este, definimos cuales son los tamaños mayores y menores que él. **Color** Como mínimo, solemos establecer un color oscuro y otro claro para utilizar en la tipografía. Sin embargo, hay ocasiones en los que también utilizamos estilos de texto que de otros colores definidos en la paleta. **Peso** Corresponde al *text weight* asociado a la tipografía. Por ejemplo: * Light * Regular * Medium * Semibold * Bold * Extrabold * ... **Alineación** Siempre tenemos los estilos de texto alineado al centro, la izquierda y la derecha creados, para que estén disponibles. Utilizamos la siguiente nomenclatura: * Left Aligned * Centered * Right Aligned ``` Un ejemplo sería: - Primary / M / Dark / Medium / Left Aligned - Primary / M / Dark / Medium / Centered - Secondary / M / Dark / Medium / Right Aligned - Primary / L / Light / Regular / Right Aligned ``` * Opacidad Opacity / \[Número de opacidad] * **Número de opacidad** Coincidiendo este número con el tanto por ciento de opacidad aplicado. ``` Un ejemplo sería: - Opacity / 10 - Opacity / 20 - Opacity / 30 - Opacity / 40 - ... ``` ## 6. **Documentación** Para documentar los elementos que forman el sistema de diseño, es necesario ordenar los componentes para crear una **documentación** visual de los mismos. Estos componentes se deben ordenar clasificados en diferentes mesas de trabajo, de forma que se separen estilos y elementos. En algunos proyectos puede suceder que haya muchos elementos y sea imposible organizarlos todos en un mismo sitio, en ese caso se podrá dividir los elementos según al grupo al que pertenezcan en fragmentos, componentes y módulos. A continuación se muestra un ejemplo visual de cómo se organizarían esos estilos y elementos. **Estilos** Los componentes perceptibles hacen referencia a aquellos que reflejan la identidad y personalidad de la marca. Los componentes mínimos de esta mesa de trabajo deben ser: * Color → paletas de colores utilizadas en el producto * Tipografía → de la tipografía es necesario documentar: * Pesos tipográficos utilizados * Estilos de textos utilizados → se deben documentar las características de cada estilo de texto: altura, espaciado entre caracteres y pesos en los que se utiliza. * Espaciado → debe mostrar el grid utilizado para el producto concreto ![Estilos del sistema de diseño](/files/-LNkC0e1-eFEv4Hhe_lc) De manera interna, hemos desarrollado un *plugin* que complementa nuestro software de trabajo **automatizando la creación** de la estructura de un sistema de diseño. Esta extensión ahorra el trabajo mecánico de creación de estilos de color y texto. **Elementos** La organización visual de los elementos debe respetar y ser un reflejo de las reglas que seguimos para dividirlos en grupos de tal forma que estén separados según su naturaleza. La perspectiva general del sistema de diseño debería ser similar a la mostrada en el siguiente diagrama: ![Visualización global de los elementos de un sistema de diseño](/files/-LNkC0e3cBa7KH6MERQb) Una vez hemos dado por concluida la documentación visual, es interesante reflejar en un documento adjunto, o en el mismo archivo del sistema, aquellos elementos que requieren de un nivel de detalle más minucioso. Esta documentación adjunta debe hacer una breve descripción de estos y de su uso. # 5. Conversion Rate Optimization ## 1. **Qué es CRO** ### 1.1 Fundamentos de CRO Conversion Rate Optimization es el proceso mediante el cual se optimizan los objetivos de un entorno digital y en consecuencia los objetivos de negocio de dicho entorno. El proceso se basa en el análisis del comportamiento de los usuarios para identificar los problemas o necesidades que pudiesen tener, y potenciar las acciones que nos ayudarán a incrementar las conversiones finales. CRO es una disciplina que se basa en el método científico como marco de referencia para plantear y validar hipótesis. #### 1.1.1 ¿Por qué hacer CRO? CRO te habilita a optimizar las funcionalidades de tu producto digital, mientras entiendes el porqué y el como se comportan tus usuarios. La premisa es que tus activos digitales nunca llegan a tener su máximo potencial hasta que rigurosamente experimentas los cambios. Los principales beneficios por los que hacer CRO: * **Incrementa tus beneficios**: mejora tus principales objetivos de negocio optimizando los procesos clave que harán que incremente tu revenue de forma directa. * **Optimiza los resultados de tus campañas**: mejora la relevancia de tu producto para los usuarios que vienen impactados de diferentes canales y puntos de contacto. * **Incrementa el CLV de tus clientes**: incrementar el engagement de tus usuarios hará que quieran seguir teniendo contacto con tu marca. * **Baja tu Coste por adquisición**: tu CPA deberá de ser siempre menor que tu CLV si no no estarán siendo rentables tus campañas. * **Mejora la experiencia de tu usuario**: generar procesos amigables y usables garantiza la probabilidad de que se generen procesos transaccionales sin fricciones ni dificultades. #### 1.1.1 ¿Qué se entiende por una conversión? Una conversión es la consecución de un objetivo o una acción que quieres que tus usuarios realicen y que directa o indirectamente genera ganancia para tu negocio. Como consecuciones de objetivo se puede entender el número de veces que se alcanza un objetivo de valor para el negocio. ![](/files/-LpEC20t2gQlqPicKbEW) ### 1.2 Ingredientes del CRO Entendemos como ingredientes del CRO aquellas disciplinas dentro del producto digital que nos permitirán generar la mejora en cualquier entorno. Son las disciplinas necesarias para que un proyecto de CRO se pueda llevar a cabo. #### 1.2.1 Disciplinas necesarias En un proyecto CRO necesitamos coordinar 3 tipos de disciplinas: * **Tecnología**: Front-end Back-end. * **Product design**: UX, UI, copywriting y negocio. * **Analítica digital**: estadística, analítica, implementación técnica. Tener un perfil que integre estos conocimientos es bastante complejo y más cuando hablamos de conocimientos avanzados de cada una de estas disciplinas. #### 1.2.2 La Pirámide de la conversión El inicio de un proyecto de CRO pasa por analizar aquellas dimensiones que tiene que tener cubiertas cualquier producto digital para que se produzca una conversión.\ Estas dimensiones van desde lo más esencial que se le exige a cualquier interfaz, que funcione, ganando poco a poco en complejidad hasta llegar a la palanca de la persuasión. Las dimensiones son las siguientes: 1. **Funcional**: ¿La web funciona correctamente? ¿Podemos generar los procesos de conversión sin errores técnicos? 2. **Accesible**: ¿Se puede utilizar independiente de las capacidades del usuario? ¿Está adaptada a personas con discapacidad? 3. **Usable**: ¿Se generan procesos amigables y sin obstáculos? 4. **Intuitiva**: ¿Se guía a los usuarios solventando sus dudas? ¿El usuario es capaz de encontrar lo que busca por sí mismo y sin dudarlo? 5. **Persuasiva**: ¿Las propuestas de valor son claras y atractivas? ¿Se recomiendan acciones que conducen a la conversión? ![](/files/-LpECBCzOExfoBDIRxO3) Dentro de cada fase generamos un análisis heurístico identificando los problemas que se pueden dar, siendo la fase persuasiva la que necesita un análisis más profundo aplicando técnicas de psicología de la persuasión para proponer mejoras en este punto. #### 1.2.3 Los principios de la persuasión Persuadir es el principal objetivo de cualquier proyecto de mejora de la conversión. Existen mecanismos que pueden activar necesidades de nuestros usuarios a través de determinados estímulos y que harán que sean más proclives a realizar determinadas acciones. Entender de qué modo podemos influir en la psicología de nuestros usuarios será clave para persuadirles y que directamente esto se refleje en los resultados de negocio. CRO no solo busca optimizar tasas de conversión, sino optimizar decisiones como objetivo principal. Para conseguir esto necesitamos entender primero el universo de nuestros usuarios. Cuáles son sus motivaciones, sus miedos, sus carencias o lo que en marketing se llama sus FUDs (Fears, Uncentainties and Doubts). Como referencia en este campo podemos basarnos en las técnicas y principios de persuasión publicados por el escritor Robert Cialdini los cuales podréis encontrar en estos dos libros: * **Influencia**: La psicología de la persuasión * **Pre-suasión**: Un método revolucionario para influir y convencer. El autor basa sus técnicas en que las cosas influyentes que hacemos y decimos sirven en primer lugar para pre-suadir a nuestro público, y lo hacen modificando las asociaciones que sus miembros establecen con lo que hacemos o decimos después. Los 6 principios de persuasión según Robert Cialdini serían lo siguientes: 1. **Reciprocidad:** estamos condicionados a mostrarnos agradecidos si alguien nos hace un favor o nos regala algo y sentimos la necesidad de dar de igual modo. 2. **Consistencia:** se es más proclive a decir que sí ante compromisos que se hayan tomado previamente. 3. **Aprobación social:** hacemos lo que hacen los demás para ser aceptados y más cuando son personas que ya conocemos o en las que confiamos. Nuestros amigos, familia o personajes públicos con buena reputación influyen permanentemente en nuestras decisiones. 4. **Escasez:** nos parecen más valiosas las cosas que más difícil resultan de conseguir. 5. **Simpatía:** no compramos cosas de personas que no nos gustan o no nos resultan familiares. Un factor decisivo para que el usuario tome una decisión es que nuestra empresa o las personas que trabajan en ella le parezcan simpáticas. 6. **Autoridad:** nos cuesta menos hacer cosas si éstas resultan creíbles y serias. El criterio de un experto puede funcionar como detonante de fiabilidad a la hora de creernos algo. ## **2. Proceso CRO: metodología científica** ### 2.1 ¿Qué es el método científico? Definición de Método científico: {% hint style="success" %} Un método o procedimiento que ha caracterizado a la ciencia natural desde el siglo XVIII, que consiste en la observación sistemática, medición, experimentación, la formulación, análisis y modificación de las hipótesis. {% endhint %} *Oxford English Dictionary.* Al ser CRO una metodología puramente analítica, las decisiones derivadas de su práctica deben ser científicas. El seguir con rigor estas reglas estrictas del método científico nos permite aplicar la metodología de forma ordenada, documentada y madura. Aprendiendo a validar nuestras ideas y haciendo a nuestros clientes partícipes de los aprendizajes en cada paso, aseguramos la certeza de las decisiones que tomamos. ### 2.2 Planteamiento de hipótesis en el método científico La disciplina CRO se sustenta en el método científico para validar las ideas de mejora, que a partir de ahora llamaremos "hipótesis". #### ¿Qué es una hipótesis? Una hipótesis es una suposición hecha a partir de unos datos que sirve de base para iniciar una investigación o una argumentación. Las hipótesis se refutan, es decir se aceptan o no se aceptan. Y será de este modo como iteraremos en nuevas hipótesis sobre el aprendizaje obtenido. Por este motivo el proceso de CRO es cíclico y nunca termina. ### 2.3 Metodología CRO en mendesaltaren En mendesaltaren hemos implementado el método científico utilizando herramientas en cada fase que aplicamos sistemáticamente en todos los proyectos. Esto nos ayuda a aplicar la metodología de forma estricta y organizada y a documentar el proceso lo cual nos ayuda a poner en valor el aprendizaje que obtenemos de la validación de nuestras ideas. Trabajar dentro de un framework claro te permitirá optimizar tu tiempo y tus recursos. ![](/files/-LpECGlITMa66OK4boDt) #### 2.3.1 Fase de entendimiento En esta fase inicial el objetivo es conocer el proyecto con el mayor grado de profundidad posible. #### **2.3.1.1 Kickoff** **¿Qué es?** Es el punto de inicio de un proyecto donde las partes implicadas toman contacto y se presentan. Además es el punto de intercambio de información para conocer el estado de la empresa y su histórico. Debemos tener claros los objetivos y que tod o el equipo los comparta. **¿Cómo lo aplicamos?** En mendesaltaren tenemos una hoja con preguntas predeterminadas por categorías que nos ayuda a tomar el máximo partido a los kickoff de proyectos de CRO: {% hint style="info" %} 👉 [Table 1 - Grid view](https://airtable.com/shrySBP6wEQYm704U) {% endhint %} #### **2.3.1.2 Plan de medición** **¿Qué es?** El plan de medición es un documento que nos ayuda a definir las necesidades de medición mediante la identificación de los objetivos de negocio y de los indicadores que responderán a la consecución de dichos objetivos. Todo proyecto de optimización de la conversión debe de empezar por una fase estratégica de alinear negocio con el Plan de objetivos que vamos a mejorar. Esto nos ayuda a poner foco en los KPIs que atacaremos con las acciones que llevaremos a cabo y a monitorizar esos KPIs con herramientas de medición para ver el impacto que éstas acciones están teniendo a lo largo del tiempo. Pasos para generar un plan de medición en CRO: 1. **Definición de objetivos de negocio.** Definimos cuáles son los objetivos de negocio de forma global. Estos objetivos de negocio serán los que nos acompañen en todo el proceso de optimización y serán los objetivos que buscaremos mejorar como fin último. 2. **Definición de objetivos de cada activo digital.** Traducimos esos objetivos de negocio en objetivos de los activos digitales, entendiendo como activo digital aquellos entornos donde tiene presencia nuestro negocio de forma digital (apps, webs, quioscos en tiendas...). Cada activo digital apoyará de un modo u otro a esos objetivos de negocio. No todos los entornos deben tener los mismos objetivos, tenemos que pensar cómo asisten unos a los otros en el journey de conversión. 3. **Definición de KPIs.** Identificamos los KPIs que darán respuesta a si esos objetivos se están cumpliendo o no. Las acciones relacionadas con el uso y explotación del servicio o producto nos ayudarán a definir nuestros KPIs. 4. **Periodicidad**. Establecemos la periodicidad con la que deberán ser revisados los KPIs para entender su evolución. La periodicidad está muy relacionada con los ciclos de compra o estacionalidad del producto. 5. **Segmentación**. Elegimos los segmentos (reglas de agregación de datos que responden a una serie de características o variables cualitativas concretas) que, aplicados a los KPIs, nos ayudarán a tomar decisiones de negocio. 6. **Visualización de datos.** Debemos definir cuál será la visualización de los datos, y, tras esto, definir una herramienta para crear dashboard y automatizar los reportes. De esta forma simplificaremos el proceso de análisis de datos hasta una forma mucho más operativa. 7. **Justificación del plan de medición.** Justificamos cuándo será necesario actualizar el plan de medición. La justificación de un cambio en ese plan de medición puede estar relacionada con un cambio del producto o una evolución de sus funcionalidades, así como un cambio de modelo de negocio o un nuevo segmento de mercado. **¿Cómo lo aplicamos?** El resultado de este ejercicio debe de ser algo similar a este ejemplo aplicado a un medio de comunicación digital. ![](/files/-LpECs-TSQ47_GQQtEJ7) #### **2.3.1.3 Guía de etiquetado** **¿Qué es?** Una guía de etiquetado describe los códigos a incluir en el código fuente de una web o app, para garantizar el despliegue de la herramienta de medición digital elegida. Este documento incluye un primer apartado donde se exponen aspectos generales relacionados con el etiquetado, detallando en las siguientes secciones los criterios específicos aplicados en los diferentes escenarios de conversión y otros contenidos. El objetivo último es poder extraer información específica del comportamiento de los usuarios con el entorno, para así profundizar en el análisis de los datos y conseguir insights relevantes para el desarrollo y optimización del activo digital. **¿Cómo lo aplicamos?** Generamos una guía donde aparecerán especificadas las variables página, de usuario y eventos de interacción con los valores que se enviarán a la herramienta de medición. Un ejemplo de especificación de evento de interacción con un botón sería el siguiente: ![](/files/-LpEDB7CPBzCRJMLvQ7L) {% hint style="info" %} *Para el etiquetado, el valor que tomarán las variables en el data Layer serán siempre caracteres alfanuméricos, en minúsculas, separadas por guión bajo y sin acentuación.* {% endhint %} #### 2.3.2 Fase de Investigación #### **2.3.2.1 Analítica cualitativa** **¿Qué es?** Los análisis cualitativos son una parte fundamental de la investigación y complementan a los análisis cuantitativos y heurísticos de la fase de research o investigación. La investigación cualitativa tiene como objetivo principal obtener información de los participantes basada en sus creencias, percepciones, opiniones, significados y actitudes. Son análisis que nos dan un conocimiento más aproximado a cómo los usuarios piensan o sienten. **Tipos de análisis cuantitativos:** * **Entrevistas**\ La entrevista cualitativa, a diferencia de la cuantitativa, es más abierta y conversacional aunque su fin último es el mismo: la recolección de datos. Las características principales son: * Puede ser individual o grupal, no como una dinámica abierta sino siempre moderada por un entrevistador. * Aunque preferiblemente se realizan en persona, no siempre se tienen los recursos y el tiempo, por lo que pueden realizarse de forma telemática o por teléfono. * La entrevista puede ser más estructurada o más abierta, más rígida o más flexible, poner el foco en entender o en explicar. * **Encuestas o cuestionarios.** Aunque las encuestas tienden a percibirse como herramientas más cerradas de recolección de datos pueden formar parte de estudios cualitativos cuando pretenden conocer más allá de meras cifras. * **Mapas de calor** Los mapas de calor son una representación gráfica del seguimiento del movimiento del ratón de un usuario durante su visita a un sitio web, donde los valores están asignados a diferentes colores, siendo los colores más cálidos las áreas más populares y los colores más fríos las áreas más impopulares o menos recorridas. Existen distintos mapas de calor: * **Mapas de click.** Los mapas de clic muestran una vista agregada de nuestra página dónde los visitantes han realizado clic sobre nuestra página (si hablamos de una versión de escritorio) o donde han realizado tap (desde sus dispositivos móviles). * **Mapas de Scroll.** Los mapas de scroll muestran el porcentaje exacto hasta dónde han bajado nuestros usuarios en la página en cuestión. Cuanto más roja sea el área, más usuarios la han visualizado. * **Mapas de movimiento.** No se ha demostrado la correlación entre el movimiento del ojo y el movimiento del ratón, por lo que estos análisis son los más impopulares y relativos. Todos estos mapas nos dan información valiosa sobre qué partes del sitio son más o menos interesantes para los usuarios (las áreas más vistas o más clicadas), cuáles no se interpretan bien (muchos clics sobre elementos que no son clicables) o no llegan a visualizarse e incluso apreciar las diferencias entre el comportamiento de los usuarios móviles y los usuarios de escritorio u otras reglas de segmentación. * **Grabaciones de sesión** Las grabaciones de sesión son una de las herramientas más valiosas para conocer el comportamiento de usuarios en nuestro sitio. Se trata de grabaciones completas de visitas a tiempo real, incluyendo clics, taps, movimientos de ratón y de scroll. Observando la interacción del usuario con nuestra página podemos ver dónde se queda atrapado (¿no entiende lo que ve o cómo continuar?, ¿la información es muy densa?, ¿no termina de realizar la acción porque hay algún punto de fricción?), si la navegación para él es intuitiva o no es usable, etc. **¿Cómo aplicamos?** A continuación vamos a definir un caso de estudio. * **Método utilizado**: Encuesta en entorno digital web con herramienta especializada. Informe basado en 754 respuestas. * **Pregunta**: ¿Cómo puntuarías tu experiencia con nosotros? ![](/files/-LpEE8r9q-nXIy73OW9I) Tras esa pregunta general, ahondamos en el porqué de esa puntuación con 3 preguntas de campo abierto donde dejamos al usuario expresar su opinión. * ¿Qué podemos hacer para mejorar tu experiencia? * ¿Qué es lo que más te gusta de nosotros? * Si hay algo que casi te frena a suscribirte con nosotros, ¿qué fue? Para sacar patrones claros debemos generar unos tags asociados a unos motivos para etiquetar las respuestas en base a su naturaleza. De este modo podemos tener una visión más global de los problemas o necesidades importantes. Lo mostramos en la siguiente tabla: Ejemplo de gráfico tras evaluar una de las preguntas con los diferentes tags asignados. #### **2.3.2.2 Analítica cuantitativa** **¿Qué es?** Los análisis cuantitativos son los análisis obtenidos de herramientas de recolección de datos agregados por interacción. Son datos numéricos que se generan mediante la interacción de los usuarios o el consumo de contenidos. Estos datos numéricos podemos segmentarlos aplicando variables cualitativas para profundizar en su conocimiento. **¿Cómo lo aplicamos?** Ejemplo de análisis para una web de Oposiciones. * **Objetivo**: entender los principales accesos a registro y consecución del mismo desde los diferentes puntos del site. * **Método utilizado**: identificación y tagueo de todos los accesos con variables de interacción en Analytics y análisis cuantitativo por segmentos secuenciales. ![](/files/-LpEEt86KfIhdanbUISy) #### 2.3.3 Fase de ideación #### **2.3.3.1 Generación de hipótesis** Las hipótesis tienen que reflejar el problema o necesidad identificada, que esté justificado con unos datos, anunciar cuál será nuestra propuesta de mejora y qué impacto tendrá. Podemos utilizar el siguiente framework como guía: {% hint style="success" %} Observando \[**problema**] y considerando \[**datos cualitativos/cuantitativos**], esperamos que \[**cambio**] para \[**segmento**] provoque \[**impacto**] que mediremos con \[**KPI**] durante \[**periodo de tiempo**]. {% endhint %} Hay una serie de preguntas que ayudan a generar hipótesis y conceptualizar esas hipótesis para testearlas de forma sencilla. A continuación enumeramos las preguntas y detallamos que información se necesita para responderlas adecuadamente. * **¿Qué problema tratamos de resolver?** Describir fricción en la experiencia de usuario, problemas de performance de página o cualquier otro tema estratégico en el que estamos trabajando * **¿Cuál será la métrica principal?** Métrica principal que vamos a utilizar para cuantificar nuestro objetivo * **¿Dónde vamos a testear?** Página, flujo o experiencia donde llevar a cabo el experimento y afectar a la métrica principal * **¿Qué cambios proponemos?** Describir el cambio que queremos testear * **¿Qué datos cualitativos tenemos?** Insights cualitativos para apoyar la decisión de qué testear * **¿Qué datos cuantitativos tenemos?** Cosas que nos dicen las grabaciones de sesión, encuestas, clickmaps o cualquier otra herramienta * **¿Cuál es la hipótesis?** Basado en \[datos cualitativos/cuantitativos], esperamos que \[cambio] para \[segmento] provoque \[impacto] que mediremos con \[KPI] para el \[periodo de tiempo] * **¿Qué métricas secundarias mediré?** Otros datos que nos pueden ayudar a entender el impacto del experimento * **¿A qué usuarios impactaremos?** Audiencia objetivo del experimento * **¿Durante cuánto tiempo?** Tiempo estimado necesario para obtener resultados significativos El documento para conceptualizar tus hipótesis podría estructurarse de la siguiente manera: 1. **Hipótesis.** 2. **Situación actual.** 3. **Solución visual.** 4. **Datos específicos en insights del análisis asociado a la hipótesis.** 5. **Criterios de aceptación para el test.** 6. **Cálculo de la muestra y días previstos del test.** 7. **Resultados.** 8. **Previsión de impacto en resultados de negocio.** {% hint style="warning" %} ***Recurso:*** [Plantilla Hipótesis de una idea](https://docs.google.com/presentation/d/1LpED3zhI3v_mitOQBNJJKv6ngAGDqfkRZijjeiAhu_w/edit#slide=id.g3f120539d2_0_0) {% endhint %} #### **2.3.3.2 Priorización de las ideas** Las ideas se priorizan en base a impacto vs esfuerzo. Todos los índices de priorización publicados tienen variables que toman más o menos valor numérico en base a estas dos premisas. El índice más conocido y el que utilizamos dentro de mendesaltaren es el *índice PIE (Widerfunnel).* Es un índice muy sencillo de implementar y que aconsejamos aplicar para los proyectos que están empezando hasta que lo hayan adoptado y a posteriori sofisticar mucho más esas variables. * ***Potencial**:* ¿Cuánto rango de mejora hay en la página? ¿Cuáles son las que están funcionando peor? Aquí tendrás que tener en cuenta los datos analizados cuantitativos y cualitativos que hayas podido obtener. * ***Importance**:* ¿Cuánto valor tiene el tráfico en esa página? Pon foco en las páginas que tengan mayor volumen de tráfico y cuyo su coste de adquisición sea mayor. * ***Ease**:* ¿Cómo de complicado será de implementar el test en la página? Aquí el grado de complejidad puede darse debido a diferentes criterios como: dificultad técnica o barreras organizacionales o políticas. Un ejemplo de índice para un cliente sería este: ![](/files/-LpTK-pfdfYr5Ie3Icxs) {% hint style="info" %} La puntuación final es el promedio de las notas que obtienen cada una de las variables. Si en una compañía hay variables que tienen más importancia que otras se puede hacer un cálculo ponderado en base al nivel de criticidad que tenga. {% endhint %} Otro índice en el que nos podemos basar es en el patentado por Conversion XL el cual tiene un nivel de detalle mucho mayor. {% hint style="info" %} **Recurso**: Índice PXL prioritization framework by CXL\ [PXL Test Prioritization Model](https://docs.google.com/spreadsheets/d/1DGuw1vkqYZ61plOpTcGHFDvh4MMP4kaRnlTtaXSWrJA/edit#gid=0) {% endhint %} #### **2.3.3.3 Wireframing y diseño** En esta fase tangibilizamos esas ideas en wireframes, es decir, en un esquema de la página o plano que se representa como un esqueleto o estructura visual de un sitio web o app. Este recurso nos permite representar visualmente la ordenación de los contenidos incluyendo los elementos de la interfaz y sistemas de navegación, y cómo funcionan en su conjunto. Usaremos un código en blanco y negro mostrando con un trazo negro los contenidos y la disposición de los mismos en el layout. #### **2.3.4 Fase de Experimentación** #### **2.3.4.1 Codificación de los test** La codificación de los test consiste en desarrollar las diferentes versiones de la hipótesis planteada que vamos a lanzar a test. En este proceso existen varias formas de implementar las diferentes variantes con una herramienta de test. A continuación enumeramos las opciones que tenemos a la hora de decidir cómo codificar esos cambios. **1) Crear los cambios en el editor visual que te provee la herramienta de test:** Esta se utiliza para cambios simples de CSS. Un cambio de este tipo puede ser cambiar el color o el copy de un botón determinado. Cualquier persona sin conocimientos o con conocimientos básicos de lenguajes de programación puede realizar esta tarea. El propio editor visual incorpora un modo sencillo para generar cambios sin tener que generar código. **2) Inyectar código javascript:** En determinadas ocasiones podemos querer hacer cambios más complicados en los que intervienen condiciones javascript o aplicar ciertos cambios a clases. En este caso inyectamos código javascript en el body escuchando el evento de carga de la página "DOMContentLoaded". Este método requiere conocimientos de programación y es más complicado, pero a la vez más potente. Nos permite aplicar ciertas reglas a algunos elementos, mover elementos de sitio, eliminar etc... **3) Split test entre dos versiones de ejecución sencilla:** Los métodos 1 y 2 se utilizan para cambios más o menos pequeños, pero en algunos casos se realizan rediseños enteros de la página, por lo que es necesario utilizar dos versiones totalmente diferentes en las que no se pueden hacer cambios ni con javascript ni con el editor debido a la envergadura de los mismos. Para ello podemos crear dos páginas [*www.example.com/content-a*](http://www.example.com/content-a) y [*www.example.com/content-b*](http://www.example.com/content-b) y en cada una de ellas mostramos su variante correspondiente del experimento. En dichos experimentos se puede producir un efecto no deseado de parpadeo (flickering) en función de cuánto tarde el código de la herramienta de test en ser cargado y ejecutado. Se muestra la versión original durante X milisegundos y a continuación se redirecciona a la variante. Para solucionar dicho parpadeo utilizamos un código javascript que nos proveerá la propia herramienta de test que evita este efecto no deseado. Dicho código evita el parpadeo pero la web se verá perjudicada en X milisegundos de latencia entre la ejecución de la herramienta y la redirección a la misma, en la cual la página aparecerá en blanco. Esta solución puede ser válida para experimentos simples, pero tiene un impacto grande en el rendimiento de la página, por lo que no solemos utilizarlo salvo que sea imprescindible. **4) Split test entre dos versiones de ejecución compleja:** Cuando es necesario hacer un cambio completo de en la página y queremos tener un buen performance en la implementación para no perjudicar a las ventas utilizamos los test a/b del lado de servidor. En estos experimentos es el propio servidor el encargado de realizar el experimento y mostrar la variante al usuario final. Estos experimentos son los más complicados de todos, requieren un conocimiento amplio y la posibilidad de modificar el backend. En dicho tipo de experimentos el servidor también debe mantener la variante del usuario, por lo que añadimos una cookie al navegador del usuario y forzamos la variante seleccionada durante todas las sesiones del usuario. **5) Otro tipo de experimentos:** No solo se pueden testear cambios de la interfaz, con los experimentos de servidor se pueden testear cambios más avanzados, como por ejemplo un cambio en un algoritmo de recomendaciones. También se podría llegar a testear el cambio de un framework javascript a otro, para ver que dicho cambio no afecta a los objetivos de la web. #### **2.3.4.2 Configuración de la herramienta de testing** A la hora de configurar un test en la herramienta de test tienes que tener en cuenta los siguientes puntos: * **Modulación de tráfico.** Modula el tráfico según cómo te gustaría distribuir la proporción del tráfico entre las variantes. En ningún caso se podrá cambiar la modulación cuando el test esté en ejecución puesto que los resultados se verán afectados. * Dividido de forma uniforme entre las variantes - 50 control / 50 variación. * Porcentajes personalizados para cada variante - 60 control / 40 variación. * **Impacto en tráfico.** Elige qué porcentaje de cantidad de tráfico quieres que sea impactado - 20% de la totalidad de mi tráfico. * **Segmentación.** Elige el tipo de segmentación de tu test. Las más comunes se reflejan en la siguiente tabla: {% hint style="warning" %} **Recurso**: [Tipos de reglas de segmentación](https://www.notion.so/63c99dec21414d7fb748748745c768a2) {% endhint %} * **Integración de la herramienta.** Integra el test con tu herramienta de analítica en una variable JS que te permita ver el trazo de tus usuarios en las diferentes variaciones. * **Configura tus objetivos**. Configura un objetivo primario y al menos dos secundarios, de modo que el test determine una variación ganadora basándose en las consecuciones del objetivo principal pero pudiendo ver cómo se comporta el tráfico en otros objetivos importantes para tu negocio. Los objetivos de los test son acciones que tienen valor para tu negocio y que los usuarios pueden hacer en su comportamiento: acciones de interacción, consumo de página o transaccionales. #### **2.3.4.3 Lanzamiento y auditado** Es muy importante que exista un *protocolo de auditado* antes de lanzar el test y después de lanzarlo. Repasa que los siguientes puntos funcionan correctamente: * Se lanzan los eventos y hits de página para la analítica en todas las versiones. * Funcionan todos los procesos en los principales navegadores y sistemas operativos. * La codificación de los cambios es correcta a nivel diseño y maquetación. * Los objetivos están bien configurados en la herramienta de testing y se registran tanto en la herramienta de análisis como de test. * Los test no deberían ser lanzados un viernes. Debemos de monitorizar al menos durante un día entero para asegurarnos de que no se están interrumpiendo procesos importantes en el entorno. ## **3 . Organización de equipos y trabajo multidisciplinar** ### **3.1 Gestión de flujo de trabajo: Asana** Asana es una herramienta de gestión de tareas que nos ayuda a organizar y planificar los flujos de trabajo a fin de tener en un panel con una visibilidad completa todas las tareas con los criterios para generar cada una de ellas y el momento de ejecución en el que se encuentran. ![Ejemplo de gestión de proyecto en Asana](/files/-Lpd17Whldqg54dqLwkO) El panel se organiza en 5 columnas más el Sprint en curso. 1. **Backlog**: tareas a abarcar en próximos sprints. 2. **Sprint Backlog**: tareas a abarcar en este sprint. 3. **In Progress**: tareas que se están abarcando en el momento. 4. **QA**: tareas pendientes de revisión generalmente por cliente. 5. **Done**: tareas terminadas. 6. **Sprint n**: tareas abarcadas en el sprint cuando se finaliza. Se quedan archivadas a modo histórico. ### **3.2 Modelo de Tareas** El panel se nutre de **tareas** las cuales integran los siguientes tags a la hora de clasificarse: * **Prioridad**: bloqueante, Alta, Media, Baja. ![](/files/-LpEiLiwmvNhe4h3qtWY) * **Épica**: lugar al que corresponde la historia de usuario; área privada, checkout, listados, fichas de detalle, otra parte pública etc. ![](/files/-LpEkJFYEVS9Rm5OJRMP) * **Nº de Sprint**: sprint al que corresponde la tarea. * **Historia de usuario**: Como usuario necesito\_\_\_\_\_\_\_\_ para\_\_\_\_\_\_\_\_\_. * **Tipo**: Diseño, Research, Definición, Documentación, Análisis, implementación... * **Qué y Para qué**: todas las tareas responden a estas dos preguntas. * **Tabla de tallas**: * **XS**: un rato. * **S**: medio día. * **M**: 1 día. * **L**: 3 días. * **XL**: 5 días o más. * **Criterios de aceptación**: especificaciones más técnicas o con mayor detalle de cómo tiene que realizarse la tarea. * **Asignación**: Persona que la va a realizar. Ejemplo de tarea: ![](/files/-LpdNkb5ke0DIk7ymFR8) ### **3.3 Plan global de optimización** Un Plan global de Optimización es un conjunto de recursos que nos ayudan a ver la trayectoria del proceso de optimización de un entorno digital, además de servir de histórico de todas las acciones que se han llevado a cabo. En cualquier proceso de optimización de un entorno digital debemos poner el valor el proceso al igual que el resultado. Google Drive o Airtable son dos herramientas gratuitas que pueden ayudarte a organizar toda la documentación relacionada con un plan global de optimización. A continuación enumeramos las partes de las que debe constar un Plan: #### **3.3.1 Backlog de ideas** Visión Global de las ideas de mejora en base al tipo de análisis que hayamos hecho para identificar el problema o la necesidad del usuario. #### **3.3.2 Plan de testing** Contiene el listado de test con su index en la herramienta de testing, el estado en el que está, su ubicación en cuanto a página, tipo de segmentación, entorno e índice de priorización. Además incluiremos el objetivo principal que va a dictaminar la variación ganadora, la conversión actual y conversión objetivo y el número de variaciones que intervienen. ![](/files/-LpEJZtyWMfuFpJagkUJ) Datos de muestra y cálculo de días y fechas. ![](/files/-LpEJjL9HdHArfo-iupg) ![](/files/-LpElGt5Gw6gs48rpC8h) Al finalizar el test haremos una valoración del mismo con las conclusiones y próximos pasos a seguir. ![](/files/-LpEllfSEIQVPUs-jHqZ) #### **3.3.3 Seguimiento de test en producción** Esta tabla nos servirá para ir generando una auditoría constante de los test que tenemos en ejecución y que podamos distribuir por la compañía en diferentes canales. La recomendación es que sea actualizada semanalmente para tener una visión de la evolución del test en un histórico. ![](/files/-LpEpsBnAiO-xgDG9gO4) #### **3.3.4 Documentación del proyecto** Este punto es clave para tener a mano todos y cada uno de los análisis generados en el proceso, así como los documentos de las hipótesis validadas para tener un histórico del proyecto y poder iterar en él. ![](/files/-LpEpwJi8nRKca2ZT0b0) ## **4. Tipos de proyectos en mendesaltaren** Existe la tendencia a creer que en un test A/B hay que hacer pequeños cambios muy controlados cada vez que testeamos algo. El plantear una hipótesis no quiere decir que se tenga que tangibilizar en pequeños cambios, principalmente porque la cantidad de tráfico que necesitas para testear es muy grande y en muchas ocasiones no contamos con ello. En nuestros proyectos apostamos por generar grandes cambios que nos den grandes diferencias. Los cambios basados en aprendizajes de investigación tienen mayor probabilidad de conseguir resultados exitosos y significativos. Diferenciamos 4 tipos de proyectos de CRO: ### **4.1 Mejora de un KPI concreto** En esta tipología de proyecto CRO, la compañía tiene un objetivo claro: mejorar un KPI de negocio. Suelen ser procesos muy concretos como optimización de formularios de registro o procesos de mejora de tasas de conversión de checkout. En ocasiones te proporcionan el incremento de mejora que esperan y en otras ocasiones simplemente el KPI. En este tipo de proyectos, el primer paso es asegurarnos de que existe una medición avanzada y consistente en una herramienta de datos, y si no fuera el caso, prepararemos una guía de etiquetado basada en sus objetivos de negocio. Ésta nos permitirá controlar de forma exhaustiva la evolución nuestras métricas de éxito. ### **4.2 Rediseños basados en datos** El rediseño basado en datos exige una sinergia perfecta entre equipos expertos en implementación y analítica de datos y equipos de diseño de producto. En este modelo de proyecto el cliente quiere un rediseño pero asegurándose de que sea efectivo y esté orientado a la consecución de sus objetivos de negocio. La primera fase de este proyecto es generar análisis cuantitativos y cualitativos para identificar problemas actuales o necesidades no cubiertas de los usuarios. Tras esto, generamos hipótesis de mejora que se aplican a los diferentes procesos del entorno y las cuales priorizamos en base al ciclo de compra del usuario y al impacto que pudiesen tener en negocio. Desde CRO y conjuntamente con los product designers, formulamos unas soluciones visuales conjuntamente, las implementamos y testeamos. {% hint style="success" %} Al mismo tiempo que vamos mejorando puntos clave en el journey de los usuarios, generamos un sistema de diseño que nos servirá para nutrir evolutivos del producto y a futuro escalar mucho más rápido. {% endhint %} ### **4.3 Implantación de metodología CRO in-house** En este tipo de proyecto, el cliente necesita formar en metodología CRO a sus equipos, implantar la metodología dentro de la compañía generando una estructura de forma que los equipos se coordinen y haya recursos que nutran el proyecto. **¿Cómo lo hacemos?** * **Definimos** la documentación estructurada para cada fase del proceso CRO. * **Generamos** requisitos de analítica avanzada para medición de todos los activos digitales. * **Conectamos** objetivos de negocio con los objetivos de cada activo. * **Construimos** modelos colaborativos interdepartamentales. * **Analizamos** datos cualitativos y cuantitativos. * **Recopilamos** un backlog de ideas para testing. ### **4.4 Testeo de nuevos modelos de negocio** Estos proyectos necesitan de la colaboración de diseñadores de servicio los cuales serán los encargados de definir el nuevo modelo de servicio "to be" y generar el blueprint que nos ayudará a tangibilizar el servicio dentro del customer journey. Aplicaremos la metodología científica trasladando todo el nuevo modelo en hipótesis y las priorizaremos de modo que nos ayude a construir un backlog de releases para la construcción del producto mínimo viable (MVP). Para trasladar esas hipótesis a producto y funcionalidades utilizamos una técnica de diseño de producto "User Story Mapping" que nos ayuda a entender qué funcionalidades serán necesarias para que se cumplan las historias de usuario que dotarán al producto de entidad. El nuevo modelo se diseñará y se experimentará mediante test A/B controlando los indicadores de éxito que nos ayudarán a entender si el nuevo modelo es adoptado de forma correcta y exitosa. # i. Herramientas En este apartado detallamos las herramientas y ejercicios que utilizamos a lo largo del proceso. Hablamos sobre el fin que tiene cada herramienta y cómo trabajamos con ellas de forma que nos ayudan a mejorar nuestro trabajo día a día. [Abstract](/tools/abstract) [Sketch](/tools/sketch) [Figma](/tools/figma) [Zeplin](/tools/zeplin) [Marvel](/tools/marvel) [Notion](/tools/notion) [Asana](/tools/asana) # Abstract ## Abstract En el equipo trabajamos con Abstract porque nos permite tener un control de versiones del producto y trabajar varias personas simultaneamente sobre un mismo archivo de Sketch, nuestra principal herramienta de trabajo. Con Abstract hemos conseguido eliminar copias en conflicto, duplicados y confusiones sobre cuales son los archivos finales. Y además, nos ha permitido incluir a nuestros clientes en el flujo de trabajo, pudiendo estos visualizar el trabajo realizado y el estado en el que está proyecto. {% hint style="info" %} ✏️ Para que los clientes puedan ver el proyecto deben estar invitados al proyecto y formar parte de los miembros de este. {% endhint %} En este apartado veremos cómo funciona Abstract y cómo lo utilizamos en el estudio en nuestro día a día. ## 1. Introducción La estructura básica de abstract se compone de *Master* y *Branches.* Su funcionamiento se basa en realizar *commits* y *mergear* ramas, o *branches*. Los *commits* representan los cambios que se han realizando. Un *commit* puede entenderse como una foto a un archivo de Sketch en un momento determinado, permitiéndonos volver siempre que queramos a ese instante. El conjunto de *commits* forman un histórico, donde están reflejados todos los cambios que se han realizado sobre los distintos archivos de Sketch que formen un proyecto. Esto nos permite tener conocimiento del trabajo realizado, y que ante cualquier ausencia no prevista, se pueda continuar con el trabajo sin ningún problema. Cualquier miembro del equipo podría seguir sin que se produzcan pérdidas de información, conocimiento y trabajo. ### 1.1 *Master* El *Master* es la ***Source of truth*** de nuestros proyectos. Todo lo que contenga el *Master* debe estar listo para poder validar el trabajo con el cliente o subir los diseños a Zeplin para producción. ### 1.2 Rama (*branch*) Cada persona que trabaja en el proyecto, trabaja en una rama distinta. Cada rama pertenece a una persona distinta. Todas las ramas principales sobre las que se trabaje una nueva funcionalidad o un concepto deben partir del *Master*, ya que es allí donde están reflejados los últimos cambios *buenos* realizados. Y una rama puede sostener otras, de forma que varias personas puedan trabajar sobre lo mismo y posteriormente se pueda unificar sin problemas el trabajo realizado. Al realizar una rama se realiza una copia exacta de los archivos de su rama padre, bien sea el Master o la rama de otro compañero. Esto nos permite evitar pérdidas de información. Para nosotros, ejemplos de ramas podrían ser: * Branding * Exploración visual * Módulo de búsqueda * Flujo del checkout * Alineación navbar Las ramas tienen un nombre y una descripción. * El nombre debe ser descriptivo sobre lo que se va a trabajar en esta. * La descripción debe complementar al nombre. Para nosotros, una buena descripción es aquella que contiene cuales son los requisitos para que la funcionalidad se complete o cual es el objetivo de ella. Así, cuando se haya cumplido se podrá *mergear* con su *rama padre*. ## 2. ¿Cómo trabajamos en Abstract? En este apartado compartiremos como utilizamos Abstract en el equipo, cual es nuestra metodología, nuestras pautas y procedimientos ante los distintos proyectos. A este proceso hemos llegado tras trabajar meses con la herramienta, pero para cada equipo y proyecto pueden funcionar de forma distinta. ### 2.1 Commit {% hint style="info" %} ✏️ Un commit puede entenderse como una actualización de los archivos de Sketch en un momento de tiempo determinado, de forma que recoge todos los cambios que se han realizado hasta ese momento. {% endhint %} **¿Cuándo realizamos un commit?** En el estudio, distinguimos entre tres tipos de *commits*, que representan tres momentos en los que se debe realizar un commit. * Cada vez que se complete una tarea. Esto nos permite llevar un control sobre cuándo se llevó a cabo y cuales fueron los cambios realizados para completarla. * En las ramas de concepto, a lo largo de la fase de exploración, realizamos un *commit* cada vez que se cambia de dirección. * Al finalizar el día. Siempre, cada uno de las personas del equipo debe hacer commit antes de cerrar el ordenador e irse a casa. Esto nos ayuda a que cualquiera pueda continuar el día siguiente con el trabajo, en el mismo punto que se dejó el día anterior. {% hint style="info" %} ✏️ Las tareas coinciden con las tareas marcadas en [Asana](https://github.com/mendesaltaren/product-design-handbook/tree/e6917bdfb723014dd2c5e3ef24be95efb32f5370/tools/tools/asana.md), que es donde reflejamos el roadmap y las tareas a realizar en un proyecto. {% endhint %} **¿Cómo se realiza un commit?** {% hint style="info" %} ✏️ Para hacer un commit habrá que clicar sobre *Preview and Commit* en la bar que sale la parte inferior en Sketch. Al seleccionar esta opción, se cargan todas las pantallas añadidas o modificadas en Abstract para poder visualizar los cambios que se han realizado. {% endhint %} Para completar el commit, hay que incluir un nombre y una descripción de este. El nombre y la descripción nos dan contexto para cuando queramos visualizar *commits* anteriores, y que sean los suficientemente claras es especialmente útil cuando queremos retroceder a un punto concreto. El nombre debe ser descriptivo y la descripción contener los cambios realizados. Una buena práctica para dar nombre al *commit* realizado es: * Si el *commit* se realiza tras haber completado una tarea, el nombre debe coincidir con el \[**nombre de la tarea]**. * Si el *commit* se hace por haber finalizado el día, el nombre debe seguir la siguiente estructura: **Avanzar con \[nombre de la tarea]**. * Si el commit es en una rama de exploración, el nombre debe describir los cambios realizados Para nosotros, la descripción es una lista de cambios que se han realizado entre un *commit* y otro. Para que esta sea clara y fácil de entender por todos los miembros que formamos el equipo utilizamos la siguiente nomenclatura: ``` ✅ [Acción] [Donde se producido la acción] ``` **Un ejemplo sería:** ``` ✅ Añadir [artboard] ✅ Añadir [symbol] ✅ Añadir [página] ✅ Cambiar [módulo] ✅ Cambiar [symbol] ✅ Eliminar [módulo] ✅ Eliminar [página] ✅ Cambiar [página] ``` ### 2.2 Merge Cuando *mergeamos* estamos unificando el archivo de Sketch. Al *mergear* volvamos todos los artboards y páginas en los que hemos estado trabajando y hemos realizado cambios al archivo que se encuentra en la *rama padre* desde la que hicimos la rama. Nosotros hacemos *merge* cuando se completa el objetivo para el cual fue creada la rama en la que estábamos trabajando. Como por ejemplo, tras completar una funcionalidad. Cuando *mergeamos* una rama, Abstract nos da la opción de incluir detalles. Esto es importante cuando hay comunicar información al equipo sobre los cambios realizados en la rama, y queremos que esta quede reflejada. Puede ocurrir que se modifique un mismo *artboard* o un mismo símbolo en distintas ramas. Cuando esto ocurre, Abstract nos obliga a seleccionar con que opción nos quedamos. Es importante que esta decisión se tome junto con el equipo que esté participando en el proyecto, y comunicar finalmente cual es la decisión. ### 2.3 Añadir comentarios Abstract nos permite añadir comentarios sobre los distintos elementos de un archivo de Sketch. Esto nos ayuda tanto a la comunicación interna como a la colaboración con el cliente y su equipo. ### 2.4 Crear nuevo proyecto en Abstract Cada proyecto en el que trabajamos en el estudio, forma parte de un proyecto distinto en Abstract. Los proyectos en Abstract tienen un nombre, una descripción y un color asignado. * Para el nombre, mantenemos el nombre del proyecto tenemos en Dropbox. De esta forma, conseguimos mantener consistencia en las distintas herramientas con las que trabajamos. * La descripción es interesante y recomendable que refleje la descripción del proyecto y sus objetivos a alcanzar. * El color sirve como identificador visual del proyecto, por lo que es bueno que este sea el color principal de este. ### 2.5 Crear un nuevo archivo en Abstract Para mantener los procesos, creamos los de Sketch direcamente en Abstract. Abstract, nos permite crear archivos de Sketch o bien librerías de Sketch. Las librerías que creamos en un proyecto quedan automáticamente vinculadas con todos los archivos que contenga este. La **nomenclatura** de nuestros archivos de Sketch siguen el siguiente formato: ``` [id archivo][tipo de archivo][Plataforma] ``` **Un ejemplo sería:** ``` 01_Research 02_UX_Web 02_UI_Web 02_UI 02_UI_App_Android 02_Design-System ``` {% hint style="info" %} ✏️ Para conocer más sobre como nos organizamos y cual nomenclatura de archivos que seguimos puedes encontrarlo en **1. Cómo nos organizamos**. {% endhint %} # Sketch ## Sketch Sketch es la herramienta principal del estudio. Sketch forma parte del día a día del estudio, con la cual se diseña en la mayoría de los proyectos. En este apartado se detalla cómo utilizamos Sketch, la organización que seguimos y los plugins que utilizamos. ## 1. Organización La organización básica de nuestros archivos de Sketch se basa en páginas, *artboards*, símbolos y estilos compartidos. ### 1.1 Páginas En nuestros archivos de Sketch se pueden encontrar tres tipos de páginas, en función de su contenido y del estado de este. **Páginas en proceso 🔩** Las páginas en proceso son sobre las que se está trabajando. En estas se itera sobre un mismo *artboard* o elemento. Consideramos importante diferenciar las páginas en las cuales no hay diseño acabado porque se está trabajando sobre ellas. Son páginas en las cuales el contenido no tiene que ser perfecto. **Páginas** ***master*** **✅** Las páginas *master* contienen el contenido acabado. El contenido de esta página debe estar perfecto, contar con estilos aplicados, estar formadas en base a componentes y respetar los espaciados definidos. **Página de símbolos (*****Symbols*****)** En la mayoría de nuestros proyectos, esta página **únicamente aparece cuando el archivo se trate de una librería,** la cual contiene sistema de diseño de nuestro producto. ![Nomenclatura que usamos en las páginas de Sketch](/files/-LNkC0dszzpcRGbFeCA8) {% hint style="info" %} Esta es nuestra organización, no tiene porqué ser siempre así, pero esta es la que nos ayuda a nosotros a resolver conflictos sobre que páginas están listas y sobre cuales se está trabajando. {% endhint %} Para reflejar estos tres tipos de páginas y mantener los archivos de Sketch consistentes en todos los proyectos definimos que todas las páginas deben contar con un identificador visual, un identificador numerico y un nombre descriptivo de su contenido. Siendo su nomenclatura: ``` [Emoji] [nombre página] ``` * Emoji: utilizamos ✅ para páginas master y ⚙ para páginas en proceso. Un ejemplo sería: * ✅ Account * ✅ Catalog * ⚙️ Profile ### 1.2 Artboard Nosotros agrupamos los *artboards* en flujos o historias de usuario. Cada fila representa un posible flujo de la aplicación o de la web que se esté diseñando. Al principio de cada fila existe un *artboard* que contiene el nombre y una descripción del flujo que representan los *artboards* de dicha fila. Para nombrar los artboards utilizamos un identificador, que se corresponde con el de la página, y un número que se compone con el número de fila y el número de vista. ``` [id]_[numero fila][número vista] ``` * El id hace referencia al id de la página ✏️ Si la página es 01 Account → id página: 01 * El número de fila hace referencia al número de flujo en el que estemos situados Un ejemplo sería: Primer flujo → número fila: 1 Segundo flujo → número fila: 2 Tercer flujo → número fila: 3 * El número de vista será incremental de izquierda a derecha. ✏️ Si 01 02 03 04 05 06 07 08 09 10 11 12 Un ejemplo sería: Para los flujos en la página en 01 Account: * 01\_100 01\_101 01\_102 01\_103 * 01\_200 01\_201 01\_202 01\_203 01\_204 * 01\_300 01\_301 01\_302 01\_303 ### 1.3 Símbolos Utilizamos símbolos para optimizar y automatizar trabajo, los símbolos nos facilita el cambio en múltiples componentes simultáneamente. La raíz de los símbolos en Sketch está situada en una Librería de Sketch, vinculada archivo de Sketch en el que estamos trabajando. El uso de librerías nos permite que todos los archivos de Sketch de un mismo proyecto compartan componentes y evitar duplicidades que nos lleven al error. {% hint style="info" %} ✏️ Para conocer más sobre como trabajamos con símbolos y componentes puedes leer **4. Sistemas de diseño**. {% endhint %} ### 1.4 Estilos compartidos Trabajamos con dos tipos de estilos compartidos, estilos de texto y estilos de capa. Normalmente estos van a residir en la librería en la cual se encuentra el sistema de diseño de nuestro proyecto, y se aplicarán en el archivo en el que estemos trabajando. Los estilos, como los símbolos y componentes, nos ayudan a evitar inconsistencias y duplicidades. **Estilos de capa** Entre los estilos de capa podemos diferenciamos entre color, opacidad y sombras. * Color Los estilos de texto deben coincidir con la paleta de colores del producto. Estos los creamos tanto en color fill como en outline. * Opacidad (*Opacity*) Nosotros aplicamos las opacidades al grupo contenedor del elemento o elementos que se quiere que tengan una opacidad determinada. Así, controlamos que opacidades se utilizan en el proyecto. Eso nos permite actualizar estilos de capa y texto sin perder las diferentes opacidades que tengan las instancias de dicho estilo. * Sombras (*Shadows*) **Estilos de texto** En todos nuestros archivos, los textos tienen que tener un estilo de texto asignado. Esto nos ayuda a mantener la consistencia en el archivo y en el producto. ## 2. Sketch plugins A continuación se detallan 5 plugins de Sketch que nos facilitan el día a día en trabajando con la herramienta 🚀. ### 2.1 [**Sketch Runner**](https://sketchrunner.com/) *Sketch Runner* nos ayuda a buscar *todoloqueimagines* dentro de Sketch, aplicar estilos e insertar símbolos. ![Captura de pantalla del modal de Sketch Runner](/files/-LNkC0dwUAjZ8neP9hA5) Sketch Runner permite: * Ejecutar plugins * Instalar plugins * Ir a cualquier página, artboard, grupo o *layer* en el documento de Sketch que nos encontramos * Insertar símbolos * Crear símbolos * Crear estilos de texto y estilos de capa * Aplicar estilos de texto y estilos de capa * Actualizar plugins obsoletos ### 2.2 [**Automate Sketch**](https://github.com/Ashung/Automate-Sketch/) Algunas de las cosas que puedes hacer con este plugin y que nos hacen el día más fácil son: * Remplazar fuentes (*Replace Fonts*) * Importar estilos de una librería (*Import Styles from Library*) * Reemplazar símbolos con símbolos de una librería (*Replace Symbol with Library Symbol*) * Renombrar instancias de símbolos (*Rename Instances*) * Seleccionar capas por estilo de capa o por estilo de texto (*Select Layer by Layer / Text Style*) * Redimensionar artboards para que se ajusten a la altura de las capas y grupos que contiene (*Resize to Fix Height*) ### 2.3 [**Rename It**](https://rodi01.github.io/RenameIt/) *Rename It* permite: * Renombrar capas (*Rename Selected Layers*) * Renombrar *artboards* (*Rename Artboards*) * Remplazar palabras por otras (*Find and Replace*) Para nosotros es muy útil porque nos permite añadir secuencias de números de forma ascendiente o descendiente de forma automática, lo que nos permite nombrar los *artboards* fácilmente. ![Captura de pantalla de la ventana de Rename It](/files/-LNkC0e0FNid1a0RTxuW) ### 2.4 [**Sketch Style Master**](https://github.com/aparajita/sketch-style-master) Es igual que *Rename It*, pero para estilos de texto. Es realmente útil ya que te deja cambiar el nombre de los estilos de texto y remplazar palabras de estos. ![Captura de pantalla de la ventana de Sketch Style Master](/files/-LNkC0e2EBURPvFP_zhx) ### 2.5 [**Sketch Style Inventory**](https://github.com/getflourish/Sketch-Style-Inventory) Una de las grandes ventajas de este plugin es poder sacar todos los estilos de texto que existen en el archivo. Al ejecutar el plugin, *Sketch Style Inventory* crea una página con todos los estilos de texto que haya. ![Captura de pantalla del modal de Sketch Style Inventory](/files/-LNkC0e4eatLjAU9RsyD) Es realmente útil cuando se necesita cambiar alguna característica de los estilos, ya que de esta forma podemos asegurar que el cambio se ha aplicado a todos los estilos de texto. *Sketch Syle Inventory* también puede generar todos los colores y símbolos presentes en el archivo de Sketch, incluso exportarlos. ### 2.6 [**Sketch Page Numbers**](https://github.com/getflourish/Sketch-Style-Inventory) Este plugin permite añadir numeración a los artboards en Sketch de tal forma que estos se numeran según el orden en el que aparecen en el listado de capas (también pueden numerarse en orden inverso). ![Captura de pantalla de la ventana de Sketch Page Numbers](/files/-LNkC0e6L_Q84vDFvRdX) Es de gran ayuda sobre todo a la hora de diseñar documentos en Sketch como brandbooks o presentaciones de conceptos. # Figma Figma nos permite trabajar de forma colaborativa, online y en tiempo real. Además, Figma nos permite realizar todo el proceso que realizamos en Sketch. Figma es una gran alternativa para realizar ejercicios de ideación y definición cuando el equipo no puede estar de forma presencial. {% hint style="info" %} El porqué utilizamos más Sketch que Figma es porque con Sketch nuestro proceso está mucho más automatizado gracias a los plugins y más controlado gracias a Abstract. {% endhint %} Figma es una gran alternativa para realizar ejercicios de ideación y definición cuando el equipo no puede estar de forma presencial. En cuanto a cómo trabajamos con Figma el proceso se mantiene igual que el que realizamos en Sketch. ## Páginas En nuestros archivos de Figma se pueden encontrar tres tipos de páginas, en función de su contenido y del estado de este. **Páginas en proceso** ⚙️ Las páginas en proceso son sobre las que se está trabajando. En estas se itera sobre un mismo *frame* o elemento. Consideramos importante diferenciar las páginas en las cuales no hay diseño acabado porque se está trabajando sobre ellas. Son páginas en las cuales el contenido no tiene que ser perfecto. **Páginas** ***master*** **✅** Las páginas *master* contienen el contenido acabado. El contenido de esta página debe estar perfecto, contar con estilos aplicados, estar formadas en base a componentes y respetar los espaciados definidos. **Página de componentes (*****Components*****)** Donde residen los componentes que componen el sistema de diseño. {% hint style="info" %} Esta es nuestra organización, no tiene porqué ser siempre así, pero esta es la que nos ayuda a nosotros a resolver conflictos sobre que páginas están listas y sobre cuales se está trabajando. {% endhint %} Para reflejar estos tres tipos de páginas y mantener los archivos de Sketch consistentes en todos los proyectos definimos que todas las páginas deben contar con un identificador visual, un identificador numerico y un nombre descriptivo de su contenido. Siendo su nomenclatura: ``` [Emoji] [id] [nombre página] ``` * Emoji: utilizamos ✅ para páginas master y ⚙️ para páginas en proceso. * Los identificadores numéricos serán números incrementales precedidos por un 0. Un ejemplo sería: * ✅ 01 Account * ✅ 02 Catalog * ✅ 03 Profile * ⚙️ 03 Profile ## Frames Nosotros agrupamos los *frames* en flujos o historias de usuario. Cada fila representa un posible flujo de la aplicación o de la web que se esté diseñando. Al principio de cada fila existe un *frame* que contiene el nombre y una descripción del flujo que representan los *frames* de dicha fila. Para nombrar los artboards utilizamos un identificador, que se corresponde con el de la página, y un número que se compone con el número de fila y el número de vista. ``` [id]_[numero fila][número vista] ``` * El id hace referencia al id de la página ✏️ Si la página es 01 Account → id página: 01 * El número de fila hace referencia al número de flujo en el que estemos situados Un ejemplo sería: Primer flujo → número fila: 1 Segundo flujo → número fila: 2 Tercer flujo → número fila: 3 * El número de vista será incremental de izquierda a derecha. ✏️ Si 01 02 03 04 05 06 07 08 09 10 11 12 Un ejemplo sería: Para los flujos en la página en 01 Account: ``` 01_100 01_101 01_102 01_103 01_200 01_201 01_202 01_203 01_204 01_300 01_301 01_302 01_303 ``` ## Components Utilizamos componentes para optimizar y automatizar trabajo, ya que nos facilita el cambio en múltiples componentes simultáneamente. En Figma, los componentes pueden pertenecer al archivo o pertenecer al *Team Library.* El *Team Library* es el repositorio de componentes compartidos por todas las personas que pertecezcan al equipo. En nuestro caso, la *Team Library* es compartida por todos los archivos de mendesaltaren. Los componentes en Figma no son lo mismo que los símbolos en Sketch. Al utilizar un componente se crea una instancia y no una copia de este. Esto permite que las propiedades de color y texto de los elementos que componen una instancia se pueden cambiar, lo único que no se puede modificar es la posición. ## Estilos compartidos **Estilos de color** Una peculiaridad de Figma con respecto a Sketch es que no tiene estilos de capa como tal, sino que son estilos de color únicamente. Los estilos de color se pueden aplicar tanto en bordes y los rellenos de una capa como en los estilos de texto. Esto, para nosotros tiene dos ventajas claves: * No tenemos que crear tantos estilos de capa, diferenciando entre cuando es un borde (*outline*) y cuando se trata de un relleno (*fill*). * No tenemos que crear un estilo de texto por cada color que se vaya a utilizar. Creamos unos estilos de texto base y sobre estos aplicamos estilos de color definidos. **Estilos de texto** Los estilos de texto también difieren en cuanto a cómo son los estilos de textos en Sketch. En Figma para cada estilo de texto únicamente queda reflejado el tamaño, la altura de caja y el peso. La alineación puede ser modificada. Esto nos permite que cada vez que creamos un estilo de texto, no haya que crear uno distinto para cada alineación (izquierda, centro y derecha). Únicamente creamos uno y al utilizarlo lo modificamos. # Zeplin Con Zeplin conseguimos estrechar el gap entre diseño y desarrollo. Para garantizar que lo que está en Zeplin es el diseño final, únicamente subimos los archivos que están en la rama *Master* del proyecto en Abstract. ## 1. Crear un proyecto nuevo en Zeplin Los proyectos en Zeplin se crean de acuerdo a la siguiente nomenclatura para mantener la consistencia entre los nombres de los proyectos en las distintas herramientas. ``` [id proyecto][Nombre del proyecto][Plataforma] ``` * El campo de plataforma es opcional. Nos sirve para concretar si los artboards que contiene dicho proyecto son de web o de app iOS o Android . Por ejemplo, si crearamos un nuevo proyecto en Zeplin para exportar el diseño de Playtomic Web: * id proyecto → 19 * Nombre del proyecto → Playtomic * Plataforma → Web ``` 19_Playtomic_Web ``` {% hint style="info" %} ✏️ Para conocer más sobre como nos organizamos y cual nomenclatura de archivos que seguimos puedes encontrarlo en [**1. Cómo nos organizamos**](/organization). {% endhint %} ## 2. Preparar Sketch para subir a Zeplin Marcar elementos necesarios como exportables para desarrollo. Estamos hablando de los assets del proyecto como los iconos o las imágenes. ## 3. Exportar los *Artboards* o *Frames* La forma de exportar las vistas dependerá de si trabajamos con Sketch o con Figma. **Sketch** Si estamos trabajando con Sketch, al descargarnos Zeplin se nos ha descargado un plugin de Sketch, el cual utilizaremos para realizar la exportación. **Figma** Para exportar los *Frames* desde Figma debemos activar Zeplin dentro de Figma y posteriormente utilizar el comando Option+E con los *frames* que queramos exportar seleccionados. Este comando activará la activación a Zeplin de forma automática. # Marvel Utilizamos Marvel para prototipos rápidos. Nos permite testar y compartirlo fácilmente. {% hint style="warning" %} Para utilizar Marvel directamente desde Sketch es necesario tener instalado [este plugin](https://help.marvelapp.com/hc/en-us/articles/208594489-Sketch). {% endhint %} Para organizar los proyectos en Marvel utilizamos la siguiente nomenclatura: ``` [id proyecto][Nombre del proyecto][id archivo][tipo de archivo][Plataforma]_[Variación] ``` * El campo de plataforma es opcional. Nos sirve para concretar si el contenido del proyecto corresponde a web (desktop o mobile) o a app (iOS o Android) . * El campo de variación es opcional. Nos sirve para concretar que se va a testar en ese flujo. Por ejemplo, si se realiza un prototipo para testar a nivel wireframe la navegación de Fastti el nombre debe ser: id proyecto → 18 Nombre del proyecto → FASTTI id de archivo → 03 Tipo del archivo → UX Plataforma → Web-Desktop Variación → Navegacion Por ejemplo, si se realizase un prototipo para testar la navegación del proyecto Fastti, el nombre quedaría: * id proyecto → 18 * Nombre del proyecto → FASTTI * id de archivo → 03 * Tipo del archivo → UX * Plataforma → Web-Desktop * Navegación → Navegación ``` 18_FASTTI_03_UX_Web-Desktop_Navegación ``` {% hint style="info" %} ✏️ Para conocer más sobre como nos organizamos y cual nomenclatura de archivos que seguimos puedes encontrarlo en [**1. Cómo nos organizamos**](/organization). {% endhint %} # Notion Notion es la herramienta de documentación que utilizamos en el estudio. En Notion se reflejada tanto la organización interna del equipo como la organización de proyectos. Por ello distinguimos entre dos páginas principales, Team Home y Proyectos. En Team Home se documenta todo lo relacionado con la gestión de los miembros del equipo y recursos útiles para el día a día del estudio. En la página de Proyectos se recogen tanto los proyectos antiguos como los proyectos que se están llevando a cabo. Esto nos permite tener los proyectos documentados y todos los recursos disponibles necesarios en un proyecto centralizados en un único lugar. ## 1. Organización de un proyecto Todo proyecto es una página, consideramos que es importante que esta siga una plantilla concreta, de forma que todos los proyectos contengan la misma información, y cualquier miembro del equipo pueda acceder fácilmente a ella. Nuestros proyectos contienen: * **Link a Asana** En Asana se controlan las tareas y el roadmap del proyecto. * **Responsables del proyecto** Nombre de las personas involucradas y rol que tienen en el proyecto. * **Deadlines** Fecha de inicio y fecha de fin del proyecto. * **Enlaces importantes** El enlace a Dropbox es imprescindible, ya que es donde se encuentran todas las carpetas de los entregables y recursos necesarios para el proyecto. Cada proyecto requiere unos enlaces distintos. Lo que intentamos con esto es que todos los enlaces importantes y necesarios para el proyecto están en un mismo lugar, y puedan ser encontrados fácilmente. * **Goals** En este apartado se mostrarán los objetivos del proyecto de forma que todo el equipo conozca la dirección, resultados esperados y objetivo final del proyecto. {% hint style="info" %} ✏️ Los objetivos del proyecto se definen con el cliente al inicio del proyecto. Puedes conocer más sobre nuestro proceso en **2. Proceso**. {% endhint %} * **Servicios** Los servicios de cada proyecto también se acuerdan con el cliente al incio del proceso, en la propuesta. Estos pueden revisarse a lo largo del proyecto, añadiendo nuevos o eliminando existentes, en función del proceso del proyecto. Ejemplos de servicios serían: * Branding * Wireframing * UX * UI * Sistema de diseño * Prototipado en bajo nivel * Prototipado detallado de interacción * **Reuniones** Cada reunión que se realiza a lo largo del proyecto se documenta. Esto nos permite recurrir a ella cuando se crea necesario. Para llevar a cabo la documentación de una reunión, contamos con una plantilla. En función de como se desarrolle este se puede incluir información adicional a esta información básica. {% hint style="info" %} Esta es la plantilla que utilizamos en el estudio para documentar las reuniones [Meeting \[Descripción Breve\]\[Fecha\]](https://www.notion.so/mendesaltaren/Meeting-Descripci-n-Breve-Fecha-aaad9a2a12084d96bd327fa7e433e5ce) {% endhint %} Tener los proyectos siguiendo esta estructura en Notion nos permite tener los proyectos documentados de una forma clara y todos los recursos disponibles necesarios para un proyecto centralizados en un único lugar. {% hint style="info" %} Esta es la plantilla que utilizamos en el estudio para documentar cada proyecto [\[Nombre Proyecto\]](https://www.notion.so/mendesaltaren/Nombre-Proyecto-8c43290643bd4382bf0cede77d334dc0) {% endhint %} # Asana En Asana está reflejado el roadmap de cada proyecto y las tareas a realizar. Asana nos permite tener esta información organizada de forma clara y sencilla para utilizarla en el día a día por todos los miembros del estudio. ## 1. ¿Cómo trabajamos en Asana? ### 1.1 Proyectos Para cada proyecto mantenemos su id y su nombre, para mantener la consistencia a través de todas las herramientas que utilizamos. ``` [id Proyecto]_[Nombre del Proyecto] ``` Por ejemplo, si crearamos un nuevo proyecto en Asana para Playtomic: * id proyecto → 19 * Nombre del proyecto → Playtomic 19\_Playtomic {% hint style="info" %} ✏️ Para conocer más sobre como nos organizamos y cual nomenclatura de archivos que seguimos puedes encontrarlo en **1. Cómo nos organizamos**. {% endhint %} Cada proyecto tiene su propia sección donde están: * Tableros Permiten visualizar tareas. * Timeline El timeline representa el roadmap del proyecto. Este roadmap se establecejunto con el cliente en la propuesta. * Calendar * Conversations * Progress Permite ver las tareas que se han completado y las que quedan por hacer. * Files Permite ver todos los archivos adjuntados a las tareas. ### 1.2 Tableros Los tableros contienen las tareas. Las tareas a realizar las definimos al inicio del proyecto y las vamos desgranando y complementando estas según se va avanzando. Un tablero se forma por columnas y tareas. Las columnas representan el estado en el que se encuentra una tarea. Para nosotros las tareas pueden tener 5 estados distintos: Backlog, Sprint Backlog, In progress, QA, Completed. * **Backlog** Al inicio de un proyecto se añaden a Backlog todas las tareas derivadas de las funcionalidades y servicios acordados con el cliente en la propuesta. Todas las nuevas tareas que surgan a lo largo del proyecto, se incluirán a esta columna, para posteriormente decidir cuando se van a llevar a cabo. * **Sprint Backlog** Cada lunes, en la Planning semanal nos reunimos todo el equipo para concretar que tareas se completaran de la semana y definir el alcance. {% hint style="info" %} ✏️ Puedes conocer más sobre nuestra organización en [1. Cómo nos organizamos.](/organization) {% endhint %} * **In progress** Para poder coordinarnos, es muy importante que cuando un miembro del equipo comienza una tarea determinada, la mueva a esta columna. Esto permite al resto del equipo conocer qué tareas se están realizando. * **QA** Cuando se completa una tarea, esta pasa a QA para poder ser revisada por el líder del proyecto. * **Completed** En esta columna se sitúan todas las tareas completadas y revisadas por el responsable del proyecto. Esto asegura que todas las tareas han sido completadas con éxito. ### 1.3 Tareas Cada proyecto se descompone tareas globales que corresponden con los servicios y funcionalidades a realizar. A su vez, cada tarea global la desgranamos en tareas más pequeñas que nos ayudan a completarla. Para que las tareas realmente ayuden en nuestro flujo de trabajo, debe describir la acción que implica realizar. Nosotros, definimos las tareas con acciones. Un ejemplo sería, en lugar tener una tarea llamada *Sistema de diseño*: * Documentar Sistema de Diseño * Crear Sistema de Diseño Esto permite que la persona a quien se le asigne la tarea sepa qué es lo que tiene que realizar. Además de contar con un nombre descriptivo, Asana nos permite detallar las tareas con: * **Nombre** * **Descripción** La descripción nos permite incluir detalles necesarios para que cualquier persona que no sepa nada del proyecto pueda completarla. Para dar contexto a una tarea: * Se pueden mencionar a personas o a otras tareas mediante @. * Incluir enlaces importantes * Subir archivos Si se cambia el deadline de una tarea incluimos en la descripción el porqué del cambio y se notifica a las personas correspondientes. * **Proyecto al que pertenecen** * **Deadline** El deadline debe ser realista y objetivo teniendo en cuenta los objetivos del proyecto, y el resto de las tareas marcadas. * **Persona encargada** Cada tarea únicamente puede estar asignada a una persona. Y todas las tareas deben estar vinculadas a la persona que debe llevarlas a cabo. Es el líder del proyecto el que asigna la tarea a un miembro del proyecto. * **Followers** Como cada tarea solo puede estar asignada a una persona en concreto, se incluyen *followers* de la tarea cuando implique a varias personas. Al ser *follower* se reciben notificaciones cuando su estado cambie.