Archivo de la etiqueta: Agile

Principios Lean UX para guiar el proceso

Tiempo de lectura: 3 minutos

Una vez que hemos hablado qué cultura y organización debe existir en la empresa y los equipos, vamos a ver cómo deben trabajar.

Trabaja en bloques pequeños para reducir el riesgo

Otro principio fundamental heredado de Lean Manufacturing es la práctica de dividir el trabajo en pequeñas unidades, en su caso con el objetivo de reducir el inventario y obtener la máxima calidad.

Trasladado a Lean UX significa que sólo la cantidad de trabajo necesario se realizará para poder avanzar hacia delante, validando la hipótesis y continuando el desarrollo en base a lo aprendido. Con ello contribuimos a otro de los principios, el de reducir el desperdicio.

Descubrimiento continuo

Para realizar este proceso debemos involucrar al usuario o cliente en el proceso durante la fase de diseño y desarrollo de las ideas.

Muchas veces (en el caso de que se haga) este contacto, en vez de hacerse de forma regular se realiza al final, con el trabajo ya desarrollado. Por ello se deben definir encuentros seguidos mediante métodos cuantitativos o cualitativos que permitan obtener el feedback para la validación.

Descubrimiento continuo

El objetivo es claro: entender que hacen los usuarios con tus productos y por qué lo están haciendo.

Por ello la investigación debe hacerse de forma regular y con todo el equipo implicado.

Este segundo punto (con todo el equipo implicado) es muy importante ya que normalmente sólo los UX Research hacen esta parte teniendo posteriormente que explicar los resultados al resto del equipo.

Al introducir a todo el equipo en la investigación consigues 3 cosas:

  1. Que desarrollen una mayor empatía por el usuario y sus problemas
  2. Entendimiento compartido de lo que ocurre y por que luego se van a tomar ciertas decisiones.
  3. Reducción de la necesidad de generar documentación que explique los descubrimientos de la investigación

GOOB (Getting out of the building)

Con esta expresión que significa literalmente “salir fuera del edificio”, Steve Blank, profesor de Stanford, quiere conseguir que los equipos salgan fuera de las salas de reuniones con sus interminables divagaciones y suposiciones, y que den a los potenciales usuarios la oportunidad de proveer feedback real tan pronto como sea posible.

Gracias a esta dosis de realidad verás que ideas no funcionan antes de malgastar más recursos en ellas.

Exponer el trabajo

Con este principio, se quiere que las ideas salgan de la cabeza o de las pantallas de las personas y se pongan a la vista de todo el equipo. Esto permite ver el estado del trabajo, creando un flujo de información compartida, de nuevas ideas y sugerencias que surgen en base a lo visto…

Sigue leyendo Principios Lean UX para guiar el proceso

Principios Lean UX para guíar la organización de equipos

Tiempo de lectura: 4 minutos

Los principios en los que se basa Lean UX se agrupan en 3 bloques. Cada uno sirve para guiar:

  1. La organización de equipos
  2. El proceso
  3. La cultura

Gracias ellos iremos viendo las ventajas que conlleva implementar Lean UX en tu organización y como esta se modificará conviertiendose en un lugar abierto, transparente, que aprovecha el conocimiento y la entrega de todos para conseguir los mejores resultados.

En ellos se basarán las herramientas y técnicas para lograr mejorar la colaboración, lograr entregar mejores productos y servicios de forma más rápida y con el menor gasto de recursos usando los conocimientos de todos los implicados y basando las decisiones en pruebas reales.

Y es que como dice Jeff Gothelf en su libro Lean Startup: “Get out of the deliverables business”, en castellano: olvidémonos de centrar el negocio en las entregas y centrémonos en los que de verdad importa, hacer disfrutar a nuestros clientes con una experiencia memorable.

Principios Lean UX para guíar la organización de equipos

Equipos multifuncionales

Con esta palebreja lo que se refiere es que los equipos deben estar formados por aquellas personas con conocimientos necesarios en ese momento del proceso: desarrolladores, product management, testers, diseñadores visuales y de interacción, gestores de contenidos, marketing…

Para crear un gran producto es necesaria la suma de todos los conocimientos y la colaboración entre todas las disciplinas.

El todo es mayor que la suma de sus partes

