WordPress: ¿Barra lateral o Área de widgets? Una propuesta de traducción

A estas alturas deberíamos contemplar la opción de cambiar el ‘Barra lateral‘ por ‘Área de widgets‘. Evitaríamos algunas confusiones típicas en nuevos usuarios y/o clientes que veo las suficientes veces como para entender que hay un claro problema de concepto.

Entiendo que esta propuesta debería escalar a la versión en inglés modificando ‘Sidebar‘ por ‘Widgets area (o algo muy parecido). ‘Sidebar‘ se hereda del formato blog pero ¿no hemos dicho que WordPress es más que blogs? Es tiempo de revisarlo.

Desde el punto de vista de la maquetación web, el concepto ‘Barra lateral‘ no tiene sentido. Recordad: “Separar contenido de presentación”. Si es lateral, superior o inferior es circunstancial a la presentación. En maqueta podría ser un <aside> que colocaremos dónde veamos.

El Elemento HTML Aside (<aside>) representa una sección de una página que consiste en contenido que está tangencialmente relacionado con el contenido que le rodea, que podría ser considerado independiente de ese contenido. Estas secciones son a menudo representadas como barras laterales o como inserciones y contienen una explicación al margen como una definición de glosario, elementos relacionados indirectamente, como publicidad, la biografía del autor, o en aplicaciones web, la información de perfil o enlaces a blogs relacionados.

— Vía MDN Web Docs

Otra cosa que conseguiremos con la propuesta de nueva traducción es evitar que los usuarios confundan ‘Widget‘ y ‘Sidebar‘ (o al revés). Continente != Contenido. No es inusual que se creen confusiones cuando un cliente dice “Widget” refieriéndose a todo un “Área de widgets“.

Creo que quedaría mucho más claro porque se establece una clarísima relación que cualquier puede entender: “Área de widgets” y “Widgets“. Un área de widgets contiene, oh sorpresa, widgets. Llamando barra-nosequé o sidebar, al usuario más básico lógicamente no le quedará tan claro.

Para usuarios intermedios también supondría una ventaja. Es más fácil entender que pueden existir “infinitas áreas de widgets” que “infinitas barras laterales”. “Barra lateral” confunde porque laterales, como mucho, hay dos: izq/der (en contexto desktop, en mobile ni eso).

Mis alumnos del Máster Técnico en Diseño Gráfico, Web y Creatividad de Cámara de Comercio de Sevilla se extrañan al ver que pueden existir “infinitas barras laterales“. Sin embargo no choca que puedan existir “infinitas áreas de widgets”. Porque el concepto área no se hace referencia a una posición en la página, es un concepto de acotación (“contenedor”).

En fin, es solo mi experiencia con este concepto. No dudo que el equipo de traducción lo hace lo mejor posible y tienen en cuenta más contextos que quizás a mí se me estén escapando. Igualmente, votaría por eso cambio 🙂

WP Meetup: Primeros pasos para diseñar tu propio tema de WordPress

WordPress Aljarafe es la rama del marco de WordPress Sevilla que procura mimar la actividad de la comunidad WordPress entorno a dicha comarca. La primera meetup del nuevo curso 18-19 se celebrará el próximo día 24 de septiembre. El ponente un servidor y el tema va de temas, valga la redundancia: “Primeros pasos para diseñar tu propio tema de WordPress“.

Durante una hora intentaré ofreceros una guía de pasos esenciales para crear un tema de WordPress con nuestro propio diseño, prácticamente desde cero y con conocimientos básicos. Aunque la charla no está pensada en formato taller no dudéis en traer vuestros portátiles para cacharrear sobre la marcha.

Tras la finalización de esta charla, como en todas las meetups, tendremos oportunidad de conocernos más charlando de manera más informal en algún bar cercano.

Agradecemientos por su colaboración al Instituto Municipal de Dinamización Ciudadana del Excmo. Ayuntamiento de Mairena del Aljarafe, por la cesión del salón de actos de la Biblioteca José Saramago para la celebración de esta Meetup.

Resumiendo:

WordCamp Sevilla 2018: Una experiencia diferente

El fin de semana del  7 y 8 de julio se celebró en Sevilla la quinta (sí, tras 2011, 2012, 2013 y 2016 ya van cinco) WordCamp de la ciudad: WordCamp Sevilla 2018. No os cuento nada que no sepáis si estáis al tanto de los movimientos de la Comunidad WordPress España. Paso a relataros mi experiencia personal en este encuentro.

