Smashing Podcast Episodio 9 con Stephanie Walter: ¿Cómo puedo trabajar con marcos de interfaz de usuario?

Como desarrollador, una de las cosas que me gustan de los marcos de interfaz de usuario es que a menudo vienen con un estilo predeterminado, pero ¿es algo en lo que deberíamos confiar en los proyectos? ¿Simplemente usando el estilo predeterminado y confiando en que quien produjo el marco ha hecho un muy buen trabajo en el diseño de esos componentes? Únase a mí para el episodio de podcast de hoy, donde hablo con la diseñadora de UX, Stephanie Walter, sobre las cosas que deberíamos considerar al crear un marco de interfaz de usuario.

Mostrar notas

• sitio web de Stephanie
• Estefanía en Twitter

Actualización semanal

• “Cómo crear un juego de combinación de cartas usando Angular y RxJS” por Anna Prenzel
• “Cómo crear un sitio de WordPress sin cabeza en JAMstack” por Sarah Drasner
• “Magic Flip Cards: Resolviendo un problema común de tamaño” por Dan Halliday
• "Puntos destacados de Django: Modelos de usuario y autenticación (Parte 1)" por Philip Kiely
• “Cómo crear mapas con React y Leaflet” por Shajia Abidi

Transcripción

Drew McLellan: es una diseñadora centrada en el usuario y experta en experiencia móvil, que cruzó productos e interfaces encantadores con un enfoque especial en el rendimiento. Ha trabajado en proyectos para clientes como la Universidad de Luxemburgo, el Banco Europeo de Inversiones, BMW y Microsoft, por nombrar solo algunos, y ayuda a esos clientes a entregar proyectos exitosos a su público desde la estrategia hasta el producto final. Es una desarrolladora de Google experta en diseño de productos y una profesora apasionada que comparte sus conocimientos en numerosas publicaciones de blog, artículos, talleres y presentaciones en conferencias. Sabemos que es una diseñadora experta en experiencia de usuario, pero ¿sabías que una vez tuvo un trabajo colocando alfombras con Sir Elton John? Mis amigos de Smashing, denle la bienvenida a Stephanie Walter. Hola Estefanía, ¿cómo estás?

Stephanie Walter: Hola, estoy genial y me encantó la introducción.

Drew: Así que quería hablarles hoy sobre un tema en particular y ese es el tema del uso de marcos de interfaz de usuario listos para usar. Ahora eres un diseñador de experiencia de usuario y trabajas con muchos clientes diferentes y tu trabajo es ayudar a esos clientes a crear las mejores experiencias de usuario posibles mediante la creación de interfaces de usuario altamente utilizables. Entonces, la idea de poder hacer eso con un conjunto de herramientas listas para usar me parece un poco exagerada. ¿Es el uso del marco de interfaz de usuario algo que ve mucho a lo largo de su trabajo?

Stephanie: Sí, es algo que he visto mucho, sobre todo en los últimos años porque empecé a trabajar con una agencia y ahora trabajo dentro de la empresa. Entonces, en esos equipos de tecnología de TI súper grandes y sí, en este momento hay muchas interfaces de usuario de framework como la que más he visto es Material-UI, básicamente Material design es un tipo de pautas de diseño de Google y cosas, y Material -UI es el equipo de Angular, pero también el equipo de React. Crearon su propio marco utilizando una especie de apariencia del diseño Material de Google. Pero ya no tiene nada que ver con Google. Es como ellos, no sé, creo que les gustó la apariencia. Por el momento, esos son los dos principales marcos de interfaz de usuario con los que trabajo. Y también hay algo llamado Ant Design, que se hizo bastante popular.

Stephanie: Es un marco React. No sé si tienen Angular también. Creo que fue hecho por un equipo en China. Y es interesante porque no solo proporciona los componentes, todo en React, sino que si vas a su sitio web también obtendrás los archivos borradores, lo que en realidad es bastante interesante porque motiva o ayuda al diseñador a construir o dar forma. la interfaz en los componentes de la interfaz de usuario utilizados por ese marco. Así que sí, es algo que he visto mucho, especialmente en grandes equipos de TI porque la mayoría de las veces no tienen un diseñador. Por el momento, soy básicamente un equipo de UX de un pequeño equipo en un banco de inversión europeo. Así que soy yo como diseñador UX. Trabajo con un equipo de desarrolladores, analistas de negocios, toda la gente buena, pero aun así soy un diseñador para todo el proyecto.

Stephanie: Hasta que yo llegué no había diseñador. Es una especie de solución implementada en muchas empresas, especialmente en productos internos, por ejemplo. Donde normalmente dicen, está bien, realmente no necesitamos un diseñador para eso. Solo necesitamos algo que funcione para nuestros usuarios internos y usemos un marco porque es conveniente para los desarrolladores. La mayoría de los componentes ya están allí y, dado que no tienen diseñadores en el equipo, está reemplazando, por así decirlo, el rol de un diseñador de interfaz de usuario. Sí, el problema con eso es que, está bien, entonces tienes los componentes, pero el rol del diseñador de la interfaz de usuario no es solo decidir si el botón debe ser rojo, verde, naranja, azul, lo que sea. Por lo general, el rol del diseñador de UI es la arquitectura de la información, entendiendo las necesidades del usuario. Así que todo lo que va más allá de la interfaz. Entonces, incluso si tiene este tipo de marco que se ocupa de toda la interfaz de usuario, visualmente lo que ve en la pantalla.