Cuando un equipo está formado por personas de diferentes perfiles, se obtienen mejores soluciones ya que cada problema es visto desde un punto de vista diferente, aportando una gran diversidad.

Los miembros del equipo además están en contínuo contacto, por lo que poseen todo el conocimiento de lo que está sucediendo y lo que va a haserse al contrario que en organizaciones donde todo esta compartimentado. Gracias ello conseguimos una gran colaboración desde el inicio del proyecto logrando una mayor eficiencia de equipo, y trabajadores mucho más implicados en el proyecto.

Equipos pequeños, dedicados y juntos

Lo ideal: no más de 10 personas, focalizadas en el mismo problema y a ser posible en la misma ubicación. ¿Por qué?

Los equipos muy grandes tienen problemas para organizarse y compartir la misma información.

Los equipos pequeños generan un mayor sentimiento de camadería lo que genera mayor implicación en el proyecto y en las personas que lo están creando juntas.

Building a team

Imagen obtenida de aquí

Trabajando además en el mismo y único proyecto se consigue que estén centrados al máximo en las mismas prioridades y elimina las odiosas dependencias sobre otros equipos.

Autosuficientes y con poder para decidir

Si queremos obtener de forma rápida algo con lo que poder testear una suposición necesitamos que el equipo tenga todas las capacidades necesarias para trabajar sin dependencias externas.

Sigue leyendo Principios Lean UX para guíar la organización de equipos

Poka-Yokes, heurísticos de usabilidad y affordances

Tiempo de lectura: 2 minutos

Un poka-yoke (en japonés, ポカヨケ), es un término japonés que significa: Poka: “error no intencionado, equivocación…” y Yoke: “evitar”, es decir, “evitar equivocaciones”.

Es una técnica de calidad que se aplica con el fin de evitar errores en la operación de un sistema, introducida por el ingeniero japonés Shigeo Shingo en Toyota (1960), basada en que la causa de los errores estaba en los trabajadores, y que los defectos en las piezas fabricadas se producían porque no se corregían.

Anteriormente ya existían precedentes de poka-yokes, pero fue en ese momento cuando se consolidó este método como una técnica preventiva de control de calidad.

Para Shingo, los defectos de producción son la consecuencia de la cadena de errores generados por los trabajadores, por lo que no tenía sentido analizar el producto final cuando el defecto se producía durante el proceso de trabajo.

Es decir, el buscaba mejorar la calidad en su origen, actuando sobre la fuente del defecto, en lugar de tener que realizar correcciones, reparaciones y controles de calidad posteriores.

Para ello ideo 2 métodos sobre los que basarse para mejorar el proceso de trabajo y evitar errores.

  1. Control: Conseguir la imposibilidad o la dificultad de que el operario pueda equivocarse en proceso diseñando un sistema que lo impida (¿Te suena el término “affordance” introducido en el campo de HCI por Donald Norman en 1998 (propiedad en la cual las características físicas de un objeto o entorno, influencian en su función y uso)?).
  2. Advertencia: asumiendo que el error puede suceder, se diseña in dispositivo que dirija la atención hacia él para reaccionar y poder corregirlo.

¿No os suena esto a los principios heurísticos de usabilidad?

  • Conocimiento del estatus del sistema: el sistema debería siempre mantener a los usuarios informados de lo que está pasando, ofreciendo feedback en un tiempo razonable.
  • Control y libertad del usuario: cuando elegimos funciones del sistema por error necesitamos una “salida de emergencia” sin tener que ir a través de una serie de pasos complicados.
  • Prevenciones de errores: mejor que buenos mensajes de error, lo ideal sería un diseño que previniera que ocurrieran los problemas.

Hoy en día, es muy común ver dispositivos diseñados a prueba de error, no solo dentro de una empresa de producción o de servicio, sino en nuestro día a día, siendo una ventaja para todos los usuarios, ya que además de evitarse errores, pueden salvar vidas.

affordance

Imagen extraída de http://www.pdcahome.com/poka-yoke/

¿Algunos ejemplos?

Sigue leyendo Poka-Yokes, heurísticos de usabilidad y affordances

Cambiando la metodología de trabajo (o al menos intentarlo)

Tiempo de lectura: 4 minutos

