Manifiesto

Para el consumo de Plural DS

Plural DS NO restringe la creatividad en tu proyecto

La creatividad puede ser un atributo de tu proceso de diseño para encontrar una solución a un problema de usuario, pero el proceso de diseño siempre ocurre entre limitaciones: tiempos, asignación de recursos o barreras técnicas. No culpes a las restricciones que enmarcan un problema.
Si las restricciones imposibilitan resolver el problema de un usuario… de la misma manera que pedirías más tiempo o recursos, en el caso de Plural, puedes solicitar que ampliemos el Sistema.
“A designer solves problems within a set of constraints”.

La razón por la que creamos Plural DS no fue diseñar menos, es pensar mejores productos

Queremos solucionar un buen número de problemas reales de usuarios mediante un conjunto limitado de componentes y patrones estandarizados, esto es mucho más trabajo que ser creativo con cada uno de esos problemas.
Esto no quiere decir que los componentes existentes en Plural deban solucionar todos los problemas, ni que todos los problemas tengan que ser solucionados mediante nuestros componentes. Siempre ajusta el uso de los componentes que te ofrecemos a la persona, contexto y dispositivo. Si necesitas una nueva pieza reutilizable, puedes solicitar que ampliemos el Sistema.

Utilizando Plural DS estás asegurando estándares y conocimiento, esto elimina la subjetividad de nuestras soluciones.

Las piezas reutilizables dentro de Plural DS son soluciones estandarizadas y testadas. En la medida que las incluyes en tus proyectos estás eliminando opiniones subjetivas y generando conocimiento consistente.
Ordo Ab Chao” - Lema del grado 33 en la Scottish Rite Freemasonry.

Para la construcción del sistema

El mejor sistema de diseño es el que se usa

Somos un colectivo que se dedica a la construcción de sistemas de diseño, tenemos un posicionamiento claro sobre las mejores prácticas, herramientas y metodología para la construcción de un sistema.
Por nuestra experiencia en la adopción de sistemas de diseño sabemos precisamente que la clave es su uso, no la forma en la que está construido. Una vez en uso siempre podremos mejorar su construcción pero no al contrario, prioriza siempre adopción sobre construcción.
Recomendar, pero no obligar. Ser flexibles y empáticos con las necesidades de quien lo consume es infinitamente mejor que intentar imponer un modelo técnicamente superior pero que genera rechazo a los equipos, las personas o la organización.
Luis Montoro dixit.

Querido equipo de diseño constructor, tus librerías en Sketch o Figma no son el Sistema de Diseño

Son una representación de acuerdos que se ha llegado dentro de Sngular respecto a algunos elementos de interfaz, son una parte de Plural, pero desde luego no son el todo.
Tenemos un proceso completo de integración con desarrollo. Nuestros consumibles en diseño han de seguir siendo espejo de los consumibles disponibles en desarrollo.

NO nos olvidamos de quién lo usa

Como persona constructora de Plural DS construyes soluciones para otros miembros del equipo de diseñado y desarrollo, ellos son nuestros usuarios. Construimos lo que se necesita y NUNCA al revés. Aunque te identifiques con quien lo usa, es posible que seas de diseño o desarrollo, TÚ NO ERES TUS USUARIOS.
Descubre sus necesidades reales y construye exactamente lo que necesitan. Habla con estos equipos, realiza entrevistas, tests, construye artefactos y sobre todo, válida antes de entregar una propuesta como solución.