Stephanie: Todavía necesitas a alguien en algún momento para hacer el trabajo de entender qué ponemos en la pantalla, ¿cómo se va a comportar? ¿Qué sucede cuando hacemos clic aquí? ¿Cómo logra el usuario su objetivo? ¿Cómo vamos del punto A al punto B? Porque podemos usar un modelo, podemos usar pestañas, podemos usar todos los componentes. Es por eso que siempre es un poco complejo y complicado.

Drew: ¿Es posible? ¿Cree que podrá crear una interfaz de usuario utilizable utilizando un marco de interfaz de usuario estándar, o siempre va a ser un compromiso?

Stephanie: Espero que sí. Espero que sí porque de lo contrario estoy construyendo interfaces no utilizables. Entonces, esta respuesta es totalmente sesgada, pero sí, creo que lo es, pero también depende del nivel de compromiso que esté dispuesto a hacer y hay compromisos en ambos lados. Por el momento, estoy comprometiendo muchos botones, por ejemplo, porque tiene algunos botones muy específicos en Material-UI, y no me gusta mucho el efecto dominó en el botón. Creo que funciona muy bien en dispositivos móviles porque en los dispositivos móviles necesitas una especie de gran retroalimentación cuando el usuario hace clic o toca el botón. Pero luego los pasos son una especie de efecto dominó que llega hasta el botón. Es un poco exagerado, especialmente cuando hay muchos botones. Pero aun así vamos a mantener este efecto dominó porque sería muy complejo eliminarlo porque estaba integrado en el marco de React. Y para tener otro efecto de desplazamiento sobre este botón, algo más sutil que no será este tipo de silbido aquí. Sería súper complejo.

Stephanie: Así que este es el tipo de compromisos que haces. Pero mientras tanto, no me comprometo con cosas específicas que son componentes personalizados. Donde trabajaba antes, el cliente actual de una compañía de viajes y aerolíneas. Y la aerolínea tiene algunas necesidades realmente súper específicas. El calendario de la aerolínea por ejemplo, quieres poner precios, quieres poner… si no viajas a este destino en una fecha específica, no sabes cuándo poner eso, tienes esta salida y llegada y el calendario básico de la mayoría de esos marcos de interfaz de usuario no proporciona este tipo de cosas. Entonces, en algún momento puede decir, está bien, solo usaremos el calendario que tienen. Y eso es. Necesitas ir más allá de eso. Entonces, la mayoría de los compromisos se basan básicamente en, ¿utilizamos el componente básico? ¿Creamos uno personalizado que se ajuste a las necesidades del usuario? ¿O hacemos una mezcla de los dos? En el caso del calendario, por ejemplo, usamos la cuadrícula del calendario, así que usamos el componente básico y luego lo mejoramos con la personalización además de eso. Así que fue mucho desarrollo de React para eso.

Stephanie: Y sí, por lo general haces muchos compromisos.

Drew: Entonces, parece que usar un marco de interfaz de usuario puede ayudarlo a llegar hasta allí, pero para tener una buena interfaz de usuario como resultado, ¿necesita hacer un poco de personalización en la parte superior?

Estefanía: Por lo general. Si.

Drew: ¿Esa personalización va más allá de la temática?

Stephanie: Sí, mi desarrollador deseaba que no fuera más allá de la temática. Eugene Si me escuchas. Creo que estaría súper feliz si solo cambiáramos algunos colores en todo. Pero sí, en algún momento debe ir más allá de la personalización porque, en primer lugar, los marcos de interfaz de usuario son como las herramientas de Lego, es una especie de caja de herramientas. Así que tienes muchos componentes diferentes en la caja, pero esto no crea una página. Aún necesita un encabezado, aún necesita un pie de página. Todavía necesita contenido adicional que no estaba en el marco. Entonces, a veces puede ajustar un componente a lo que necesita. Por lo que entendí, estamos usando el componente de la tarjeta para construir una ventana modal, pero el problema con las ventanas modales es que en realidad no se comporta como una tarjeta.

Stephanie: Vas un poco más allá de eso. Necesitas un fondo con oscurecimiento. Debe activarlo al hacer clic cuando, por lo general, su tarjeta ya está en la interfaz. Así que estamos usando este componente de tarjeta porque tiene muchas de las cosas que necesitamos como el fondo, un encabezado y un título en la parte superior, algunos botones en la parte inferior. Así que tenemos la estructura y luego la modificamos un poco. Pero a veces terminamos con algún conflicto sobre la semántica, HTML también. Porque, por ejemplo, quería tener botones que no tuvieran formas de botones, así que simplemente como botón de enlace y el desarrollador dijo: "Está bien, entonces usamos un enlace como su enlace href". Dije: “No, esto no es un enlace. es un botón Cuando hacen clic en él, no abre una nueva página. Limpia todo lo que está dentro de la forma”.

Stephanie: Entonces, técnicamente, desde un punto de vista semántico, debería ser un botón. "Si. Pero no existe en el marco”. Yo digo: "Está bien, lo sé, entonces, ¿qué hacemos?" Por lo general, comienzas a discutir estas pequeñas cosas y, dado que también estoy molestando a mis desarrolladores con la accesibilidad, esta es otra capa adicional para tratar de asegurarnos de que tenemos los componentes básicos con los que funcionan bien. Pero también que son semánticamente como no quiero tener botones con gifs dentro de gifs dentro de gifs. De lo contrario, tendremos problemas al final.

