¿Cuál es la mejor manera de lograr que un equipo de UX/UI adopte estándares?

Somos un equipo de alrededor de 4 desarrolladores de UI, 1 diseñador y 2 UX. Trabajamos en una serie de proyectos en curso y cada mes comenzamos un nuevo proyecto pequeño desde cero. Todos los proyectos son propiedad de la empresa para la que trabajamos.

Hasta ahora, cuando comenzaba un nuevo proyecto, el equipo de UX y Diseño comenzaba casi desde cero. No existen estándares con respecto a la tipografía, tamaños de fuente, márgenes, rellenos, colores de botones, etc.

No hay consistencia de marca entre nuestros proyectos en este momento. No podemos asignar tiempo para iniciar un proyecto de "marca". Lo que podemos hacer es decidir sobre los estándares sobre la marcha.

Mi pregunta es, ¿cuál es la mejor manera que se te ocurre de empezar a organizar el equipo para que adopte lentamente los estándares de diseño? Dónde y cómo lo compartiría y se aseguraría de que el equipo lo sepa. ¿Qué incluirías en la norma?

El marco de tiempo sería de 2 a 3 semanas mientras trabajaba en otros proyectos. La alta dirección no considera esto una prioridad.

Vlad, edité el título y algunas palabras en la pregunta para ayudar a obtener respuestas más directamente relevantes de la comunidad. Avísame si estoy fuera de lugar.
Tal vez preguntar por los chicos de UX también podría traer algunas ideas geniales... ux.stackexchange.com
De cualquier manera, para que quede claro, considero que esta pregunta es un tema para PMSE viéndola desde el punto de vista de 'cómo aplicar estándares en un proyecto' (independientemente de qué estándares).
Tienes razon Tiago. Actualicé la pregunta en ux.stack ux.stackexchange.com/questions/29242/… .

Respuestas (1)

Realmente hay dos maneras de manejar esto. Uno es más intencional que el otro.

Y una razón más importante para ello que podría estar detrás de él.

La primera es hacer un "lecciones aprendidas" después de cada proyecto. Qué salió bien, qué salió mal, qué podríamos hacer mejor, qué nuevos riesgos identificamos, etc. Durante este tiempo, una de las cosas que puede revisar es la idea de los 'estándares'. ¿Qué necesitábamos decidir? ¿Hemos tenido esta misma discusión antes? ¿Se nos ocurrió la misma solución? ¿Usamos algo de nuevo que ya sabíamos? Use este tiempo para codificar los estándares.

El otro enfoque es encontrar algo de tiempo para volver atrás y revisar proyectos anteriores en busca de esos temas comunes, esas cosas que sigues preguntando y cuáles son las respuestas. Desarrollará los estándares a partir de las cosas comunes que vaya encontrando.

Por último, mgmt (2 argumentos) -

  1. reinventar la rueda cuesta dinero cada vez que lo haces. Por lo tanto, lo mejor para la empresa es desarrollar estos estándares para ahorrar tiempo y dinero en todos los proyectos futuros. Para cada proyecto que presente una oferta, podrá eliminar la cantidad de tiempo dedicado a definir estos elementos. Eso se traduce en más ganancias o en una oferta más baja (lo que asegura más trabajo). Colóquelo como un costo a corto plazo para ganancias a mucho más largo plazo.

  2. El tipo de estimación más preciso proviene de los datos históricos. Los datos históricos solo provienen de una revisión exhaustiva de proyectos anteriores y de encontrar la forma "estándar" en que se hicieron las cosas y cuánto costó. Por lo tanto, tomarse el tiempo para encontrar y desarrollar estos estándares no solo mejorará sus ofertas y eliminará costos, sino que hará que sus ofertas sean mucho más precisas. Eso ayuda tanto con el trabajo en progreso como con las proyecciones de efectivo.

Me gusta mucho la idea de "lecciones aprendidas". Es brillante. ¡Gracias!