Una guía rápida para diseñar sistemas
Obtenga la descripción general más esencial sobre los sistemas de diseño y las necesidades de colaboración entre diseño y desarrollo
Usar y construir un sistema de diseño no es algo nuevo. Lo nuevo, sin embargo, es cómo se usa y dónde se aplica. Hágalo bien y podrá llevar a cabo mejor los procesos a escala: diseño de productos y transición desde diseños Sketch o Adobe XD, diseño de UX, transferencias, pruebas de usuario, desarrollo de front-end.
Con nuestra RefCard de sistemas de diseño, se le brindará una descripción detallada de los sistemas de diseño para percibirlos como algo más que un inventario deliberado de patrones de UX reutilizables y pautas de estilo de marca. También comprenderá lo que se debe hacer en su panorama de diseño y desarrollo para brindar una experiencia coherente y una alineación del proceso de diseño a código entre equipos multifuncionales.
Lea la RefCard hoy para obtener más información sobre:
- La importancia de los “empoderamientos de diseño”: reducir los costosos y evitables retrabajos.
- ¿Qué es un Design System? Más allá de "una colección de activos de diseño", abarca conceptos de uso de herramientas de un extremo a otro que llevan a los equipos del diseño al código más rápidamente.
- Las 4 etapas de colaboración entre diseño y desarrollo: desde el intercambio de maquetas y guías de estilo hasta la generación de componentes específicos de diseño con el uso de herramientas como App Builder.
- La anatomía de un Design System: comparable a los átomos, moléculas y organismos, un sistema de diseño cambia para reflejar las necesidades específicas de UX con el producto y las herramientas en mente.
- Más beneficios Design System: ayudar a las empresas a escalar rápidamente sin necesariamente escalar el equipo de desarrollo de diseño y reducir el costo y el tiempo para entregar aplicaciones con todas las funciones.
- El futuro de los sistemas de diseño: su potencial para integrarse fácilmente con herramientas de desarrollo de productos digitales de automatización y DevOps, invitando a los desarrolladores desde las primeras etapas.
- Indigo.Design en pocas palabras: permitir que los equipos implementen una arquitectura sólida y preparada para el futuro de un sistema de diseño ahorra tiempo y esfuerzos.
Introducción
El diseño y el desarrollo siguen siendo las disciplinas funcionales centrales dentro del desarrollo de productos de software, pero el problema es que la mayoría de las veces evolucionan por sí solas. Mientras que, de hecho, la complejidad y la escasez de tiempo detrás de la creación de aplicaciones modernas funcionan como una prueba de la realidad que exige una única fuente de verdad que sea igualmente beneficiosa tanto para los diseñadores como para los desarrolladores.
Sin embargo, usar y construir un sistema de diseño no es algo nuevo. Lo nuevo es cómo se usa y dónde se aplica. Hágalo bien y podrá llevar a cabo mejor los procesos a escala: diseño de productos y transición desde diseños Sketch o Adobe XD, diseño UX, transferencias, pruebas de usuario, desarrollo front-end.
Desde el punto de vista del éxito empresarial, las empresas reconocen la necesidad de ofrecer una UX convincente en sus aplicaciones [#]. Sin embargo, ofrecer una experiencia de usuario convincente requiere un alto grado de colaboración entre el diseño y el desarrollo. Y este nivel de colaboración puede resultar costoso dada la naturaleza remota y distribuida del trabajo moderno. El costo de ofrecer UX también se ve agravado por otros factores, como el esfuerzo requerido para comunicar la intención del diseño y transformar las especificaciones visuales en código, por nombrar algunos. A menos que reduzcamos estos costos, puede resultar inviable ofrecer una experiencia de usuario convincente incluso para las empresas más dispuestas.
En los últimos años, los sistemas de diseño han surgido como una solución para mejorar la colaboración entre diseño y desarrollo. El enfoque del sistema de diseño ha sido adoptado por organizaciones como Salesforce.com, IBM, Atlassian, etc. y sirve como testimonio de su atractivo.
Pero existe esta definición popular de que un sistema de diseño es una colección de recursos de diseño que se utilizan para crear interfaces de usuario. En términos simples, sí, representa un inventario de patrones de UX y una guía de estilo de marca que se implementan como componentes de software coincidentes que pueden reutilizarse o contextualizarse para crear aplicaciones de software. Desde una perspectiva más amplia, los sistemas de diseño son mucho más que bibliotecas de componentes de interfaz de usuario reutilizables. Son “empoderamientos de diseño” hechos a mano que:
- Servir como una única fuente de información para los equipos de producto.
- Sintonice un contexto de uso y un dominio de aplicación específicos.
- Acelere el proceso de diseño y mejore significativamente la coherencia.
También se pueden ampliar para contener guías de voz y tonos para escribir contenido, plantillas de páginas e incluso flujos de usuarios, pero de una manera diseñada a mano para el contexto de uso y el dominio de aplicación específico de cada organización.
Para entenderlo todo, esto es lo que revisaremos en este artículo:
- La importancia de los “empoderamientos del diseño”
- Etapas de la colaboración diseño-desarrollo.
- La anatomía de un sistema de diseño.
- Beneficios de utilizar un sistema de diseño
- El futuro de los sistemas de diseño se entrelaza con la automatización y las herramientas low-code
- Indigo.Design en pocas palabras
Los sistemas de diseño son vistos como “empoderamientos del diseño”
En Infragistics realizamos una encuesta entre 388 desarrolladores que participaron en nuestros seminarios web más recientes y descubrimos que solo alrededor del 26% de ellos trabaja con un equipo de diseño, lo que deja a más de 3 de cada 4 desarrolladores que también actúan como diseñadores de UI. Un poco más del 70% de los desarrolladores también dice que trabajar con HTML/CSS y diseñar pantallas es el mayor desafío en términos de creación de aplicaciones web, lo que los ralentiza y complica aún más el proceso.
Dado que la interfaz de usuario (UI) representa el 60 % del tiempo de desarrollo de aplicaciones, la posibilidad de cometer errores durante las transferencias entre el diseñador y el desarrollador es enorme y puede costar un factor de 10 veces una vez que se implementa una aplicación. Los problemas que suelen encontrar los equipos son interrupciones visuales y de comportamiento, discrepancias de marca, mala usabilidad, estándares de diseño mal comunicados y otras inconsistencias en el ciclo de diseño y desarrollo del producto. Otras veces, existe el momento de falla que surge en algún momento entre el momento de construir un sistema de diseño y su implementación adecuada.
Sin embargo, con un sistema de diseño implementado, la creación de la aplicación se realiza sin problemas, lo que reduce el costoso y evitable retrabajo que impide que las aplicaciones lleguen al mercado rápidamente.
Evolución de las etapas de colaboración entre diseño y desarrollo.
Antes de sumergirnos en los sistemas de diseño, revisemos cómo han progresado los artefactos de colaboración entre diseño y desarrollo. Podemos clasificar esto a grandes rasgos en cuatro niveles:
- Nivel 1: Especificaciones visuales estáticas
- Nivel 2: Especificaciones visuales interactivas (inspeccionar)
- Nivel 3: Especificaciones visuales vinculadas a componentes de UI (Sistemas de diseño)
- Nivel 4: Generación de app a partir de especificaciones de diseño (Design Systems +)
Para todos los niveles, podemos suponer que alguna forma de actividad de diseño precedió al desarrollo. Es decir, las especificaciones para las UI y los flujos se crean antes del desarrollo.
Nivel 1: Especificaciones visuales estáticas
Esta forma de comunicación entre diseño y desarrollo es la más común. En este nivel, las maquetas visuales se crean utilizando herramientas utilizadas por los diseñadores visuales (por ejemplo, Sketch, Adobe XD). Las especificaciones de estilos, diseño, tamaño, etc., se agregan como anotaciones encima de los simulacros para su revisión.
Los desarrolladores consultan esta documentación como parte de su proceso de desarrollo y la implementan manualmente en el código. Este enfoque está bien para proyectos únicos personalizados que no necesitan mantenimiento.
Nivel 2: Especificaciones visuales interactivas (Inspeccionar)
En este nivel, el equipo de diseño visual todavía comparte maquetas y guías de estilo con los desarrolladores, pero en lugar de un documento estático, dependen de herramientas para proporcionar las especificaciones en un formato más accesible. Con herramientas como Zeplin.io, los diseñadores pueden cargar sus diseños sin tener que esforzarse en marcarlos, y los desarrolladores pueden luego verlos en el navegador. Más importante aún, al hacer clic en el diseño, los desarrolladores pueden ver las especificaciones a pedido y en un formato que se alinee con su plataforma de destino (por ejemplo, HTML, CSS).
El beneficio clave de este enfoque es que los diseñadores no tienen que preocuparse por agregar anotaciones manualmente y los desarrolladores aún pueden extraer activos y especificaciones para cualquier parte de la interfaz de usuario. Sin embargo, no está vinculado a ningún componente de software que utilice la organización.
Nivel 3: especificaciones visuales vinculadas a componentes de la interfaz de usuario
En este nivel podemos esperar que el diseño haya colaborado con el desarrollo para crear un inventario de estilos, diseños y componentes de UI que satisfagan sus necesidades; en otras palabras, han esbozado un sistema de diseño.
Aquí, los equipos de diseño crean diseños utilizando un kit de interfaz de usuario estandarizado que refleja el sistema de diseño. Kit de interfaz de usuario es un nombre común que se le da a una colección de elementos de diseño visual reutilizables creados utilizando la propia herramienta de diseño (por ejemplo, Sketch o Adobe XD) que coincide con los componentes de su código base. Esto facilita que el equipo de desarrollo implemente los diseños porque ya existen componentes de interfaz de usuario coincidentes.
Con este enfoque, los desarrolladores aún necesitarán escribir código de interfaz de usuario para estructurar la aplicación, crear los diseños y configurar aún más los componentes para que coincidan con las especificaciones. Dado que la implementación utiliza componentes del sistema de diseño acordados, se reduce el potencial de falta de comunicación. Soluciones como Storybook permiten vincular los componentes del kit de interfaz de usuario con el kit de herramientas de componentes del desarrollador. Este tipo de integración está ganando popularidad entre los equipos de software para documentar el kit de herramientas del desarrollador.
Sin embargo, el problema más importante es que no todas las organizaciones han invertido en un sistema de diseño. Por lo tanto, este grado de colaboración es una aspiración para la mayoría. Además, dicha colaboración se centra en la reutilización de componentes del sistema de diseño o tokens de diseño. Los desarrolladores aún deberán configurar cada componente e implementar la interfaz de usuario, que luego será aprobada por el equipo de diseño.
Nivel 3: especificaciones visuales vinculadas a componentes de la interfaz de usuario
Un sistema de diseño puede ayudar a los equipos de diseño y desarrollo a estandarizar en torno a un conjunto común de componentes básicos. Sin embargo, los artefactos creados como parte de la transferencia (es decir, el diseño entregable) pueden convertirse en una fuente de ineficiencia. Como se describió en la sección anterior, el esfuerzo desperdiciado se debe a que el equipo de desarrollo tuvo que implementar los diseños. Más específicamente, configurar componentes y recrear los diseños.
Algunas organizaciones todavía tienden a utilizar marcos antiguos y llegan a un punto en el que deben migrar a Blazor o Angular. Pero hacerlo y al mismo tiempo intentar acelerar el tiempo de comercialización exige una solución más radical. Crear especificaciones basadas en un sistema de diseño e incluirlas como artefactos de transferencia es una forma de abordarlo. Sin embargo, dichos proyectos también deben superar otros desafíos que no se limitan a los siguientes:
- Investigar y diseñar un sistema de diseño (es decir, bloques de construcción acordados)
- Crear y mantener una biblioteca de componentes que coincida con el sistema de diseño.
- Familiarícese con la plataforma de destino (por ejemplo, Angular) e incorpore las mejores prácticas.
- Cree la documentación de desarrollador necesaria para ayudar durante el desarrollo.
- Asegúrese de que la aplicación coincida exactamente con las especificaciones visuales (diseños + tematización)
Soluciones como App Builder ™ tienen como objetivo reemplazar el tipo tradicional de transferencia, como se describe en la sección anterior (consulte el Nivel 3). En lugar de compartir un documento de especificaciones o una maqueta, los desarrolladores reciben una aplicación basada en especificaciones de diseño ya realizadas. Esto elimina la necesidad de inspeccionar y extraer partes de las especificaciones y volver a implementar los diseños.
Utilizando el enfoque Indigo.Design, los diseñadores crean sus maquetas utilizando el kit de interfaz de usuario Indigo.Design. Este kit de interfaz de usuario proporciona a los diseñadores una versión del sistema de diseño en un formato adecuado para la herramienta de diseño (por ejemplo, Adobe XD, Figma o Sketch). Esto permite a los diseñadores crear diseños de pantalla y configurar los componentes de acuerdo con lo que permite el sistema de diseño.
Cuando se completa la maqueta, los usuarios pueden publicar sus diseños como una aplicación utilizando el complemento Indigo.Design. El complemento convierte automáticamente los archivos de diseño estáticos en una aplicación que se puede editar aún más utilizando un editor WYISWYG basado en la nube. Este editor permite a los desarrolladores continuar editando la aplicación antes de descargar el código fuente completo de la aplicación.
Las características clave de App Builder que respaldan la historia del diseño a escala incluyen:
- Vistas y shell de la aplicación de scaffolding para plataformas Angular y Blazor
- Navegación y enrutamiento de aplicaciones
- Diseños web
- Temas y tokens globales
- Enlace de datos utilizando fuentes de API REST
- Integración con GitHub para continuar el desarrollo
La anatomía de un sistema de diseño.
Ahora que tenemos una mejor idea de dónde encaja un sistema de diseño en la historia del diseño al desarrollo, veamos cómo está estructurado.
Un sistema de diseño utiliza un enfoque para construir elementos escalables que pueden ilustrarse mejor como átomos, moléculas y organismos. Se la conoce como Metodología de Diseño Atómico; creado por Brad Frost. Se ha convertido en un enfoque popular para describir la estructura de un sistema de diseño.
Volviendo a la metáfora de los átomos, las moléculas y los organismos, se comienza diseñando el componente más pequeño (por ejemplo, botón, avatar, etiqueta, título, etc.). Este componente más pequeño se conoce como átomo.
Yendo un nivel más profundo, los átomos están formados por partículas como el núcleo, los protones y los neutrones. Para un sistema de diseño, esto se puede asignar a la paleta de colores y la tipografía base, que definen la identidad de marca de la organización.
Subiendo un nivel desde los átomos, tienes moléculas que están compuestas de átomos. Las moléculas se pueden asignar a componentes y representar estructuras más complejas, como elementos de menú, elementos de lista o elementos desplegables.
Luego, al combinar diseños y múltiples componentes, obtenemos la siguiente unidad jerárquica: patrones UX; o apegarnos a nuestra comparación biológica: los organismos. Estos resumen las mejores prácticas en UX siguiendo "buenos" principios de diseño y están diseñados para las necesidades específicas de un producto.
El objetivo de ilustrar sistemas de diseño como átomos, moléculas y organismos es establecer paralelismos con un sistema vivo. Un sistema de diseño no debe ser estático ni cambiar nunca: debe reflejar las necesidades de UX del producto y evolucionar constantemente con el producto y las tecnologías utilizadas. Surgen nuevos requisitos debido a los nuevos requisitos de diseño de los dispositivos, las nuevas características del producto y los cambios de identidad de marca son inevitables, y debemos estar seguros de que nuestro Design System es flexible y está listo para cambiar para que podamos adaptarnos a estos cambios.
Beneficios de utilizar un sistema de diseño
Experiencia de usuario estandarizada
Uno de los mayores beneficios de un sistema de diseño es preservar la coherencia entre diferentes dispositivos, productos y subproductos, así como la coordinación con el marketing y la marca.
Una fuente común de inconsistencia es cuando diferentes desarrolladores y diseñadores participan en el desarrollo del producto. Si a esto le sumamos la creciente naturaleza descentralizada del trabajo, en diferentes zonas horarias, las revisiones 1-1 son costosas. Con un sistema de diseño implementado, los diseñadores y desarrolladores pueden trabajar de forma independiente en sus propias herramientas sin necesidad de realizar comprobaciones de bajo nivel en torno a la implementación del diseño. En cambio, pueden centrarse en interacciones de alto valor en torno a los resultados.
Desde la perspectiva pura del cliente, la coherencia significativa entre las aplicaciones ofrecidas por la misma organización permite a los usuarios reutilizar lo aprendido de sus interacciones pasadas con las aplicaciones.
Como dice Diana Mounter de GitHub:
“Los sistemas de diseño ponen orden en el caos. Todos se mantienen en la misma página, por lo que todo el producto permanece consistente y pulido en todo momento.Los sistemas de diseño mejoran la experiencia del usuario mediante el uso repetido de patrones familiares y probados. Diseñar cualquier cosa desde cero deja margen de error, así que intenta utilizar lo que ya funciona.Los sistemas de diseño mejoran la eficiencia del flujo de trabajo: los equipos de productos saben exactamente cómo deben verse los componentes de las nuevas funciones y cómo implementarlos".
Vocabulario compartido entre diseño y desarrollo.
Si bien la coherencia es una gran ventaja, algo tan simple como acordar mutuamente nombres para componentes y patrones puede ser de gran ayuda. Esto es útil para los usuarios actuales del sistema de diseño y para la incorporación de futuros miembros. Hacer que la convención de nomenclatura sea explícita y compartida facilita que tanto los desarrolladores como los diseñadores encuentren los componentes en sus respectivos entornos de herramientas.
Con el tiempo, los nombres de los patrones de UX comenzarán a aparecer en las conversaciones, sirviendo como sustitutos de los requisitos del usuario. Por ejemplo, cuando alguien menciona que deberíamos usar un componente de cuadro combinado, tanto los diseñadores como los desarrolladores tienen claro qué tipo de comportamiento admite y cómo puede adaptarse al objetivo de la experiencia. Dado que un sistema de diseño documenta un componente como un patrón, generalmente explica cuándo usar un componente específico y cómo usarlo de la manera correcta con ejemplos. Entonces, en ese sentido, un sistema de diseño puede satisfacer la necesidad de una guía UX accesible, evangelizando así las prácticas de diseño.
Acelere el proceso de diseño y desarrollo
La velocidad de entrega es un beneficio explícito de reutilizar componentes en un sistema de diseño. Desde una perspectiva de diseño, la eficiencia proviene de no tener que crear nuevos componentes o patrones, ya que ya forman parte de los kits de interfaz de usuario del sistema de diseño. Incluso cuando se enfrentan a la necesidad de crear un nuevo patrón complejo, los diseñadores pueden confiar en las directrices del sistema de diseño y construir algo utilizando los “átomos” o “moléculas” ya disponibles. Desde el punto de vista del desarrollador, poder generar el código para este componente o patrón ayuda a evitar inconsistencias entre las especificaciones de diseño y el código.
La velocidad de aprendizaje es un beneficio no tan obvio de utilizar un enfoque de sistema de diseño. Ahora que los diseñadores se han liberado de la creación de píxeles, pueden volver al verdadero proceso de diseño, centrándose en diseñar recorridos o flujos de usuarios y evaluarlos con los usuarios. El enfoque utilizado para crear entregables de diseño también se puede utilizar para producir prototipos provisionales para [pruebas de usabilidad](#) y [obtener comentarios de las partes interesadas](#).
¿Paisajes cambiantes o cómo se entrelaza el futuro de los sistemas de diseño con la automatización y las herramientas de código bajo?
¿Qué herramienta de diseño utilizas?
Los procesos de diseño son a veces más complejos, dispersos y caóticos de lo que deberían ser. En tales casos, exigen un sistema de diseño como función estratégica y como instrumento para mejorar la colaboración. Como comentamos, un sistema de diseño sirve como una especie de conocimiento común que puede ayudar a alinear el diseño y el desarrollo. Es un foro donde los equipos pueden codificar (tanto como puedan) las mejores prácticas. Y dado que se supone que es un sistema vivo, también brinda oportunidades para que se discutan y luego se absorban nuevos patrones, requisitos e incluso soluciones de generación de código (como el uso de creadores de aplicaciones de bajo código a lo largo del proceso). Más importante aún, un sistema de diseño no es solo un repositorio, sino una forma de colaborar. No es una solución milagrosa para los desafíos que enfrentan los diseñadores y desarrolladores al colaborar. La existencia de un sistema de diseño tampoco impide una conversación significativa entre las dos disciplinas.
El mayor desafío para muchas empresas es comenzar con un enfoque de sistemas de diseño relevante que resuene con sus necesidades y, al mismo tiempo, con la transformación digital en curso. Para algunos, que ya tienen una gran variedad de aplicaciones disponibles, la fase inicial es tediosa. Si bien hay varios sistemas de diseño disponibles como referencia, cada uno ha sido creado para su propia organización matriz. Al mismo tiempo, también tienen mucho en común en términos de patrones de UX y mejores prácticas. Por lo tanto, existe la necesidad de herramientas y servicios para ayudar a las organizaciones a crear rápidamente su propio sistema de diseño, y no copiarlo ciegamente.
El tipo de proceso simplificado y coherencia del que hablamos se puede lograr mediante automatizaciones y complementos que, por ejemplo, le permiten aplicar un tema general a su biblioteca de diseño de una sola vez. También significa permitir enfoques innovadores y mucho más eficientes para manejar el traspaso entre diseñador y desarrollador, ahorrándose el tiempo y la energía de intentar explicar ideas o justificar animaciones y microinteracciones que normalmente no están en los archivos Sketch, Adobe XD y Figma.
Entonces, en un panorama altamente digitalizado, el uso de herramientas como App Builder se convierte en la columna vertebral de un sistema de diseño funcional y eficaz para equipos y empresas. Para ilustrar mejor cómo altera positivamente el diseño y el desarrollo, esto es lo que hace App Builder:
- Se suma al kit de interfaz de usuario de materiales con kits de interfaz de usuario para Bootstrap, Fluent e Indigo. Esto brinda a los equipos de diseño la capacidad de apuntar a cualquier sistema de diseño popular, personalizable según los temas, partes de la pantalla y patrones de UI que se transfieren sin problemas a App Builder para aplicaciones con píxeles perfectos y generación de código para Angular o Blazor.
- Toneladas de controles y funciones de generación de código, desde datos vinculados y controles de navegación hasta generación de código para aplicaciones Blazor y Angular.
- Plantillas de aplicaciones y diseños de pantalla: para iniciar el diseño de aplicaciones y ayudar a crear páginas responsivas con un solo clic. Alivian la parte más difícil del desarrollo de aplicaciones para los desarrolladores: codificar manualmente CSS responsivo para la web y crear diseños complejos e interactivos con controles de interfaz de usuario reales vinculados a datos reales.
Es importante tener en cuenta que un sistema de diseño no son solo las mejores prácticas de UX y kits de UI. También necesita componentes de interfaz de usuario coincidentes en el lado del desarrollo. Si bien el movimiento de sistemas de diseño ha sido tradicionalmente defendido por equipos de diseño dentro de grandes organizaciones, para que realmente tenga éxito, el equipo de desarrollo también debe convertirse en copropietario/contribuyente del sistema de diseño.
Además, la estructura átomos-moléculas-organismos es sólo el punto de partida para el diseño de sistemas, pero no tiene por qué detenerse ahí. Puede contener información adicional sobre cómo se supone que deben comportarse las aplicaciones. A continuación se muestra una lista de candidatos potenciales para su inclusión en un sistema de diseño, que de ninguna manera es exhaustiva:
- La guía de diseño de interacción describe cómo los usuarios interactuarán con las aplicaciones, ya sea mediante gestos, mouse o teclado. Describe lo que se debe y no se debe hacer. El diseño de materiales de Google lo hace muy bien.
- El movimiento y las transiciones son cada vez más comunes para proporcionar un nivel de dinamismo y placer al usar aplicaciones. Sin embargo, si bien podemos entender algunas de las transiciones de forma aislada, es bueno estandarizarlas para las aplicaciones (por ejemplo, transición de diapositivas para la transición maestro-detalle).
- Las historias de usuarios pueden ayudar a documentar cómo se han realizado algunas de las tareas comunes o especializadas en la aplicación. Puede servir de inspiración para nuevos diseños.
- Aplicaciones de referencia que muestran cómo las diferentes piezas de un sistema de diseño pueden funcionar juntas.
Entonces, construir, usar y mantener un sistema de diseño conduce a experiencias más coherentes porque no hay necesidad de reconstruir componentes o patrones. En cambio, los diseñadores y desarrolladores se benefician de un inventario unificado que fomenta la reutilización y ofrece recursos de diseño flexibles, ahorrando tiempo y esfuerzos al diseñarlos desde cero. El futuro de los sistemas de diseño también dicta prácticas que rigen estándares claros y el cumplimiento práctico de la marca a través de tipografía, colores, voz y tono consistentes.
Pero hay algo más: el exitoso sistema de diseño actual también requiere un cambio cultural común y una mentalidad diferente que:
- Cultiva la funcionalidad cruzada, incluyendo a diseñadores y desarrolladores para canalizar mejor las ideas y los resultados, mejorar la calidad del producto final y aumentar el impacto que los equipos generan juntos.
- Da la bienvenida a herramientas, sistemas y servicios como App Builder en torno a prácticas de UI y UX ya establecidas para pulir hojas de ruta, eliminar silos, reducir tareas repetitivas, ayudar a establecer una única fuente de verdad y mejorar la velocidad y la calidad del diseño y desarrollo de productos digitales.
¿Por qué elegir Indigo.Design para su sistema de diseño?
Además de ayudar a los equipos a implementar una arquitectura sólida y preparada para el futuro de un sistema de diseño, ahorra tiempo y esfuerzos y permite a los diseñadores centrarse en el diseño real.
- Lo que distingue Indigo.Design:
- Tiene kits de interfaz de usuario de terceros que siguen exactamente el mismo sistema de diseño para todas las tecnologías, lo que significa que los diseñadores pueden incluso cambiar la herramienta que elijan y al mismo tiempo poder diseñar con símbolos proporcionados por nosotros para la herramienta específica.
- Representa una biblioteca nativa para Sketch y Adobe XD (pronto para Figma) que utiliza los metadatos detrás de los símbolos del kit de interfaz de usuario para incorporar las pantallas diseñadas al App Builder y visualizarlas en términos de componentes reales.
- No solo entrega componentes con estados sino también plantillas y variantes que se ajustan automáticamente cuando el usuario del sistema de diseño cambia la configuración de un componente.
- Funciona con App Builder para crear componentes reales en la web.
- Resume una forma de definir la estructura, las vistas y las interacciones de la aplicación.
- Le permite tener una misma aplicación en diferentes tecnologías.
- Toma un diseño, lo hace comprensible para App Builder y permite la vista previa y generación de código para Angular o Blazor (Web Components y React próximamente).
- Define patrones comunes entre tecnologías.
- Generado por analizadores de herramientas de diseño además de los kits de interfaz de usuario, App Builder u otros complementos de terceros.
- Tiene potentes mecanismos para temas, marcas y otras opciones de personalización.
- Implementa distintas variantes para Material, Bootstrap y Fluent que se parecen a estos marcos.
Sigue leyendo
Rellena el formulario para seguir leyendo.