Drew: Supongo que al comenzar un nuevo proyecto que utilizará un marco de interfaz de usuario, probablemente deba comenzar con algún tipo de investigación de usuario.

Estefanía: Sí.

Drew: ¿Es eso justo?

Estefanía: Deberías. Necesitas. Así que sí, normalmente puedes tener todos los componentes que quieras. Aún necesita saber qué necesitan sus usuarios en las páginas, ¿cómo van a navegar? Necesitas construir un flujo. Entonces, por lo general, incluso antes de decidir sobre un marco, lo que hacemos es acercarnos a nuestros usuarios, hablamos con ellos, tratamos de comprender sus necesidades. Así que en este momento tengo mucha suerte porque los usuarios están internamente dentro del banco. Así que hacemos muchos talleres con ellos y tienes que imaginarte que es una interfaz súper compleja. Estamos migrando de algo que se construyó, no sé, creo que hace 10 o incluso 15 años a algo completamente nuevo y brillante usando Material-UI React. Así que es un cambio bastante grande y hay que entender que durante esos 15 años, todos los que querían algo podían ir al soporte y luego le pedían al equipo de TI que lo implementara. Entonces, en este momento, mi interfaz es como 400 páginas con tablas, dentro de tablas, dentro de tablas, con otras tablas y cosas que ni siquiera deberían estar en tablas.

Stephanie: Tenemos muchas cosas que son solo valor clave, valor clave, valor clave. Entonces construyen la mesa con dos columnas. Estoy como, "No, tal vez podamos hacer algo mejor con eso". Entonces, en este momento, lo que estamos haciendo es investigar un poco a los usuarios para comprender los diferentes objetivos de los usuarios. Entonces, lo que identificamos es que lo que hacen con la interfaz, tienen algunos objetivos de planificación. Necesitan planificar su trabajo. Entonces quiero saber que esta operación va a ir a esta reunión, así que necesito eso en ese horario, cosas así. Quieren monitorear algo, quieren reportar los datos. Entonces, monitorear es como mirar los datos y asegurarse de que todo esté bien. Informar es poder explotar los datos, hacer algo con ellos que quieren compartir y colaborar con colegas y todo eso lo descubrimos discutiendo directamente con los usuarios.

Stephanie: Y lo que descubrimos es que, en realidad, algunas de las cosas que planeábamos migrar al final son algunas de las cosas más importantes a diario para el usuario. Por lo tanto, el objetivo del usuario de planificación es uno de los más grandes en este momento. Así que realmente estamos trabajando en eso. Entonces, sí, usamos la entrevista y ahora estamos en la fase en la que en este momento estamos en un nivel muy alto y decimos, está bien, necesitamos construir el caparazón, necesitamos entender la navegación. Pero por el momento no revisamos realmente todos los datos y esto es lo que vamos a hacer ahora. Y es interesante porque tenemos muchas tablas y dijimos que podemos ir de la manera no inteligente y simplemente poner las tablas en la nueva interfaz y hemos terminado, o podemos decir, está bien, tratemos de entender qué esas tablas son, ¿Para qué usan nuestros usuarios esta tabla?

Stephanie: Y luego, tal vez algunas de las tablas podrían mostrarse como visualización de datos y luego, para hacer eso, necesita comprender todo el negocio para que los datos tengan sentido. Entonces, si tiene un buen marco y dice, está bien, usemos este gráfico... creo que se llama marco JS de gráfico. Tienes muchas cosas, puedes tener histogramas, gráficos circulares y gráficos y todo, pero en algún momento todavía necesitas un diseñador que te ayude a decidir. Bien, estos datos, ¿tienen sentido si los mostramos en un gráfico o tiene más sentido mostrarlos como un pastel porque queremos mostrar parte del todo, o queremos comparar la evolución de un país en los últimos 10 años, entonces un histograma es más interesante. Entonces, según lo que el usuario quiera hacer con los datos, los mostrará de otra manera.

Stephanie: Y normalmente no es un trabajo de desarrollador hacer eso. Nuestro desarrollador, es un tipo súper inteligente. Lo siento, pero honestamente trabajo con desarrolladores chicos, desearía tener algunas chicas, pero no. Ninguno de ellos son mujeres. Entonces, muchachos súper inteligentes, pero no están súper calificados para decir, está bien, estos datos deberían mostrarse así, así, así y así. Entonces, al final, aún necesita que algunos diseñadores hablen con los usuarios, entiendan lo que pueden hacer con los datos y esto va mucho más allá de simplemente decir, está bien, esto debería ser una barra de pestañas o esto debería ser una navegación a la izquierda.

Drew: Y después de tomar ese tipo de decisiones basadas en hablar con los usuarios. ¿Por lo general, llevaría los prototipos o diseños resultantes a los usuarios para probarlos nuevamente y ver si entienden su tipo de gráfico elegido, por ejemplo?