He trabajado en varias empresas que querían modificar su proceso de desarrollo de producto. Algunas (2013) querían implantar una nueva metodología (Agile en este caso) y otras ya la tenían, pero necesitaban un pequeño reajuste para adecuarla a su cultura de empresa.

Y es que desde mi punto de vista, cualquier metodología o proceso de trabajo tiene sus herramientas e indicaciones, pero no siempre sirven al 100%, sino que debe adaptarse a lo que la empresa necesita en ese momento.

Son una base sobre la que trabajar para encontrar el proceso que realmente funcione para cada grupo de trabajo.

En ambos casos las empresas contrataron los servicios de una persona que facilitase y guiase el cambio. En una el proceso duraba X meses, para luego la empresa continuar por su cuenta con lo aprendido, mientras que en la otra la fase de implantación duraba X meses, pero prosiguiendo después el trabajo con el facilitador.

Es decir, (o por lo menos lo que yo creo que es lo ideal) esa metodología por la que se estaba apostando no era algo cerrado, inmutable para siempre, sino que seguiría evolucionado en el tiempo.

En ambas empresas, como muchos imaginaréis, el proceso no fue sencillo.

Para mi existen 2 puntos claves en el proceso:

  1. ¿El cambio viene impuesto desde arriba o es algo en lo que todo el equipo cree y apuesta?
  2. Como en cualquier materia, la constancia y repetición son claves para hacer algo bien.

Si el cambio viene impuesto desde la dirección, va a ser muy difícil que suceda si los principales implicados no lo aprueban. El facilitador se va a encontrar con un muro muy difícil de romper, no digo que imposible, pero muy complicado.

Lo ideal es partir de una base en la que la mayor parte cree que es necesario el cambio porque lo existente no funciona. O funciona pero podría ir mejor.  Pero aun siendo algo querido por todos, cambiar unas costumbres suele ser muy complicado.

No olvidemos que estamos trabajando con personas.

Personas que pueden llevar 5, 10, 15, 20 años trabajando de una misma forma. Personas que han luchado por sacar adelante un proyecto. Personas que no se han sentido escuchadas. Personas que van agobiadas porque tienen unos plazos de entrega. Personas con un baggage emocional hacia la empresa y otros compañeros.

Sigue leyendo Cambiando la metodología de trabajo (o al menos intentarlo)

Getting Things Done® (GTD®)

Tiempo de lectura: 3 minutos

Getting Things Done® (GTD®) es una metodología para ser más productivo sin estrés. Escrita por David Allen y publicada en un libro en 2001, en un principio estaba dirigida a  altos directivos, pero su uso puede ser aplicado a cada aspecto de tu vida.

Your mind is for having ideas, not holding them®

(David Allen)

Se basa en la idea de que nuestra mente es para generar ideas, no para mantenerlas, con lo que sino almacenamos de forma correcta las ideas, pensamientos… que vamos teniendo, el espacio que ocupan no permitiendo entrar a otras o el miedo a olvidarnos de ellas, nos genera un entimiento de estrés constante.

Más que un conjunto de consejos para la gestión del tiempo y la organización, GTD® es un sistema de gestión total. Allen crea un modelo coherente para almacenar elementos clave, los cuales aun pueden ser necesarios para nosotros, tanto para su uso futuro como presente.

En este mundo de información, constantemente nos están llegando nuevos datos, proyectos, ideas… que procesar que se suman a los que ya teníamos. El propósito de su proceso de gestión de flujo de trabajo es facilitarnos el hacer buenas elecciones sobre lo que estamos haciendo en ese momento.

GTD Diagram

Regla de los 2 minutos

A mi modo de ver, lo que cuenta Allen es de sentido común, y seguramente muchas de las cosas ya las haceis en vuestro día a día. Un ejemplo muy sencillo es la regla de los 2 minutos descrita en el diagrama superior.

La idea es muy sencilla. Cuando algo te llega, lo primero que te preguntas es si puedes hcer algo con eso. Si la respuesta es si, piensas en cual es la siguiente acción que quieres hacer con eso. Y si esa acción te cuesta menos de 2 minutos, la haces en ese momento, sino la delegas o la pospones apuntándola en un calendario si es para hacer en una fecha específica o en tu sistema de siguientes acciones.