Mi relación con WordCamp Sevilla.

En el pasado ya os he contado mi estrecha relación con WordCamp Sevilla desde sus inicios —voluntario, diseñador, organizador, speaker (en flash talk) e incluso patrocinador en niveles modestos. No siempre he podido participar con la intensidad deseada, pero de una u otra manera siempre he procurado estar ahí porque no sólo hay comunidad detrás de todo esto, también hay amigos.

Mi charla “WordPress y Medios: diseñando la editorialización”.

WordCamp Sevilla 2018

En esta edición he participado como ponente con mi charla —nunca tengo claro si es más adecuado decir “charla” o “ponencia”, ninguno es cierto al 100%—, “WordPress y Medios: diseñando la editorialización”. Esta presentación ha sido muy importante para mi por varios motivos:

1. Nunca antes había estado en un track principal de la WordCamp de mi ciudad. Es cierto que en 2011 realicé una Flash Talk sobre HumansTXT, pero no estaba en la línea de ponencias principales. Me hacía ilusión jugar en casa 🙂

2. He convencido a un cliente como ABCdesevilla sobre la importancia de abrirse a la Comunidad, en la medida de lo posible. Trabajo con ellos desde 2013 (en los proyectos Gurmé y BulevarSur entre otros) y os garantizo que a nivel de desarrollo los productos que trabajan son potentísimos (ellos cuentan con sus propios desarrolladores). Con la excusa de hablar de la metodología de diseño que seguimos he podido abrir un poquito la tapa —hasta donde me dejaban— para devolver a la Comunidad lo que corresponde. Gracias, Javier Arias por hacer esto posible. Tienes toda mi admiración profesional, ya lo sabes.

3. Creo que es importante llevar a primera línea ponencias y charlas que hablen de diseño como un proceso serio y no una transición anecdótica entre la toma de requisitos y el desarrollo con WordPress. El diseño es un proceso integrador y conciliador entre equipos. Al menos, ese fue el argumento y la intención de mi charla. Si lo conseguí o no es algo que deben valorar los asistentes.

Además de participar como ponente, colaboramos con la organización desde Root dando soporte a nuestro fotógrafo de cabecera, Ruben Sutilo, que por el apellido los más espabilados habrán adivinado que es mi hermano. Alfombra roja para que el brother pudiera venir y tirar unos cuantos disparos. Aquí podeís ver todas las fotografías que hizo. La licencia que demanda una WordCamp os permite descargarlas y/o usarlas en vuestros perfiles.

WordCamp Sevilla 2018

WordCamp Sevilla 2018

WordCamp Sevilla 2018

WordCamp Sevilla 2018

Ponencias

En cuanto al resto del evento, no pude asistir a todas las charlas que me hubiera gustado debido a que tuvimos que dedicar mucho tiempo a organización del equipo y los proyectos aprovechando la presencia física de un equipo que trabaja de manera deslocalizada.

De hecho ni siquiera me pude quedar a la “foto de familia” porque este año, como novedad personal, tenía que volver pronto para encargarme de un pequeño  y adorable bichillo de dieciocho meses que tengo en casa 🙂

En cualquier caso, espero poder ver todas las ponencias en WordPress.tv próximamente. Si no pudiste acudir al encuentro, te recomiendo hacer lo mismo.

Menciones y agradecimientos.

Gracias a todos los asistentes a mi charla. Me sorprendió gratamente la cantidad de asistentes de todos los niveles interesados en lo que iba a contar. Espero haber cumplido las expectativas —aunque no estoy contento del todo con mi propio speech, aprenderé. Agradecería cualquier tipo de feedback al respecto. También estoy interesado en conocer si hay interes en este tipo de discurso, con idea de terminar de echar a andar mi canal de youtube, proyecto que sigo valorando.

Gracias al equipo de la organización por solventar rápido los problemas técnicos que tuvimos al principio. Gracias a Joaquín Ruiz, la sombra con más arte que un ponente puede llegar a tener.

Gracias a Ibon Azkoitia por su disposición a ayudar y por los tirones de oreja al vernos pasar tanto tiempo en la mesas de trabajo.