Stephanie: Sí, en realidad lo hicimos mucho, lo cual es muy bueno porque no desarrollas algo hasta que sabes que será útil y usable. Así que depende. Si es más rápido desarrollar la cosa porque ya tienen la mayoría de los componentes, lo que suelo hacer es crear prototipos en papel muy rápido y luego desarrollamos la cosa porque es rápido, incluso sin los datos. Si es algo complejo, algo realmente nuevo que tomará mucho tiempo desarrollar, entonces decimos, está bien, diseñamos algunas pantallas y hacemos algunas pruebas directamente en la pantalla. Así que tenemos una herramienta que se llama InVision, donde básicamente pones todo tu diseño, puedes crear enlaces entre las diferentes partes. La cosa es que también depende de lo que quieras probar. Si desea probar teléfonos, por ejemplo, es una pesadilla probarlos en InVision porque la gente realmente no puede sentirlos, especialmente en teléfonos móviles, por ejemplo.

Stephanie: Así que siempre se trata de ser inteligente. ¿Cuál es la forma más rápida y económica? ¿Es más rápido y más barato probar solo diseños? ¿Es suficiente? En el caso de los formularios, por lo general, no realmente, ya que tiene que completar automáticamente todo el trabajo pesado que pone en el front-end y que en realidad hace que el usuario llene un formulario, por lo que para los formularios, tal vez sea más eficiente construir un formulario y probarlo. Pero para cosas nuevas, sí, hacemos muchos diseños. Vamos a los usuarios. Así que por el momento hacemos uno a uno, pero mis usuarios son personas muy ocupadas. Es un banco de inversión europeo por lo que no tienen tanto tiempo. Entonces, lo que solemos hacer es que si nos reunimos uno a uno con los usuarios, hacemos algunas reuniones pequeñas, más como grupos focales. Y también es interesante porque a veces tienes una especie de confrontación. Algunas personas dicen: "Sí, creo que funciona para mí porque trabajo así y así", y luego habrá otras personas que digan: "¿Oh, trabajas así? En realidad no, lo hago así y así”.

Stephanie: Entonces, también es interesante tener algunas personas en la sala y escuchar solo la conversación, tomar notas y decir: "Oh, tal vez entonces podríamos hacer eso" y "Este componente sería mejor basado en lo que acabo de hacer". oyó." Y cosas asi.

Drew: Si está trabajando con una audiencia más general para su producto. Entonces, tal vez no los usuarios internos como usted, sino más bien el público en general, ¿existen formas económicas en que los diseñadores pueden obtener ese uso de la investigación? ¿Existen formas más sencillas si no sabe directamente quiénes serán sus usuarios?

Stephanie: Debes saber quiénes van a ser, de lo contrario, hace el trabajo de la gente de marketing antes de construir el producto. Pero sí, hicimos algunas pruebas de usuario de guerrilla, por ejemplo. Todavía puedes usar InVision, por ejemplo. Entonces puede construir algunos prototipos en InVision y luego puede reclutar a los usuarios a través de las redes sociales, por ejemplo. Estaba trabajando para un producto que ayudaba, cómo se llama, a los mecánicos de los concesionarios de automóviles que reparan cosas y luego también informan al cliente sobre reparaciones adicionales, cosas así. Así que ya teníamos una especie de comunidad en crecimiento en LinkedIn y Facebook. Entonces, lo que puede hacer es reclutar a esas personas. Puede hacer pruebas remotas, como si estuviéramos conversando en una herramienta como una herramienta en línea. Puedes compartir la pantalla. Así que hicimos eso para algún proyecto también.

Stephanie: Solo te daría un consejo: prueba la herramienta antes, porque la estaba usando y se llamabaparece.in. Pero creo que cambiaron el nombre a Whereby o algo así, pero es realmente en el navegador donde dije, está bien, es bueno porque los usuarios no necesitan instalar nada, pero los usuarios no estaban en una computadora real. Estaban en VM, en un Citrix y no tenían micrófonos, así que terminamos haciendo que usaran mi herramienta para compartir la pantalla. Estaban haciendo clic en el prototipo y al mismo tiempo los tenía por teléfono, como un teléfono fijo, para hablar con ellos directamente. Así que siempre, esto fue bastante barato porque fue un maravilloso día de reclutamiento, creo que tuvimos 10 usuarios o algo así. Sí, puedes hacer muchas cosas incluso si no puedes ir cara a cara, he hecho muchas pruebas de usabilidad directamente en Skype o cosas así. Así que siempre hay algunas formas baratas de hacerlo.

Drew: Cuando se trata de elegir un marco de interfaz de usuario con el que trabajar, si esa es la ruta que está tomando, ¿es algo que dejaría solo a los desarrolladores o es algo en lo que los diseñadores también deberían involucrarse?

Stephanie: Para mí, debes involucrar a todo el equipo. Al igual que los diseñadores, los desarrolladores, tal vez también los arquitectos si tienes algunos, porque la forma en que se construye el marco también puede influir en este tipo de cosas. Desafortunadamente, la mayoría de las veces cuando llegan al proyecto, el marco ya estaba decidido. No, en realidad es divertido, o ya está decidido o me piden que valide su elección del marco, pero no hice ninguna revisión ni investigación. No tengo estrictamente idea de lo que hay en el proyecto porque ni siquiera me mostraron sus pantallas. Son como, “Sí, haz lo tuyo. Podemos usar este marco”. No sé. Bueno, ¿tenemos una pantalla? Así que terminaron mostrándote algunas pantallas, que era una aplicación nativa de Windows que querían migrar a la nube. Dijeron: "Sí, solo necesitamos los botones y, sobre todo, nos gustan los formularios y cosas así".