GTD® en 5 pasos

La metodología se basa en 5 pasos que son los que naturalmente suceden en nuestra mente con las acciones más simples, solo que muchas veces lo hacemos de forma automática (Natural Planning Model) y no le ponemos nombres.

Sigue leyendo Getting Things Done® (GTD®)

Esto va de siglas: PMBOK® vs SCRUM

Tiempo de lectura: 3 minutos

Últimamente, durante este pasado año, he estado leyendo bastante sobre gestión de proyectos. Como en todo, hay un montón de información, con siglas y definiciones que pueden volver loca a cualquier persona.

En esta caso nos centraremos en las referidas a PMBOK® y SCRUM, cuyo error más común es pensar que PMBOK® es una metodología de gestión de proyectos, cuando es un estándar que recoge “the best practices”, es decir, las mejores prácticas del sector.

Es el Project Manager quien decide que procesos aplica, con que nivel de detalle y ver que metodología escoge para la gestión, ya sea ágil como SCRUM o tradicional.

Web de Scrum.org

Imagen de la web de srcum.org

No son opciones excluyentes, sino complementarias, gestionando un proyecto teniendo en cuenta el marco definido en el PMBOK® pero aplicando metodologías ágiles para su desarrollo.

Más lío viene aun cuando nos metemos en el tema de certificaciones con tantas siglas ya que dependen de la entidad que las gestiona:

  • Certificación PMP® (Project Management Professional) del PMI®
  • Certificación PMI-ACP® (PMI Agile Certified Practitioner) del PMI®
  • Certificación PSM I (Professional Scrum Master) de Scrum.org

The Scrum Framework

SCRUM, por su parte es un método de gestión de proyectos con un enfoque ágil, especialmente útil en proyectos de desarrollo de software, pero que también se puede aplicar a otro tipo de proyectos y sectores. Aquí puedes descargarte de forma gratuíta la guía de Scrum escrita por Ken Schwaber and Jeff Sutherland, las persona que definieron el método.

Igual que SCRUM encontramos otras metodos ágiles como:

  • Extreme Programming (XP)
  • Lean Development
  • Kanban Development
  • Feature Driven Development (FDD)
  • Dynamic systems development method (DSDM)
  • Crystal Clear

Scrum.org ofrece entre otras la Certificación Professional Scrum Master™ (PSM) con 3 niveles de evaluaciones profesionales Scrum Master (fundación, intermedio y avanzado) que validan y certifican sus conocimientos de Scrum y la capacidad de aplicar ese conocimiento.

PMBOK® (Project Management Body of Knowledge)

El PMBOK®, en castellano, Guía de los fundamentos para la dirección de proyectos, es un estándar de gestión de proyectos que recoge las mejores prácticas del sector, gestionado y actualizado periódicamente por el PMI®.

Actualmente se encuentra en su 5ª Edición, y su 6ª Edición, se publicará oficialmente en septiembre de 2017.

Sigue leyendo Esto va de siglas: PMBOK® vs SCRUM

Meetup de Juegos y dinámicas ágiles

Tiempo de lectura: 3 minutos

El pasado día 7 de junio nos juntamos en las oficinas de Flywire para una nueva reunión del grupo de Agile Levante, organizado por Emma López (@hell03610).

El taller consistía en la realización de dos dinámicas lúdicas, aprendiendo de ellas diferentes tipos de problemas que surgen en entornos de desarrollo.

Comunicación y visión compartida

La primera dinámica se realizaba en parejas. Una persona era el constructor y la otra el gestor (creo, no recuerdo muy bien los nombres). La idea era cambiar en base a los roles que ejecutamos en nuestro día a día para entender el papel de la otra persona.

Juegos agile

Emma le dio a cada gestor unas instrucciones para hacer una figura de origami (la conocida ranita) para que se las dictará al constructor. El constructor, apoyado en una mesa, con un folio, y de espaldas al gestor, no podía verlas no podía tampoco hablar con el gestor.

Así mismo el gestor tampoco podía ver lo que iba haciendo el constructor en base a sus indicaciones, con lo cual, imaginaos lo que salió de ahi. Ningún equipo consiguió finalizar algo similar a una ranita 🙁