Gracias a Fernan Díez, además de por una charla útil y funcional, por una buena conversación sobre metodología de trabajo, organización de equipo, gestión de tareas. Este tipo de detalles es el oro oculto en una WordCamp. Espero que la vida te compense tu generosidad con más “family points” para gastar ;P

Gracias a Javier Casares por el esfuerzo de crear un hilo por cada una de las ponencias, prácticamente en directo. Aquí el tweet que marcar el inicio del hilo de mi charla:

Gracias Roberto y Mercedes por ser así. No hay que decir nada más. Creo que representais fielmente los valores de la Comunidad y la honestidad y dignidad sube de nivel cuando enfocáis los esfuerzos a ayudar a los más jóvenes, pensando en el futuro.

Y finalmente gracias a Mariano, Rafa, Rocío, Maribel… perdonadme si me dejo mucha gente fuera. En general gracias a todo el equipo de la organización por hacer una WordCamp magnífica en un tiempo récord.

Recordatorio: Carla sigue necesitando nuestra ayuda.

Ya os hablé del proyecto solidario WPCarla. Queda poco para alcanzar el hito. Si no has colaborado, puedes hacerlo a partir de un euro. Si ya lo has hecho, puedes mover el enlace o volver a aportar. Visita: https://wplovescarla.com/

WP♥Carla: Una iniciativa solidaria de la Comunidad WordPress España

Carla Sáiz (@LaPeceraDeFiu) es una profesional freelance, como muchos de nosotros. Carla, trabaja por y para esto de hacer webs, como tantos de nosotros. Carla abandera una tecnología como es WordPress (el sistema de gestión de contenidos más utilizado, supone el 30% de los sitios en Internet), como muchos de nosotros. Carla pertenece a lo que llamamos la “Comunidad WordPress“, como muchos entre los que me incluyo. También a Carla le han diagnosticado cáncer, como podría pasarnos a muchos de nosotros.

Durante los primeros tres meses tendrá que centrarse en el tratamiento, lo que la obliga a parar su actividad hasta poder retomarla. Muchos de nosotros, profesionales independientes, podemos entender y empatizar con el problema que supone esto —además de lo que la propia enfermedad supone, lógicamente.

Por eso la Comunidad WordPress se ha unido en esta campaña solidaria “WP♥Carla” para conseguir el dinero suficiente para que Carla, como profesional independiente, no tenga que preocuparse de esos meses en los que estará centrada en el tratamiento.

Esto revela a mi modo de verlo un par de hechos importantes a destacar:

1). Los autónomos seguimos totalmente desprotegidos cuando la situación va más allá del simple resfriado. La solución de costear esto desde el bolsillo propio (seguro privado, etc) sigue siendo un parche, especialmente cuando se mete en el mismo saco al autónomo que tiene una empresa que factura millones de euros anuales y al autónomo que con mucho esfuerzo supera el salario mínimo interprofesional mes a mes.

2). Pertenecer y participar en una comunidad tecnología aporta mucho más que contactos o conocimiento. Sin duda esto es lo más grande y humano que ha hecho la Comunidad de WordPress española hasta la fecha, aunque a los que llevamos un tiempo en esto tampoco nos extraña. Sólo hay que ir a una WordCamp —la próxima es en Sevilla, por cierto— para sentir y comprobar los valores que se trasladan, el ambiente que se vive y el tipo de persona —no ya profesionales, digo personas— que te puedes encontrar como norma. Es fácil sentirse orgulloso.

Espero a continuación muchas cosas. Una pronta mejoría para Carla. Y que el hito se cumpla. Y espero que no tengamos que volver a vivir un hecho similar pero, en caso de hacerlo, es grato saber que esta es la Comunidad de WordPress España que tenemos.

Link: WP♥Carla

Metodologías para ser feliz

Manos de equipo en el barro

Hoy de nuevo tuve otra gran charla con Luis Rull. Mutuamente aprendemos (problablemente yo más que él) sobre los problemas y soluciones en las metodologías de creación de productos digitales. Y cómo hay una base común a cualquier tipo de organización (grande o pequeña). La solución siempre pasa por lo mismo, hablemos de un freelance o una empresa de decenas de profesionales. Sin palabrería ni humo:

1) Reconocer el problema, identificarlo. ¿Es un problema de comunicación? ¿De conocimientos / competencias? ¿De compromiso? Todo estos aspectos tienen solución y herramientas para ello (apps, formación, estructura de roles) PERO sin identificar previamente no hacemos nada.