Stephanie: Pero es muy difícil decir: "Sí, elija este marco, tenemos todos los componentes que necesitamos". O como, "No vayas si no tienes una idea aproximada de cuál será tu contenido, cuál es la navegación". Por lo tanto, creo que aún debe tener una especie de descripción general antes de elegir sus marcos, a menos que esté 100% seguro de que tiene todos los componentes. Pero tengo la sensación de que la mayoría de las veces la elección del marco se basa básicamente en qué tecnologías les gustan a los desarrolladores en este momento, ¿tienen experiencia con un marco antes de eso? Usamos Ant en algunos proyectos solo porque algunos desarrolladores tenían experiencia con eso y realmente les gustó y fueron bastante eficientes al usar Ant. Y para la interfaz de usuario de Material React es lo mismo. Es como porque el desarrollador ya lo usó en proyectos anteriores, por lo que son eficientes con él.

Drew: Así que realmente tiene que haber un equilibrio entre lo que los desarrolladores se sienten cómodos, lo que saben, lo que va a funcionar con su pila de tecnología y luego cuáles son los requisitos del producto en términos de crear una buena interfaz de usuario. Y de alguna manera necesitas equilibrar los dos para encontrar el marco ideal para ello.

Estefanía: Sí. Tengo una especie de requisito específico para algún proyecto, que es... Estoy en Luxemburgo, tenemos muchas instituciones europeas y cosas así, por lo que tenemos un requisito de accesibilidad adicional para algunos de ellos. Y, por lo general, cuando se decidió el marco, en realidad no verificaron la accesibilidad de su marco y luego regresaron unos meses después del comienzo del proyecto y dijeron: "Oh, solo nos dijeron que existe esta nueva ley y deberíamos ser accesible, pero no sabemos cómo hacerlo”. Como sí, es un poco demasiado tarde. Entonces, para mí, para elegir un marco, realmente necesita conocer todas las restricciones al comienzo del proyecto y, si la accesibilidad es una de ellas, debe probar sus componentes y asegurarse de que serán accesibles. Pero no soy un desarrollador de React o Angular, pero estoy bastante seguro de que es muy complejo convertir un marco de interfaz de usuario no accesible en algo accesible. Supongo que podría ser un poco complejo reconstruir todos los componentes, así que cosas así.

Drew: Si se encuentra trabajando en un proyecto en el que no se ha llevado a cabo ese proceso y ya se ha elegido un marco de interfaz de usuario, ¿existe el peligro de que la interfaz de usuario comience a verse influenciada por los componentes que ya existen dentro de ese marco en lugar de siendo impulsado por las necesidades del usuario?

Stephanie: Realmente, honestamente, en la mayoría de los proyectos en los que trabajé, eventualmente terminas teniendo muchas compensaciones, incluso si realmente intentas presionar. Por lo tanto, se trata principalmente de equilibrio y discusión con los desarrolladores. Por lo general, lo que hago es hacer algunos marcos de alambre, incluso marcos de alambre de papel rápidos, digamos que está bien, en esta página necesitaremos eso y eso y ese componente, lo primero que hago es preguntarle al desarrollador si tenemos eso en nuestro marco en este momento? Cómo se ve? Y luego decidimos juntos, está bien, este es un componente que haría el trabajo o bien, esto no hará el trabajo. ¿Lo retocamos? ¿Mantenemos el componente pero lo cambiamos un poco para que haga el trabajo, o construimos algo desde cero?

Stephanie: Y al final del día dependerá del presupuesto, por supuesto. Así que terminaste haciendo compensaciones. Como si estuviera bien para componentes pequeños que casi nunca se usan si no son perfectos y hay algunos problemas. Pero para la navegación principal, la estructura principal, las cosas que ves todo el tiempo en la pantalla, por ejemplo, esto realmente necesita funcionar. El usuario necesita comprender cómo funcionan de manera eficiente y sí, es, como dijiste, encontrar un equilibrio entre la experiencia ideal que desearías tener si no tuvieras ningún marco y lo que tienes a mano y el presupuesto y también el sincronización. Si decimos, está bien, para estos sprints, la función debe finalizarse al final de este sprint, y luego dicen, está bien, pero si desea sus componentes, nunca terminaremos la función al final de este sprint, entonces usted Comience a discutir, está bien, ¿terminamos esta función en la siguiente pantalla, nos tomamos más tiempo para hacerlo correctamente? Y por lo general, realmente depende.

Stephanie: Lo que más me frustra es cuando sé que usamos un componente de corrección de cultivos y me dicen: Oh, no, no te preocupes. Lo arreglaremos más tarde. Y sabía que lo último, lamentablemente, nunca podría suceder. Así que depende del equipo. Pero después de un tiempo tienes la experiencia y ya sabes, ¿llegará esto más tarde y o no? Sí, se trata de compromisos. Cuando se trabaja con este tipo de herramientas.

Drew: Como desarrollador, una de las cosas que me gustan de los marcos de interfaz de usuario es que a menudo vienen con un estilo predeterminado. Eso significa que no necesariamente necesito tener un diseñador que me ayude con la apariencia de todos los componentes. ¿Es eso algo en lo que deberíamos confiar en los proyectos? ¿Solo el estilo predeterminado y confiar en que quien haya producido el marco ha hecho un muy buen trabajo en el diseño de esos componentes? ¿O diseñarías esos componentes tú mismo?