En la segunda ronda, el gestor podía ver lo que realizaba el constructor e ir guiándole en consonancia a los pasos que daba. En este fase, sólo 2 equipos acabaron las ranitas.

Y en la tercera ronda, tanto el gestor como el constructor, veían las instrucciones. El gestor ayudaba al constructor guiándole y explicándoselas. En este caso todos los equipos acabaron las ranitas y a una mayor velocidad.

De este juego, se extrae la importancia de compartir todos los miembros del equipo la misma visión, y que está quede de alguna manera reflejada de una forma visual, ya que las palabras dependiendo de quien las interprete pueden tener diferentes significados.

Y es como dice Dani Latorre en este post sobre Una de BDD, Specification by Example y Cucumber: “Muchos problemas cuando desarrollamos software surgen de los malentendidos de comunicación entre los diferentes miembros del equipo.

Estimación, competitividad y la importancia del testeo

En el segundo juego nos dividimos en 2 equipos. Emma nos dio 3 tipos de aviones diferentes a construir en papel, cada uno en folios de un color. Dependiendo de su dificultad cada tipo valía unos puntos u otros.

En una reunión inicial, debíamos decirle cada equipo, cuantos aviones de cada tipo íbamos a entregarle en los 4 minutos de tiempo para construir que disponíamos con el requisito imprescindible de que pasasen su test de vuelo.

Ahí, ya cometimos el primer error. Estimamos pensando en que TODOS iban a volar, es decir, el número de aviones que íbamos a construir en los 4 minutos no tenía que ser el mismo que el numero de aviones que iba a pasar el test.

Y lo que es peor, nos pusimos a hacer aviones como locos, sin probar antes que alguno volase (Hola?? TESTEO!!), para en el caso de que no lo consiguiesen, introducir alguna mejora. Emma no nos había especificado que no podíamos cambiar los diseños, simplemente dimos por hecho que no podíamos hacerlo.
Sigue leyendo Meetup de Juegos y dinámicas ágiles

Elementos de un sistema de diseño

Tiempo de lectura: 2 minutos

Seguimos con la serie de artículos de cómo crear un buen sistema de diseño, primero vimos por qué eran útiles y segundo las características de un buen sistema de diseño. Continuamos con este artículo sobre qué debe contener un sistema de diseño.

Como comenta el libro Lean UX, “Si está hecho de pixels va en el sistema de diseño“.

Todos los componentes, con la definición de su aspecto visual e interacción, el código necesario para insertarlo, sus clases, selectores, modificadores… deberían estar en el sistema.

iOS Design System

Ejemplo de Search Bars en el Sistema de Diseño para iOS

Qué aspecto visual tiene el elemento

Detalles sobre el tamaño mínimo y máximo, restricciones verticales u horizontales, color, estados (active, inactive, hover….)….

Dónde se coloca normalmente en la pantalla

Especifica claramente si un elemento sólo puede estar ubicado en ciertos lugares de la pantalla, así como posibles excepciones.

Sigue leyendo Elementos de un sistema de diseño

Características de un buen sistema de diseño

Tiempo de lectura: 4 minutos

Continuamos el post anterior sobre los sistemas de diseño hablando sobre qué características definen a un buen sistema de diseño. Y es que existe más de una manera de crear un buen sistema de diseño, y las elecciones dependen de los objetivos y las capacidades que se tengan. No en todos los casos se requiere ya que el esfuerzo y la inversión es grande.

  • ¿Es necesario para tu organización?
  • ¿Qué objetivos debe cubrir tu sistema de diseño?
  • ¿Es importante la adopción generalizada?
  • ¿Cómo de grande es lo que necesitas desarrollar?
  • ¿Trabajan múltiples equipos en ello?

Por ejemplo, si eres una empresa pequeña que necesita una ecommerce puede que no necesites hacer un sistema de diseño propio, sino que te bases en uno ya creado, o que con una imagen con los principales componentes sirva. Pero si eres una empresa que necesita desarrollar por ejemplo, múltiples aplicaciones internas, si que es conveniente un sistema de diseño más complejo que de soporte a todos los equipos de trabajo.

Web Guide Components

Resumen visual y con estilos de componentes mínimos