2) Tomar una decisión de solución y aplicarla. A fuego. Aquí suele fallar desde el freelance a la gran empresa. Es el “dejar de ir al gym porque tengo lío”, el “abandono la dieta por un disgusto”. Un clásico si se es humano. Si nos desviamos: reconocerlo y recuperar pronto.

3) Ser honestos y responder a la pregunta “¿Qué necesito para ser feliz en este proyecto (empresa)?” Esta para mí es la mejor enseñanza aportada por . Sobre todo para aquellos que somos de vieja escuela. Del “p’alante sí o sí“. Tenemos que aprender a levantar la mano.

Sin atacar y resolver esos puntos (no solo una vez, también de manera iterativa) cualquier equipo está condenado a la frustración. Eso es la antesala del fracaso. De ahí la importancia de estos puntos. Incluso si son valoraciones crudas. Con educación todo cabe en la mesa.

En resumen, las metodologías relacionadas con la creación de productos digitales están íntimamente relacionadas con los factores humanos dentro de un equipo de trabajo. Las soluciones no sólo pasan por la elección de herramientas y la gestión de competencias, también pasan por el equilibrio y el valor humano del equipo.

Espero Luis Rull no te moleste que haya compartido este pequeño fragmento de una conservación enriquecedora. Es curioso cómo se revela que parte más importante de una buena metodología de creación de productos digitales recae al final no en la herramienta sino en lo “humano”.

Y el que sea perfecto, que lance la primera pied… el primer smartphone.

Modern Web Event 2017

Modern Web Event” es un evento gratuito y sin ánimo de lucro organizado por la UOC (Universitat Oberta de Catalunya). La primera edición se celebró en 2015 y a lo largo de estas tres ediciones (Barcelona, Bilbao, Sevilla) profesionales de diferentes ramas del sector IT han compartido sus conocimientos.

El encuentro se dirije a todos aquellos que quieran aprender sobre las nuevas tecnologías web, de la mano de profesionales apasionados por compartir conocimiento en comunidad.

La edición de 2017 se celebró el día 6 de junio en Sevilla. Me invitaron a participar en esta edición ylo hice encantado con mi charla “Diseñadores, desarrolladores y viceversa”, en la que pretendía romper el viejo mito de que diseñadores y desarrolladores no se entienden.  Hablé de metodología y de cómo convertir a los desarrolladores en los mejores aliados asi cómo resultar para los mismos un perfil imprescindible en el flujo de trabajo.

Os dejo el vídeo de charla y también la presentación.

Una visión crítica de los frameworks CSS

Código HTML Bootstrap
Este texto pertenece a una colección de publicaciones que he programado bajo el marco de una Guía crítica de Componentes de la Interfaz de Usuario. Está dirigido principalmente a los alumnos del Máster de Diseño Web y Creatividad de la Escuela de Negocios de la Cámara de Comercio de Sevilla, pero también puede servir de ayuda a todo el que se inicia en el Diseño de Experiencia de Usuario y en el Diseño de Interfaz de Usuario. Los profesionales con más experiencia que se acerquen a este texto quizás no encuentren nada nuevo. No obstante espero que, en su caso, sirva como excusa para abrir debate sobre la cuestión.

Los llamados frameworks HTML, frameworks CSS o frameworks Responsive de código abierto proponen soluciones —discutibles, como ahora veremos— a aspectos de composición o diseño. Algunos frameworks de esta tipología destacados son Foundation, Bootstrap, Semantic UI, UiKit o Skeleton, por ejemplo.

El primer premio a la ausencia de diseño se lo llevaría, sin duda alguna, Material Design Lite. Se trata de una un framework CSS que emula la estética de las Android User Interface Guidelines con el objetivo de vencer la fricción del producto digital respecto al sistema operativo del dispositivo a toda costa, incluso sacrificando el diseño (personalizado). El producto se mimetizará con la apariencia del sistema operativo del dispositivo.

Tres puntos a favor de los frameworks CSS de código abierto.

Seré honesto: yo utilizo frameworks CSS. No en todo los proyectos, pero los aplico. Y no todo es malo en ellos siempre y cuando los recursos se gestionen adecuadamente. Desde los objetivos que perseguimos en esta colección de artículos —gestionar y diseñar mejor los componentes de la interfaz de usuario—, podemos destacar las siguientes ventajas de los frameworks CSS:

