Hay una gran cantidad de artículos que enseñan cómo los diseñadores pueden decir que no . Esto se trata principalmente de autónomos y cómo interactuar con clientes difíciles. También hay artículos con consejos para tratar con Product Managers. Sin embargo, ¿qué pasa cuando estás apoyando un sistema de diseño? Qué hacer con las solicitudes conflictivas de otros diseñadores o desarrolladores.

No sé lo que estoy haciendo todavía...

Si no eres un experto y recién estás comenzando a crear un sistema de diseño para tu empresa desde cero, es posible que no sepas qué dirección tomar. Por supuesto, puedes leer varios artículos con recetas sobre “ cómo empezar ”, pero a veces no hay nada mejor que la experiencia personal. Probar algo, cometer errores a veces y aprender de los errores. Estar abierto a cosas nuevas. Sea una persona de “Sí, intentémoslo”.

Tienes que ser lo más flexible posible en tal situación. Sin embargo, documente sus decisiones si no quiere que las decisiones exitosas permanezcan como “magia negra” y las fallidas como una coincidencia desconocida.

No solo me refiero a escribir la decisión en sí, sino cómo usted (u otros) llegan allí. Argumentos, etc. Sí, esto puede ser, a veces, difícil. Especialmente cuando la decisión fue intuitiva (corazonada). Sin embargo, si aprende a cuestionarse a sí mismo y a los demás, eventualmente puede comenzar a comprender el origen de la idea.

Dicha documentación le permitirá comprender mejor las relaciones de causa y efecto y aprender qué funciona y qué no. Y la próxima vez, si ve que una nueva propuesta se ajusta a un patrón conocido (o va en la misma dirección), podrá señalarlo a los demás. Es decir, aprenderás a dar razones razonadas frente a soluciones arriesgadas.

He visto esto en alguna parte antes...

Siempre puede pedir ejemplos a la comunidad cuando se trata de malas decisiones . A los diseñadores (y a muchas otras profesiones) les gusta hacer listas de lo que no se debe hacer .

Hay una gran variedad de artículos en la categoría " 10 peores decisiones de diseño " y similares. Sin embargo, en lo que respecta a los sistemas de diseño, lo más importante serán las descripciones de prácticas “buenas/malas”, “patrones”, “hacer y no hacer”, etc. Y es mejor buscarlas en la documentación de los sistemas abiertos de diseño.

A menudo , dichos documentos brindan argumentos concisos pero concisos a favor o en contra de una solución en particular, y pueden ser de gran ayuda para analizar situaciones que surjan en su sistema. E incluso en tu trabajo diario de diseño.

Lo que se debe hacer y lo que no se debe hacer es un elemento clave de cualquier documentación de diseño de sistema y cuanto antes comience a documentar las prácticas "buenas/malas" para su sistema, más preguntas y malentendidos podrá evitar.

“ Si no está documentado, no existe ”

La documentación es un compromiso. Pero también orientación sobre “qué podría/debería hacer”. Después de todo, los diseñadores a menudo toman decisiones cuestionables porque no son conscientes de lo que se debe y no se debe hacer dentro del sistema de diseño. En su ausencia, la afirmación “todo es posible” es un pensamiento razonable.

Pero aquí es importante enfatizar: la documentación no se trata de prohibiciones. La documentación está diseñada para explicar cómo funciona el sistema e indicar razonablemente qué vale la pena hacer y qué no. En consecuencia, si el diseñador (o desarrollador) solo está motivado por "Me gusta de esta manera" y contradice la documentación, tiene una razón razonable y justificable para rechazar, refiriéndose a la documentación.

La documentación ayuda a dar un buen ejemplo para que otros argumenten sus ideas. Y convierta las ideas en soluciones que le ayudarán a llevar su sistema de diseño al siguiente nivel.

Biblioteca de diseño ≠ Sistema de diseño

A menudo, surgen problemas cuando los usuarios (o colaboradores) no comprenden qué es un sistema de diseño y lo consideran una biblioteca de diseño. Muchos diseñadores están acostumbrados a lidiar con bibliotecas de diseño listas para usar y tener que modificarlas para satisfacer sus necesidades.

“Me gusta este UI-Kit, pero se creó sin tener en cuenta mis casos de uso, por lo que necesito personalizarlo”. Suena bastante razonable, ¿no? Sí, si hablamos de soluciones de terceros de las que tú (u otra persona) solo utilizarás una pequeña parte. Pero en el caso de un sistema de diseño interno, esto podría conducir al caos.

Algo parecido a esto, pero un poco diferente….

En mi opinión, lo más difícil es cuando los usuarios solicitan pequeños cambios. Cambios bastante pequeños:

• Agregue la capacidad de usar íconos en los encabezados.
• Cambia el orden de los bloques en la lista.
• Mostrar 3 botones en lugar de 2 (definidos por un componente).

• Coherencia del enfoque con otros componentes.
• La complejidad de implementación en código y componentes de diseño (Figma, Sketch, etc.).

Primero, debe averiguar si el patrón se cruza con algún otro componente. Para hacer esto, debe conocer todos los componentes y su comportamiento de memoria o revisar cada uno de ellos y ver si la propuesta entra en conflicto con alguno de los otros componentes. Si hay los más mínimos conflictos, es necesario discutir la propuesta no de forma aislada, sino en el contexto del comportamiento de varios componentes. Esto a menudo puede requerir invitar a más personas a la discusión.

La complejidad de la implementación.

Muy a menudo, lo que parece una solución simple en el diseño puede requerir un gran esfuerzo en el desarrollo. Quizás porque la arquitectura actual no es lo suficientemente flexible. Tal vez solo vaya en contra de los estándares/enfoques básicos utilizados en el desarrollo. Teóricamente, casi todo es posible, pero algunas cosas requerirán más esfuerzo. En tal situación, es posible que deba comprender cuán importantes son estos cambios: "Agradable tener" o "necesidades críticas".

Somos sirvientes, no dictadores

El sistema de diseño es un producto . Pero es uno muy específico. Si bien el éxito de la mayoría de los productos se puede medir por cuánto dinero ganan, para un sistema de diseño, el indicador principal es cuántos usuarios lo usan y cuánto les facilita la vida. En otras palabras, un sistema de diseño es “El producto más honesto” . Y eso implica mucha responsabilidad. No solo necesitamos aprovechar al máximo lo que los clientes quieren, sino también ayudarlos a comprender las consecuencias de cada decisión cuestionable:

• una falta de flexibilidad en la perspectiva
• retrasos en el desarrollo de la solución (debido a la complejidad de la solución y su mantenimiento)
• la necesidad de cambios en cascada a otros componentes o acuerdos
Administración de las contribuciones del sistema de diseño

En última instancia, el sistema de diseño se trata de los usuarios (diseñadores y desarrolladores). Así que hay que estar muy atento a ellos. Después de todo, sin ellos no somos nadie. Y si las ediciones son razonables y no rompen nada, ¿por qué no hacerlas?

Todas las razones para decir "no" son solo para asegurarnos de que creamos el producto que los usuarios necesitan, no el que quieren.

Cuando se le preguntó acerca de la opinión de los clientes en el desarrollo del Ford Modelo T, Henry Ford dijo: "Si le hubiera preguntado a la gente qué querían, habrían dicho caballos más rápidos".

¡Gracias por leer! ¡Mantengamonos en contacto! Conéctate conmigo en LinkedIn y sígueme en Dribbble y aquí en Medium para obtener más contenido relacionado con el diseño.