He estado en empresas que habían invertido mucho dinero en crear sistemas de diseño para cada dispositivo (movil, desktop, tablet…), y existían dos principales problemas:

  1. El ritmo de mejora del sistema era demasiado lento para las necesidades reales de los diseñadores y desarrolladores de aplicaciones. Cuando se lanzaba una mejora o se introducía un componente nuevo, las aplicaciones antiguas no podían usarlo.
  2. El sistema no era fácil de usar, estando por un lado la GUI de componentes que explicaba su estilo visual y de interacción, y por otro las indicaciones de como insertar y usar los elementos. Además estas indicaciones no estaban bien explicadas.

Esto conllvaba a que los equipos de desarrollo al final preferían hacer los componentes de cero que buscarlos en el sistema. Eso conllevaba un gasto de recursos enorme, aparte de que era imposible mantener la consistencia en las aplicaciones.

Para que eso no ocurra, sigue las siguientes recomendaciones:

Ten en cuenta lo que los usuarios necesitan

Problema:

Si el sistema no tiene en cuenta los elementos que se puedan necesitar para desarrollar el producto, lo que se acaba consiguiendo es que los equipos desarrollen sus propios componentes, sin que estos estén integrados y revisados por los encargados de mantener la coherencia y excelencia del sistema.

Solución:

Recuerda que los usuarios en este caso es todo el equipo de desarrollo de producto: diseñadores, developers, QA…. todos se basarán en el sistema de diseño para realizar su trabajo. Inclúyelos en el equipo que lo desarrolle haciendo que los contenidos del sistema contemplen sus necesidades.

Mejora contínua

Problema:

Cómo tratar las actualizaciones del sistema es un tema importante. Si sólo se lanza 1 actualización grande al año, o cada año y medio, se genera una gran brecha entre las necesidades que tienen los equipos de diseño y desarrollo de aplicaciones y los componentes del sistema.

Además si al lanzarse la actualización, las aplicaciones creadas con los componentes anteriores dejan de tener soporte, sin poderse actualizar de forma sencilla, conlleva a 2 cosas:

  • Al soporte de múltiple sistemas de diseño en paralelo (Horror!!)
  • A aplicaciones ancladas en un sistema viejo que no podían mejorarse a no ser que se rehicieran enteras (Más horror!!)

Lo ideal es que cuando se actualizase un componente, este se pudiera cambiar de forma sencilla en cada lugar donde se haya aplicado, para que el elemento sea el mismo en todos los lugares donde esté, existiendo coherencia en su uso y en el diseño. Si cada vez que se lanza una versión de un componente nuevo las aplicaciones creadas anteriormente se desactualizan, y no están al día, se acaban teniendo diferentes interfaces en base a cada actualización.

Solución:

Un sistema de diseño es un elemento vivo. Debe ser la “única fuente de verdad” de la organización. Si el producto evoluciona tambián lo debe hacer el sistema. Debe ser bastante maleable y añadir mejoras de forma sencilla, habiendo determinado un proceso claro de actuación para esas mejoras.

Cuando un nuevo elemento o mejora de uno existente sea añadido al sistema, debe estar disponible para su uso en las formas que sean necesarias, estando el código disponible, el diseño gráfico, las especificaciones…

El sistema es accesible

Problema:

Un buen sistema de diseño debe ser fácil de usar para los desarrolladores para que sólo necesiten encontrar el elemento que necesitan e insertarlo en el código, desarrollando sólo el back.

Si los usuarios no saben como acceder, o no encuentran de forma sencilla los elementos, o las indicaciones de como insertarlos no son las adecuadas, el sistema deja de cumplir su función.

Solución:

Accesibilidad significa que todo el mundo en la organización puede acceder al sistema.

  • Fácil de acceder: usa una URL que sea fácil de recordar y asegúrate que todo el mundo la conozca.
  • Fácil de encontrar los elementos: el sistema debe poseer un índice, un campo de búsqueda, una nomenclatura clara y consistente que ayude a los usuarios a encontrar lo que necesitan.
  • Fácil de usar: Sino lo es nadie lo usará y todo la inversión no habrá valido la pena.

Propiedad

Problema:

Si no existe un responsabl claro  del sistema cuando surja un problema, una duda, una sugerencia de mejora… los equipos no sabrán a quién acudir, decidiéndo por su propia cuenta cuestiones que atañen a toda la organización.