1. Los frameworks resultan altamente eficientes porque proponen una respuesta multicontexto (responsive) cuyo mantenimiento es mínimo. Los frameworks también responden a la filosofía DRY en el momento en que incluyen un catálogo de componentes predefinidos —predefinidos a todos los niveles: visual e interacción— que hacen posible encapsular los objetos.

2. El grid o rejilla es el recurso maestro, el cual sirve como hilo conductor para trasladar un visual estático hacia una maquetación responsive. Incluso el software para el diseño de experiencia de usuario tiene en cuenta este recurso, como hace por ejemplo Axure. El grid es un recurso visual que se hace tangible a través de hojas de estilo CSS. El grid propone una suerte de esperanto entre el diseñador (de experiencia y de interfaz) y el desarrollador, entre lo estático y lo líquido. El requisito básico de todo framework CSS es que su núcleo consista en una solución de desarrollo para el grid.

Ejemplo de grid
Ejemplo de grid creado con Gridulator

3. Gracias al listado de componentes, el lenguaje y la experiencia de usuario se ha normalizado. Todos los frameworks CSS contienen prácticamente los mismos componentes. Nombran a cada componente de manera similar. Casi todos los componentes se comportan de manera similar —por ejemplo, la forma en la que mostramos una ventana modal al usuario suele ser similar. He elaborado esta tabla comparativa de los componentes más significativos. Observad que en algunos casos siendo el mismo componente se nombran diferentes o tienen variantes:

