Aplicando los Principios del Pensamiento de Producto a tu Sistema de Diseño

Hola a todos. Mi nombre es Raymond y soy un ingeniero de front end con sede en San Francisco. Hoy, hablaré sobre cómo aplicar los principios de creación de productos a su sistema de design.

Entonces, este eres tú. Eres un ingeniero de front end construyendo el sistema de design de tu empresa. Tienes una configuración básica de storybook y algunos componentes construidos, probablemente un botón. Todos siempre comienzan con un buen botón antiguo. ¿A dónde vas desde aquí? Comienzas a buscar en Google bibliotecas notables, bootstrap, material UI, ant design, chakra, blueprint, la lista continúa. Ves un montón de componentes, variantes, props, etc. Piensas que necesitas construir todo esto y empiezas a sentirte abrumado. Empiezas a sudar. ¿Alguna vez te ha pasado esto? Definitivamente me ha pasado a mí, pero lo que me ha ayudado es replantearme cómo pienso en un sistema de design. No es una colección completa de componentes perfectos que manejarán todos los posibles casos límite y escenarios. En cambio, es un producto que existe para resolver problemas, al igual que los productos que tu empresa está construyendo. Y puedes usar los principios de pensamiento de producto para ayudar a guiar tu camino hacia adelante.

Los principios en los que me centraré hoy son la priorización, los productos mínimamente viables o MVPs, y las métricas.

Priorización. Hay un número infinito de cosas en las que podrías estar trabajando. ¿Por dónde empiezas? Empieza con tus usuarios, por supuesto. Probablemente sean otros ingenieros y probablemente internos, por lo que deberían ser más fáciles de alcanzar. Ponte tu sombrero de investigación de UX. Habla con ellos, descubre sus necesidades, encuentra sus problemas, síguelos, realiza encuestas y recopila data.

Además, piensa en los objetivos más amplios del producto y del negocio. ¿Hay un nuevo componente que aceleraría el lanzamiento de una característica importante que desbloquearía nuevas ventas? ¿Los clientes están escribiendo sobre problemas de UX en un área de producto importante? Aunque tu trabajo es generalmente interno, es importante no perder de vista el negocio más amplio. También puedes realizar auditorías de código para obtener data sobre el uso actual de los componentes. Me gusta usar el paquete React scanner, que escanea tu base de código y te da números sobre instancias de componentes, uso de prop, etc. A partir de aquí, probablemente verás patterns. ¿De qué se quejan comúnmente los ingenieros? ¿Qué usan a menudo? ¿Qué les resulta difícil de usar? ¿Qué es importante para el negocio? Utiliza toda esta información para priorizar en qué trabajar.

MVPs. Así que priorizas tu trabajo, y lo más probable es que te centres en la construcción de componentes. Cuando pienses en construir, no dejes que la perfección se interponga. Puede que hayas oído hablar de la regla 80-20, que se aplica aquí. Aproximadamente el 80% de tus casos de uso se pueden construir con solo el 20% de tu tiempo total. Por otro lado, el último 20% de las partes más difíciles, o los casos de uso menos comunes, tomarán el 80% del tiempo. Secuencia tu trabajo de tal manera que puedas lanzar algo lo antes posible para resolver el caso del 80%. Después de lanzar, asegúrate de que hay canales para recibir comentarios. Aprenderás más lanzando e iterando que intentando hacerlo perfecto desde el principio. Y a través del lanzamiento más temprano, validarás continuamente si realmente estás resolviendo problemas para tus usuarios.

Métricas. Mientras estás construyendo componentes, haciendo actualizaciones, etc., es importante medir tu progreso. El primer lugar donde comienzo es el uso y la adopción. Mencioné el paquete react scanner anteriormente que te da números sobre cuántas veces se están utilizando tus componentes. Usa estos data para construir gráficos del uso de componentes a lo largo del tiempo. ¿Qué indican las líneas de tendencia? Si están planas o incluso bajando cuando no esperas que lo hagan, podría haber problemas, como errores o una API de componentes torpe, y tus usuarios pueden estar buscando otras soluciones alternativas. Si están subiendo y a la derecha, probablemente sea bueno. Tienes data que muestra que tu componente se está utilizando, por lo tanto, resolviendo los problemas de tus usuarios. Los gráficos también son útiles si estás depreciando o migrando un componente, y se sentirá tan satisfactorio cuando la línea de ese componente super antiguo o de mala calidad, todos tenemos esos, finalmente llega a cero. En general, las métricas juegan un papel crucial en el trabajo de plataforma que está menos directamente vinculado al impacto empresarial. Todos tenemos la sensación de que el trabajo de plataforma ahorrará tiempo a largo plazo, pero los números validan la importancia de nuestro trabajo y fundamentan esa sensación en data. Tiempo de historia. Bueno, veamos esto en la práctica. Basándome en mi propia experiencia construyendo un componente de tabla para el sistema de design de mi empresa. Priorización. Hablamos con otros ingenieros de muchas maneras diferentes. Casualmente, en el almuerzo, en Slack y a través de la programación en pareja. También hicimos encuestas periódicas y a través de esto, aprendimos que a mucha gente le disgustaba trabajar con su componente de tabla existente. La API no era intuitiva, básicamente era un mega componente con más de 40 props, había un montón de sobrescrituras y hacks de CSS necesarios, y algunas características estaban ausentes o eran defectuosas. Las tablas también se utilizaban en todo nuestro producto. Así que priorizamos trabajar en ello. MVP's. Si alguna vez has trabajado en un componente de tabla, sabes que hay una tonelada de complejidad. Ordenamiento, filtrado, paginación, estados de carga, encabezados pegajosos. Podría seguir y seguir. Pero no todos estos eran realmente relevantes para nuestro producto. Abordamos esto comenzando amplio y clasificando estos por importancia y desglosando esto en una lista de DEBES TENER para nuestro MVP. Después de eso, recogimos comentarios en Slack, que nos gustó porque es de baja fricción, y usamos eso para determinar en qué trabajar a continuación. A medida que surgieron más necesidades, agregamos nuevas características de manera compatible con versiones anteriores. Métricas. Para el nuevo componente de tabla, así como para todos los demás componentes que construimos, rastreamos las métricas a través de un trabajo cron recurrente que ejecutó el escáner React y envió data a nuestro panal que luego utilizamos para construir paneles que miden el uso de componentes a lo largo del tiempo. Compartimos periódicamente estos paneles fuera de nuestro equipo para generar entusiasmo por nuestros componentes, así como para mostrar el impacto de nuestro trabajo. Entonces, para resumir, prioriza tu trabajo manteniéndote cerca de tus usuarios, enfocándote en sus problemas, alineándote con el negocio y encontrando patterns. Luego, comienza con los MVPs. Practica la regla 80-20, lanza temprano, recoge comentarios y luego itera. Y por último, mide tu progreso para fundamentar la importancia de tu trabajo con data. Gracias por escuchar. Aquí está mi información de contacto si quieres ponerte en contacto.