Solución:

El sistema debe tener asignada una persona como encargada de él, ya sea un equipo, un product owner… Pero debe quedar claro quién es el responsable de mantenerlo adaptado y de a quien deben acudir el resto de los equipos.

¿Has desarrollado un sistema de diseño? ¿Te has encontrado con problemas? Cuéntame que opinas para conocer cual es la mejor forma para desarrollarlos y gestionarlos.

A continuación veremos qué elementos debería contener un sistema de diseño.

Ejemplos de sistemas de diseño

Sistemas de diseño

Tiempo de lectura: 3 minutos

Los sistemas de diseño (como dice Jeff Gothelf y Josh Seiden en su libro Lean UX) son como “Guías de estilos con esterorides”. Usados tanto en compañías privadas (Mail Chimp y Salesforce, entre otras) como por entornos públicos (Gov.ukU.S. Web Design Standards, por ejemplo) presentan grandes beneficios.

Salesforce Lightning Design System

Imagen de Salesforce Design System

Antiguamente existían las llamadas brand guidelines, es decir, Manuales de marca o Manual de estilos de la marca, documentos impresos donde se explicaban la imagen de marca y como usarla. A veces tenían varias páginas pero normalmente eran documentos muy extensos. Cuando se digitalizaron se convirtieron en PDF, páginas web o wikis. Al mismo tiempo, algunas publicaciones tambien desarrollaron manuales que cubrían guías de como escribir o presentar la documentación.

Un ejemplo de la versión de estos manuales en el mundo de los ordenadores es la famosa Human Interface Guidelines (HIG) de Apple, un extenso documento que explica cada componente del sistema operativo de  Apple, ofreciendo reglas y ejemplos de su uso.

Por otro lado, los desarrolladores son familiares con las librerías de componentes, colecciones de reusables elementos que poseen la intención de hacer el trabajo más fácil proveyendo elementos de código ya testeados, y reusables que se encuentran almacenados en un repositorio de código.

Es decir, una vez desarrollados estos componentes (su parte visual y de interacción), múltiples equipos pueden usarlos las veces que deseen para construir elementos más complejos sin necesidad de hacerlos cada vez.

Un sistema de diseño funciona como una única fuenta de verdad para la capa de presentación de un producto.

Si se dispone de un buen sistema, los equipos pueden dibujar un sketch (boceto) y rápidamente desarrollarlo usando los elementos del sistema para crear el prototipo o producto preparado para su uso.

El valor de un sistema de diseño

Una vez creado, un equipo puede seguir evolucionando y mejorando el sistema, mientras otros equipos trabajan en paralelo desarrollando los productos (estructura, arquitectura de la información, flujo de trabajo…)

Ojo, que no hablamos de UI Kits.

Los sistemas de diseño permiten a los equipos:

  1. Diseñar más rápido porque no están inventando la rueda cada vez que diseñan una pantalla, sino que usan los elementos disponibles en el sistema.
  2. Prototipar más rápido porque los desarrolladores front usan directamente el componente que necesitan sin tener que construirlo cada vez.

Eso conselleva beneficios para las organizaciones:

Aumenta la consistencia

Cómo todos los equipos usan los mismos componentes el diseño resultante será consistente. Equipos distribuidos en diferentes lugares o incluso en distintas empresas basaran sus diseños y desarrollos en los mismos elementos, creando una imagen coherente de marca de empresa.

Mayor calidad

Centralizando la creación y el diseño de los elementos se aprovecha la destreza de los mejores diseñadores y desarrolladores de interfaz de usuarios. El resultado de gran calidad, es empleado por otros menos especializados para producir proyectos de alta calidad.

Menor coste

Un buen sistema de diseño cuesta dinero. Requiere inversión para construirlo y mantenerlo. Pero con el tiempo y sobre todo si son muchos los equipos que lo usan, la inversión se recupera al proporcionar herramientas y frameworks que permiten que los equipos de desarrollo sean más efecientes y productivos.

Las nuevas incorporaciones también serán antes productivas ya que disponen de toda la información en el sistema.

En el siguiente artículo hablo sobre que características definen a un buen sistema de diseño.

Ejemplos de sistemas de diseño