Componente Foundation Bootstrap SemanticUI UIKit Skeleton
Button (Botón) (#) (#) (#) (#) (#)
Table (Tablas) (#) (#) (#) (#) (#)
Form (Formularios) (#) (#) (#) (#) (#)
Label / Badges (Etiquetas) (#) badge
(#) label
(#) badge
(#) label
(#) (#) badge
(#) label
Alerts (Mensajes contextuales) (#) Callout (#) Alerts
(#) Alerts JS
(#) Message (#) Alert
Breadcrumbs (Migas de pan) (#) (#) (#) (#)
Pagination (Paginación) (#) (#) (#)
Navigation bar (Menús de navegación) (#) Top bar (#) Navbar (#) Menu (#) Navbar
Dropdown (Selector de opciones desplegables) (#) (#) (#) (#)
Tooltip (Descripciones emergentes) (#) Tooltip (#) Tooltip

(#) Popovers

(#) Popup (#) Tooltip
Accordion (Acordeón) (#) Accordion Menú
(#) Accordion
(#) Accordion (#) Accordion (#) Accordion
Tabs & Pills (Navegación por pestañas) (#) Tabs (#) Nav (#) Tab (#) Tab
Slider (Deslizador de contenido) (#) (#) (#)
Modal (#) Reveal (#) Modal (#) Modal (#) Modal

En contra de los frameworks.

Tres puntos en contra de un framework CSS open source:

1. El abuso de frameworks empobrece visualmente los productos digitales. Hace ya varios años que gran parte de la comunidad de diseño viene advirtiendo el problema que supone que todos los productos parezcan lo mismo —en este enlace se refieren a sitios web, pero es aplicable a cualquier otro producto en cuya base se aplique un framework CSS. Este problema se atribuía originalmente a un abuso de tendencias de diseño. Transcurrido el tiempo necesario, queda claro que es un problema de fondo del modelo de producción actual como venimos comentando artículos atrás.

2. Adormece el potencial profesional y la calidad del producto. Está bien tener herramientas que nos permitan agilizar el arranque de productos. Está bien tener procesos predefinidos para no tener que perder tiempo en tareas repetitivas. El problema es que se trata el proceso completo de creación de un producto como una tarea repetitiva en sí misma. Especialmente cuando das servicios en lugar de trabajar en tu propio producto. Y eso, adormece a la bestia. El profesional se vuelve vago en una dinámica machacona —porque somos humanos ¿a quién no le pasaría?—. Eso hace que nos alejemos en el diseño de la diferenciación, la calidad y la excelencia en la creación de productos digitales.

3. Abre una brecha entre los diferentes perfiles. El mal hábito del template y el theme predefinido apartan al diseñador del proceso. Sea por ahorro en costes o el motivo random en lenguaje entrepreneur que prefieran, se crea una brecha que aleja al diseñador del código, algo totalmente pernicioso para el producto digital. La existencia de esta brecha es tan real que a día hoy la responsabilidad en la creación de una Guía de Estilos de Producto Digital recae sobre los desarrolladores antes que sobre los diseñadores, siendo estos últimos los verdaderos responsables de ese material.

Debo añadir en este punto que no todos los desarrolladores se sienten cómodos trabajando con estos frameworks. Desarrolladores como Belén Albeza (@ladybenko) defienden sólidos argumentos en contra. Esto ocurre también en un momento en que ciertos módulos de CSS muy esperados, como CSS Grid Layout, hacen su aparición en escena.

En la siguiente entrega vamos a ver todo lo relacionado con las Guías de estilo.

La década startup y las metodologías de diseño de interfaz

desarrollador trabajando en startup
Este texto pertenece a una colección de publicaciones que he programado bajo el marco de una Guía crítica de Componentes de la Interfaz de Usuario. Está dirigido principalmente a los alumnos del Máster de Diseño Web y Creatividad de la Escuela de Negocios de la Cámara de Comercio de Sevilla, pero también puede servir de ayuda a todo el que se inicia en el Diseño de Experiencia de Usuario y en el Diseño de Interfaz de Usuario. Los profesionales con más experiencia que se acerquen a este texto quizás no encuentren nada nuevo. No obstante espero que, en su caso, sirva como excusa para abrir debate sobre la cuestión.

Los desarrolladores front-end se han convertido en una figura clave a lo largo de la última década. Probablemente de los perfiles más solicitados y valorados. Una década que, no podemos olvidar, ha estado presidida por el modelo de startup [3]. Esto ha condicionando las tendencias de los modelos de producción.

El modelo de creación de productos digitales ha priorizado las demandas de los desarrolladores porque coincidía con la el modelo de startup:

  • Metodologías de trabajo que persiguen la eficiencia y resultados cortoplacistas.
  • Filosofía DRY (Don’t Repeat Yourself), que coincide con un modelo de mínima inversión.
  • Una orientación progresiva hacia la movilidad (productos digitales que se consumen en contexto mobile).

Priorizando estas ideas y otras similares orientadas al eficientismoojo, he consultado el término— los desarrolladores front-end y las tendencias tecnológicas han condicionado las metodologías de diseño. No sabemos si de manera consciente, pero es un hecho como ahora comprobaremos.

[3] Hace unas semanas Javier Cañada publicó “15 consejos para emprendedores que lidian con diseño y UX“. En el transfondo de este texto se adivinan los problemas hasta ahora señalados: una industria basada en el modelo startup que satisface las necesidades de los desarrolladores, orientando el modelo productivo exclusivamente a la creación de MPVs que levanten la inversión deseada. Lectura obligatoria.

Otro hecho a tener en cuenta que ha modificado y condicionado la metodología de diseño en la última década está íntimamente relacionado con el tercer punto sobre la movilidad:

1. El aumento de usuarios que demandan productos digitales en contextos móviles (tablets y smarphones) ha hecho que los diseñadores tengan muy presente los patrones de diseño de interfaz de los sistemas operativos de los propios dispositivos (iOS Human Interfaces Guidelines, Android User Interface Guidelines).

2. Plantear al usuario flujos de interacción o un diseño visual similar a lo que puede encontrar en su dispositivo, ha normalizado el lenguaje y la estética respecto a ciertos componentes (accordion, badge, breadcrumb, dropdown, form, list, modal, pagination, etc).

3. Utilizar la familiaridad de los componentes del sistema operativo es un viejo recurso del sector. Ayuda a vencer la fricción y estandariza las soluciones —lo cual, según cómo se enfoque puede ser mejor o peor para el resultado final.

Mobile gestures app prototype
iOS – New Gestures by Javi Pérez

 

Todas estas demandas, preocupaciones y tendencias sirvieron en su momento (2011) como caldo de cultivo perfecto para los frameworks CSS de código abierto a los cuales vamos a dedicarle el siguiente capítulo. Creedme, se lo merecen (para bien y para mal 🙂 )

Retrospectiva sobre la segmentación de perfiles en el diseño de interfaz

Atomic design
Este texto pertenece a una colección de publicaciones que he programado bajo el marco de una Guía crítica de Componentes de la Interfaz de Usuario. Está dirigido principalmente a los alumnos del Máster de Diseño Web y Creatividad de la Escuela de Negocios de la Cámara de Comercio de Sevilla, pero también puede servir de ayuda a todo el que se inicia en el Diseño de Experiencia de Usuario y en el Diseño de Interfaz de Usuario. Los profesionales con más experiencia que se acerquen a este texto quizás no encuentren nada nuevo. No obstante espero que, en su caso, sirva como excusa para abrir debate sobre la cuestión.

Con tantos grandes profesionales contribuyendo a la historia del diseño de producto digital a nivel mundial es complicado elaborar una cronología. Aunque, si tuviera que elegir, para mi el caso más evidente es la metodología Atomic Design (2013) de Brad Frost. Esta metodología está muy relacionada con el asunto que nos trae aquí, una mejor gestión y diseño de los componentes de la interfaz deusuario. La propuesta del Atomic Design es diseñar desde los componentes como piezas identificadas y extrapolables que dan paso a sistemas más complejos, escalables, mantenibles, multicontexto.

Me parece importante destacar que esta metodología fue inspirada a Brad Frost por Stephen Hay y su “We’re not designing pages, we’re designing systems of components“. Si seguimos hacia atrás, Stephen Hay argumentaba eso mismo a raiz de su propuesta “Responsive Design Workflow” (2012), una metodología que, supongo, estaba inspirada en el “Mobile Web Best Practices” (2008) del W3C.

¿Por qué propuso Stephen Hay ese flujo de trabajo? Probablemente porque a raiz del Diseño Web Responsive el trabajo de diseño de interfaz se duplicó y hasta triplicó en la última década. Es el coste de tener en cuenta los contextos básicos (desktop, tablet, mobile).

Un breve inciso. Esto generó un problema a nivel de negocio porque, aunque era evidente que se necesitaban diseñar más pantallas en más contextos, los precios del mercado no podían duplicarse o triplicarse por proyecto de la noche a la mañana. Al menos una pequeña empresa no se podía permitir esto. Por lo tanto, estas metodologías no sólo responden a flujos de trabajo más ordenados, coherentes, extensibles. También responden a esta demanda del mercado que obliga a ecualizar los costes. Continuamos.

A la ingente suma de pantallas a resolver en cada proyecto, debemos añadir que el trabajo de maquetación también se vio afectado. Las hojas de estilos en cascada (CSS) se complicaron. Mucho. En serio, muchísimo. En su extremo, esto se ha traducido en la implantación de los preprocesadores CSS. No por gusto, evidentemente. El objetivo siempre ha sido servir las soluciones a todos los contextos en los que un producto digital puede ser utilizado.

Llegado cierto momento era evidente la dificultad del diseñador para abarcar todo el proceso [1]. Creo que por todo esto —y muchas otras razones que comentaros más adelante— en la última década se ha producido una segmentación de los perfiles dedicados al diseño. Diseñadores UX, diseñadores UI y desarrolladores front-end [2] son algunos de los apellidos de diseñador más comunes en los que han aterrizado aquellos diseñadores-maquetadores primigenios (diserrollador, como dice mi colega Cristian Eslava).

[1] Debemos tener en cuenta que no hace demasiado tiempo el diseñador de interfaz también era “maquetador“. Esto sigue ocurriendo en muchos casos, sobre todo en empresas, equipos y proyectos pequeños, aunque a día de hoy la tendencia sea segmentar perfiles. Esta segmentación tiene su justificación en favor de la especialización, la cual responde a las demandas de tecnologías y mercado. No obstante, recordar que antes el profesional era “el mismo para todo” es algo que debemos tener en cuenta para comprender la evolución de la labor del diseño de interfaz.
[2] Hago referencia a diseñadores que dan un salto más profundo al mundo de desarrollo front-end. Sobra decir que, al margen de esto, ya existían perfiles dedicados exclusivamente al desarrollo front-end. Al igual que ocurre con los perfiles dedicados a la Experiencia de Usuario, en el desarrollo front-end confluyen perfiles de múltiples orígenes, además de los desarrolladores, digamos “de raza”, que siempre han ocupado esa posición.

En este recorrido por la segmentación del perfil, el diseñador se ha ido alejando del código. Es hora de recuperar esos súper poderes que originalmente te pertenecen, aunque quizás no lo sabías. ¿Te interesa? Allá vamos.