Stephanie: Creo que realmente depende. El problema, por ejemplo, con Material-UI es que la apariencia de su aplicación web será básicamente los productos de Google configurados. Entonces, si en realidad no cambia la fuente, cambia algunos colores y trae su propia identidad de marca y hace eso, tendrá un producto que se parecerá a cualquier producto de Google, lo que podría ser algo bueno porque si sus usuarios están acostumbrados a los productos de Google, podría ayudarlos a comprenderlo. Por lo general, si no tienes un diseñador en el equipo, ¿tienes otra opción? Como muchos de los diferentes trabajos que he visto, vienen con temas personalizados para que al menos puedas cambiar los colores. Creo que también puedes cambiar las fuentes con bastante facilidad. Pero de nuevo, si cambias los colores y no eres muy bueno en el diseño o incluso en la accesibilidad, tal vez los colores que usarás choquen, es posible que tengan problemas de contraste.

Stephanie: Por ejemplo, me encanta el naranja, pero es uno de los colores más molestos para trabajar porque para tener un naranja realmente accesible, por ejemplo, como un botón con texto blanco, casi se ve marrón. Y si quieres tener este naranja realmente brillante, necesitas un texto oscuro encima para que sea legible, pero hace que tu interfaz se vea como Halloween al final del día. Sí, te veo reír. Pero es verdad. Entonces, siempre se trata de este tipo de compromisos y si eres un desarrollador y quieres usar el marco tal como está y no tienes un diseñador, creo que es mejor que no tener nada y construirlo desde cero y entonces es súper complejo de usar. Pero la cuestión es que el hecho de que tenga los componentes no significa que creará una gran interfaz. Es como los ladrillos de Lego. Si tienes los ladrillos de Lego, está bien, pero puedes hacer una nave espacial realmente bonita o puedes hacer algo que no se mantenga unido y se desmorone porque realmente no tenías un plan.

Stephanie: Así que el diseño es algo más que eso. El diseño se trata de entender realmente lo que va a estar en la pantalla, cómo funcionará. Y conozco a algunos desarrolladores que realmente tienen la capacidad de hacer eso. Son realmente buenos con las pautas de usabilidad y entienden muchas reglas de diseño, por ejemplo. Entonces, cuando se trata de elegir los componentes, son realmente buenos en eso. Y conozco desarrolladores que no tienen idea de qué componentes elegir y eligen el primero que hace el trabajo. Pero después de un tiempo ya no funciona. Al igual que las pestañas, por ejemplo, teníamos una interfaz en la que algunos desarrolladores elegían pestañas. Creo que tiene sentido al principio cuando solo tienes tres elementos. Pero luego había 12 elementos en la pantalla y luego tienes las pestañas que son tres líneas de pestañas, y todas esas son pestañas del mismo nivel uno, y hay pestañas dentro de las pestañas. Así que tenían el componente, se veía bien porque usaban el marco, pero en realidad no era utilizable.

Stephanie: Y tuve lo mismo con ventanas modales, por ejemplo. Donde construyen los proyectos sin un diseñador y después de un tiempo creo que el cliente pidió más y más cosas en este modal. Entonces terminaron con una pantalla con una tabla y cuando haces clic en agregar una fila, abres un modal, y en este modal tienes dos pestañas, y luego en una de esas pestañas incluso tienes otra tabla y luego querían agregue algo adicional a eso, pensé, está bien, tal vez podamos poner un modal encima de un modal. Y en algún momento el diseñador respondería, está bien, si tiene tanto contenido en el modal, no debería ser una ventana modal. Debería ser una página. Entonces, incluso si tiene el componente, aún necesita una especie de arquitecto para hacer el plan y asegurarse de que todos esos componentes funcionen bien juntos.

Drew: Entonces, si como diseñador, se le pide que cambie el estilo de algunos componentes, ¿intentaría cambiar todo el estilo? ¿Lo personalizarías todo o hay ciertas áreas en las que te concentrarías?

Stephanie: Colores Creo que porque es lo primero que ves, los colores en realidad pueden darte identidad. Si tiene una fuerte identidad de marca, al menos tener los colores de su producto en los botones o los íconos y cosas por el estilo, ya lo ayuda a personalizar el marco. Fuentes porque creo que es fácil, si el marco está bien construido, generalmente cambias toda la familia de fuentes en algún lugar y luego debería funcionar en cascada en el resto del sitio. Entonces, los colores y las fuentes creo que son dos formas fáciles de personalizar rápidamente el marco. Los íconos son otra buena forma de darle personalidad, pero puede ser difícil porque, por lo que he visto, la mayoría del marco viene con íconos personalizados o Font Awesome o como una biblioteca ya integrada. Entonces, para reemplazarlos, primero necesita un muchos íconos si desea reemplazarlos a todos. Así que podría ser un poco complejo. También he visto marcos que te permiten elegir qué paquete de íconos quieres usar. como Font Awesome, Glyphicons y algunos de los otros. Así que este es el tipo de cosas que puedes personalizar fácilmente.

