¿Cuál es la forma científica de construir un sitio web? Nuestro enfoque es crear flujos de usuarios mediante gráficos, describirlos en documentos, crear interfaces de usuario y entregarlos a los desarrolladores. ¿Es esta una buena manera? Estoy haciendo tanto el análisis como la experiencia de usuario.

Para cuando haya realizado toda esa investigación y documentación, el mercado ya está cambiando. Ha creado una instantánea precisa de dónde estaban las cosas, pero a medida que los desarrolladores comienzan a construir, el mercado sigue avanzando y están creando una solución para un mercado que existía hace una semana, mes o año.

Las cosas que has mencionado son herramientas. Todas son buenas herramientas, y cada una puede ayudar a comprender y comunicarse. Desde una perspectiva de TTP (tácticas, técnicas y procedimientos), está bien, pero está haciendo lo que a menudo se denomina “cascada” en la gestión de proyectos. Se llama así porque al mirar un gráfico en MS Project o un programa similar, un solo equipo trabaja en el proyecto antes de que “caiga” a la siguiente línea, que luego se trabaja y se entrega nuevamente, cayendo en cascada en el gráfico hasta que se envía .

La pieza principal que te falta arriba es la investigación. Hablando con los usuarios. Hacer preguntas que no solo justifiquen el producto como se imaginó, sino que lo ayuden a ver el problema que tiene el usuario y luego le permita enmarcar una solución a ese problema.

Debería investigar Lean UX y ver si puede aplicar ese ciclo corto, altamente integrado con los desarrolladores, en su producto. Deberías estar sentado con los desarrolladores, no entregarles especificaciones y decir “¡diviértete!” Invariablemente, descubrirás casos extremos a medida que los ingenieros lo construyan que no imaginaste.

También desea realizar pruebas de prototipos de baja y alta fidelidad antes de esto. A veces es un prototipo HTML / JavaScript, pero a menudo se realiza en Keynote (con Keynotopia o un producto similar) o Sketch o AdobeUX.

Hay libros escritos sobre estas cosas, así que simplemente lo referiré a algunos:

“Lean UX” Gothelf & Seiden

“Acerca de la cara” Cooper, et al.

“Sprint” Knapp, et al.

Y casi todo de la biblioteca de Rosenfeld Media.

La forma científica no tiene nada que ver con las estructuras de datos que usa (gráficos) o la descripción de cosas en documentos o dibujar diagramas elegantes. De hecho, los científicos escriben artículos, que generalmente hacen un trabajo horrible al describir lo que encontraron. De lo que estás hablando es de la organización general de la comunicación de tu equipo.

La forma científica es básicamente definir hipótesis sobre la naturaleza del universo y luego validarlo mediante la realización de experimentos.

Este proceso se describe más o menos en libros como The Lean Startup (libro). En su caso, desea crear un producto que funcione para maximizar ciertos KPI. La naturaleza del universo en su caso es el comportamiento de los usuarios de su sitio.

Por ejemplo, si está creando un sitio web de comercio electrónico, probablemente desee optimizar las tasas de conversión y retención. Por lo tanto, deberá comparar varios elementos diferentes de la interfaz de usuario para ver qué grupo de sus visitantes se convierte mejor.

Agile hace que el diseño iterativo sea más realista. Si usa ágil, es mejor combinar el proceso de diseño con el proceso de desarrollo dentro de los sprints ágiles.

Por lo tanto, haría un diseño de “sprint-ahead” basado en su diseño MÁS comentarios y observaciones que obtenga del desarrollo anterior / actual.

Como arquitecto de aplicaciones web, veo que el patrón de los diseños de UX se “arroja sobre la cerca” a los desarrolladores como un antipatrón. ¿Por qué?

  1. Los desarrolladores deben rechazar lo que es demasiado complejo o imposible.
  2. ¡Los desarrolladores y el control de calidad tienen ideas! Escúchalos.
  3. Obtendrá ideas a medida que vea que los desarrolladores luchan por implementar su diseño.
  4. El control de calidad en particular estará encantado de contarle todo sobre por qué un flujo de usuarios tiene problemas, o preguntar por qué no estamos usando un patrón de interfaz de usuario convencional.

La innovación no es simplemente dar al cliente lo que dijo que quiere .

La innovación significa correr el riesgo de darle al cliente lo que querría, ¡si tan solo supiera que podría tenerlo!