Stephanie: Y luego se trata de la apariencia, por ejemplo, el encabezado, generalmente tienes diferentes tipos de encabezados y pies de página. ¿Cómo navegas cosas así? Así que ya hay una gran cantidad de personalización pequeña que puede traer para que no se vea como Material-UI-ish, se parece más a su marca y luego puede jugar con los radios de los bordes, por ejemplo. Ya sea que desee botones completamente redondeados, botones cuadrados o algo en el medio como sombras también. Entonces, algunas cosas pequeñas que generalmente son fáciles de personalizar porque la mayoría de esos marcos las tienen en variables CSS. Este es el tipo de cosas pequeñas que puedes personalizar sin mucho esfuerzo, excepto por estos efectos dominó. Odio eso. Voy a luchar contra eso. Espero que lo cambien eventualmente.

Drew: I guess things like that, that might seem obvious might seem just like a surface level effect, Do you think that would be easy to change and in this case it turns out it wasn't easy to change? Is that just a case of speaking to your developers to find out what's going to be easy to customize and what's not going to be easy?

Stephanie: Yeah, usually, especially if they're used to work with the framework, they know what's easy to change on it. It depends on the developer, I had discussion with one developer and I asked him if we can not have like uppercase buttons, because they are kind of a little bit hard to read, especially in the font we were using, he went into the documentation and say, I don't know if we can customize it because I can't see it in the API. I was like, what API? It's like CSS class, CSS definition. You remove the uppercase from the CSS and it's done. So he was like looking for an API to change just the font, how does the font look like. And I was like, yeah, but if there's no API for that, I think you can change it in CSS.

Stephanie: But then it's complex because if you have to change this in like all of the CSS line. So it's usually kind of a big discussion. It was the same… was like drop downs. So Material-UI, the React version we use, has some customized drop downs. So when you have a select box like form element, the select it opens these custom components and I don't know why but we have a big problem with that on Internet Explorer. We are going to migrate to windows 10 and Edge. I'm looking forward to it, but we are still Internet Explorer 11 at the moment. And what's happened is whenever you use or you open one of those components, it freezes the screen behind it and you have a scroll bar, so it kind of jumps around whenever you want to use one of those.

Stephanie: And at some point we discuss with the developer, is the customizing of that worth the screen jumping around whenever users click on that. And it's like, honestly for me, no, I prefer it not to jump and we use the select in the browser, then it will not look the same if our users have Edge and, no not Edge, IE. Or if some users are using Firefox, okay? So it will not look the same but it will be the native one and it will not make the page jump around every time someone clicks. So it's this kind of discussion also, do we want to customize it but then it's kind of clumsy or do we say, okay we are not going to customize it. We had the same debate with a scroll bar because we had another project we had drop-downs and they were 100 elements at some point in the drop downs. So there's an auto complete but you can still scroll inside the drop down. And the developer said, yeah but this is looking really ugly on IE, the default scroll bar.

Stephanie: And they investigated, they found JavaScript library that would let us have this really small little a scroll down you have on Mac and have it everywhere. Then we said, okay, is it worth investigating? We need to investigate, test it, put it everywhere, test all of the browsers. So we said we are going to do it, but only if it doesn't damage the performance and if he doesn't damage the rest of your experience, otherwise it's perfectly normal that the browser element don't look the same on any browsers. So at the end, don't customize everything.

Drew: I guess it's a collaborative team effort, then? Everyone needs to discuss and balance up again all the different performance factors, ease of customization and where that customization happens. So once you've got your UI framework in place, you've got all your components specified and built out and customized and styled to how you want them. I guess you need to document that in some way to maintain consistency?

Stephanie: So at some point as a designer what we usually do, we already document them in our sketch files. So we have the working files with every single screen and everything. And in the sketch files we have really specific art boards where we put all of the different components. So that if another designer works on the project, they know that the components already exist and they can just drag and drop it in a new page and reuse it afterwards. So we have this system where we document the components also we document the use, like when do you use this component? When do you use that one? Where is this one working better? So all of the different states for instance, like inputs, we have I think 10 of those, like a focus with a placeholder, without a place holder, with content like arrows and things like that. So again, we bring consistency and then the development parts, it really depends on the kind of maturity of the communication of the team. So what we are currently building is basically a library of components and we are also building the tool around it.

Stephanie: So my developer is currently building that and the idea is to build the component first in our kind of a sandbox, document it. Also he builds things where you can change the colors and if have a button for instance, you can change the icon, you can change the text to see if it will still work with longer text, smaller text, things like that. So we are building this sandbox and in the sandbox, you have a 'Read me' tab where you have documentation for how should this look, how should this component be used, when, how is it supposed to behave? Like auto complete for instance, seems to be something really, really easy, But if you start actually designing the flow of the auto complete, what happens when you put the focus in the field? Do you start auto completing or offering suggestion after one character after two, after three? If it's after three, what happens in the meantime?

Stephanie: So there's a lot of different questions about that that we also document, which is really going super deep into that so that if this auto complete gets implemented on another project or gets used by another team, they know exactly how it's supposed to work as well. So we kind of do the same. The two of us, so designers are documenting into the design tools and usually in the design tool we document the colors and shadows and gradients so that the developer don't have to look around and try to remember exactly what the hexadecimal code for this button was and things like that. So in the end it's kind of you have this UI framework that was super generic and you customized it, you made sure that the components you use are actually the ones that are going to help your user accomplish their goals.

Stephanie: Everything you've customized is kind of starting to become your own little design system. So at the end you're building a design system, but instead of building it from scratch, you're basically building it using React, Material or, what was the other one? Ant or something like that. So it's the same constraints.

Drew: Would you go back to user testing at this point after things have actually been built? Would you go back and test things with users again?

Stephanie: We have tests, like real people testing, like regression testing and making sure that everything works. Like when you click it works, when you hover it works, stuff like that. But yes in the end, especially if we didn't do a prototype, if we did the user testing in mockups, we want sometimes to test it again with the real users who have a feeling that everything is still working. So yeah, sometimes we go again into user testing at the end. We do that usually at the end of a few sprints where the features were implemented. So usually what happens is like we do the research, we design the feature into design tools, we do quick testing at the beginning, then it's implemented, we do tests to make sure it works. And then again we go back to the users.

Stephanie: And it's also interesting because we are building a community with the users. So they're actually quite eager to see that. The first testing was a little bit kind of a sneak peek, like, Oh, this is what it might look like. And then they are super curious about how it works and how it looks like at the end. So we go back usually in one-on-one testing for that or if we don't have the time, we do just like panels and also we deploy it. So sometimes we do AB testing also sometimes if we don't have time for the user testing one-on-ones, we deployed it and then we say, okay, it was deployed. If you have any feedback, please come back to us. Also if you see bugs, because sometimes we compete, the team missed a bug or something, so if we don't have time for re testing it, we still try to find and manage to find some ways to gather feedback even after it's deployed.

Drew: And over time, one of the things that might be a concern probably from a technical point of view is that you've built on top of a UI framework and then a new version of that framework comes out and things have changed. Is that a situation that you've experienced where a new version has come, your developers want to update but it might have implications on the design?

Stephanie: Yeah. The thing is we have test environments, so they're really quick and easy thing to do is like, okay, let's put in your version in one of those secure environment and see what is broken. So from when designers most of the time when they do a new version they tell developers, is it going to break? Like is this new version something completely new and it's not compatible with the old version? Or is this new version something that is just an announcement and you might not break that many things. So yeah, obviously sometimes when you put a new version it completely breaks, but this is again, then you have like testing stories and like technical investigation stories to decide if we are going to migrate or not. Also like from what I understand in some of the environment I worked on, they kind of encapsulated those in web components.

Stephanie: So they're already has kind of two different version of Angulars on some components, it was using one version on the other ones it was using the other one and from what I understood it works because then you only encapsulate what you need. So this apparently is also a solution is then you can use whatever version you want, but I'm not a developer but I feel at some point you'll be like, okay, this component is using that version of Angular and this one, this and this maybe kind of becomes super hard to maintain. Do you know?

Drew: Yup.

Stephanie: It does. Bueno. So yeah, you make sure it still works, but I don't have the feeling that Material-UI are like those frameworks, even bootstrap for instance, they don't have any new version every year or something. It's a long lifecycle and in the case of my tool, I think this tool will be here for the next year, so we have eventually to update. But if you're building kind of a online tool, more like a B to B product. Most of the time you revise every three years or something. And usually there is a new technology. I was talking to a friend and they're currently working on a project where they're rebuilding and riffing on React. The first version was built three years ago with another technology. I really don't remember the technology, but they say, okay, we are three years later, they're already rebuilding it. And I think in like three years, they will re-rebuild it. So at some points if you're in like in B to C products, I even wonder if you update your framework or if you are going to change the design and rebuild it anyway in a few years from scratch.

Drew: Is there anything else that we should be considering when building on a UI framework?

Stephanie: I feel we covered a lot of things. Well, the thing is like, there's always a way to do it quick, user research, talk to users or at least do usability testing. Make sure you don't design or build in a silo and try to have other people at least look at what you've created to make sure that the components as a developer, that you used as a developer I really do wonder are going to do the job. And don't ask the designer to put paint on top of the framework at the end of the project because it's kind of already too late to do big infrastructure on changes. It might not work.

Drew: So at Smashing, we have books, we have conferences, and of course, we have Smashing Magazine, a website with loads of articles. We're all about learning. So what is it that you've been learning lately?

Stephanie: I've been taking online introduction to psychology class.

Drew: Tell us a bit about that.

Stephanie: Last lesson was actually super interesting. We were talking about visual illusions and how they work with your brain. So it's really super complex and there's… Apparently not everyone agrees on the explanation of most of those illusions, but it's interesting because I had a small psychology lesson, like I read books on cognitive sciences and things like that. So I already knew kind of the basics, but it's interesting to see like all the different aspects of psychology. So the interesting part of this course is it's an introduction but it explains to you kind have all the branches from say child development psychology to trauma psychology to intercultural psychology. So and then illusions and I think this week it's actually about cognitive psychology and how to apply psychology to interfaces. So all of those really, really interesting topics. And it's nice because it's an online class, so I'm basically learning stuff on my couch with some tea, and yeah, that's really, really cool.

Drew: Oh, that's super interesting. If you, dear listener, would like to hear more from Stephanie. You can follow her on Twitter where she's @WalterStephanie, or find her on the web at stephaniewalter.design. Thanks for joining us today, Stephanie. Do you have any parting words for us?

Stephanie: Thanks for having me. It was a smashing experience.