1. Propósito: un producto funcional que la gente usa

Un objetivo tan simple. Analizaremos cada palabra, porque no está tan formulada por estas palabras.

Preste atención a la falta de palabras de proceso, como "creación", "diseño", etc. Los procesos no son un objetivo en absoluto. El objetivo solo puede ser un resultado, no un proceso. Pero los diseñadores de todo el mundo caen en la trampa mental de los procesos, por lo que los resultados de su trabajo son artefactos de proceso, no productos de trabajo.

Tengo estadísticas tristes. De cada diez diseñadores que vienen a "hacer un producto e influir en él", uno se enfoca en el resultado, el resto se enfoca en los procesos. Llega mucho tiempo, y bueno, si llega.

Antes de que llegue la indignación, aclararé: no disminuyo la importancia de los procesos y los entiendo. Marco, investigación, diseño, metodologías, especificaciones, pautas, sistemas de diseño, software profesional, etc. Tan pronto como el producto cae en manos del usuario, todo esto no tiene sentido: el producto funciona o no.

De todos modos, volvamos a la redacción.

1. Un producto que funciona es uno que puede usarse para resolver problemas. Se trata de la capacidad técnica para resolver el problema utilizando el producto.
2. El producto es una especie de entidad completa, entera, en la cantidad de ingredientes que tiene más valor que todos ellos tomados por separado.
3. Uso: habla de demanda y conveniencia.
4. Las personas son un concepto más amplio que "clientes", "usuarios", "empleados", etc. Cuando trabajamos para personas, tenemos en cuenta la ergonomía y algunos estándares.

Digamos que el producto no funciona. Aquí todo está claro: no se utilizarán (al menos para su propósito previsto).

¿O no es un producto: un conjunto de componentes dispares que no están interconectados por ningún signo (esto también sucede).

O hay un producto, pero no lo usan (en absoluto). También un fracaso, podría ser cualquiera: la falta de comercialización, incómoda, se ralentiza.

Si no lo usa la gente ... entonces, admito, habrá principios de diseño completamente diferentes.

Esta idea se discute desde diferentes ángulos cuando hablan sobre Agile, y sobre entregas frecuentes, y sobre Scrum, y sobre el trabajo en equipo, pero incluso con tales prácticas, los diseñadores de alguna manera a veces caen en una acogedora rutina de "procesos". Admito tales razones:

• No entienden las tecnologías y su influencia en ellas,
• no puede influir en el resultado (miedo "no escuchan", falta de motivación, subordinación inventada "no me dijeron que hiciera esto")
• no entiendo su papel
• un scrum se explota sin comprender el propósito, como un marco (ver también Cult of Cargo ), entonces definitivamente no es mejor que una cascada (o incluso peor)
• organizar pequeñas cascadas dentro del scrum :-) - "Primero, diseñar, luego front-end", en lugar de trabajar al menos dos / dos. Esto, por alguna razón, es especialmente difícil para los diseñadores y desarrolladores por igual (pero cuando y si lo hace, ya no quieren volver al modelo mini-agua-agua, porque es defectuoso en todos los sentidos).

PS Enlaces a descripciones de las metodologías enumeradas, Wikipedia:

• Agile (Agile): metodología de desarrollo flexible
• Scrum (Scrum): un marco para el desarrollo ágil de software (trabajo en equipo)
• Kanban (Kanban) - un sistema de organización de producción y suministro, que permite implementar el principio de "justo a tiempo"

2. El papel del diseñador en el equipo scrum.

A menudo, el papel de un diseñador en un equipo de producto es exagerado porque piensa en términos de procesos y secuencia de acciones (cascada) en lugar del resultado.

(Pensar correctamente a partir del resultado, por categorías de propósito).

El desarrollador, que acaba de hacer todo de acuerdo con los estándares y especificaciones, probablemente resolverá el problema mejor que si pasa por las maquetas del diseñador. Probablemente, incluso las métricas de comestibles serán mejores. En ausencia total de un diseñador.

“Estamos esperando diseños”: si eso suena, entonces los procesos en el equipo no están organizados correctamente.

(Por desgracia, muchos desarrolladores y diseñadores no conocen los estándares, al menos W3C para la web, y hay muchos principios fundamentales que ayudan a construir una mejor experiencia. Por analogía, hay descripciones / estándares para las principales plataformas móviles y de escritorio; iOS , Material ).

Preste atención a las nuevas empresas: Facebook, Vkontakte, Odnoklassniki y Apple con Microsoft: se basan en soluciones de ingeniería (Wozniak, Gates), a las que los diseñadores se unieron posteriormente. Crearon productos de acuerdo con el Propósito.

Primero es un producto que funciona.

(Guapo, por el bien de la justicia, lo hicieron los muchachos ideológicos en el laboratorio Xerox, pero la escala de las consecuencias es completamente diferente).

•••

¿Cuál es entonces el papel del diseñador?

Para agregar valor .

Puede agregar algo existente , preste atención.

Valor a los ojos de los clientes, usuarios.

•••

A menudo, la secuencia se invierte y "espera el diseño". Esto, por supuesto, habla de la inmadurez del equipo y la gestión inadecuada de este mismo equipo.

•••

"Layouts" es un anacronismo, el legado de una web estática que solía seguir la estética y los procesos de preparación de gráficos de revistas y periódicos. En el diseño de productos, esto ha dejado de ser relevante, pero el enfoque, en ausencia de otro, se ha mantenido, tanto en los procesos como en la conciencia.

Comience con el código en lugar de los diseños.

Aplicación: dinámica, movimiento, interacción. Por lo tanto, los diseños en el trabajo del diseñador del producto son a menudo inapropiados y contrarios al objetivo.

Es por eso que los diseñadores avanzados migran a prototipos con datos reales. ¿Esto es bueno? Creo que esto es redundante: ¿por qué programar un prototipo cuando puede (y lógicamente) programar inmediatamente un producto?

Es mejor pasar del desarrollo al diseño de inmediato. Comience con el código, el prototipo que realiza la tarea del cliente de forma mínima. Un prototipo que puede entrar en oferta de trabajo (recuerde más adelante sobre Desarrollo de clientes).

(La apertura y madurez de los desarrolladores es importante aquí: su disposición a experimentar y mejorar el programa, posiblemente incluso reescribiendo el código varias veces de nuevo. Estoy seguro de que hay muchas soluciones listas para esto durante mucho tiempo).

Comida para llevar

Darse cuenta de la tarea del usuario.

Comience por desarrollar. Trabajar en conjunto con el desarrollador (como director de arte y redactor).

Mejore un producto que funcione en lugar de diseños.

Piense en términos de objetivos, resultados en lugar de procesos.

El diseñador del producto crea el producto, no los diseños.

3. Método

Este método, junto con la biblioteca de componentes, se ha convertido en la base del sistema de diseño bancario .

Propongo trabajar en la siguiente secuencia:

1. Reconozca la tarea del cliente (usuario) y comprométala como una historia de usuario.
2. Definir métricas. ¿Cómo entendemos que la tarea del usuario ha sido resuelta? Comprometerse
3. Formular hipótesis. Comprometerse
4. Mapa de viaje del cliente.
5. Un prototipo de trabajo. MVP Desarrollo de clientes.
6. Diseños. (Con el trabajo en equipo y el sistema de diseño existente, puede prescindir de los diseños).

Tarea del cliente

Aquí todo parece estar claro, pero a menudo no lo está. Las hipótesis de interfaz se confunden con las tareas del cliente, se dan por lista de deseos del gerente y generalmente se usan para manipulaciones de equipo no tan bellas.

La tarea del cliente se identifica sobre la base de quejas ("dolor del cliente") o necesidades de investigación.

(De paso, notamos que una queja y una tarea son dos cosas diferentes, y es importante mantener la cabeza fría y no apresurarse a "resolver un problema" basado en una queja; la tarea puede ser diferente y la queja es causada por circunstancias no relacionadas. Viene con experiencia. Use el método "cinco por qué" - a veces es útil llegar al fondo de la base sobre la cual se puede formular una tarea objetiva).

Cuando se realiza una tarea, se registra como una historia de usuario. Se han escrito muchos artículos y libros sobre esto, por lo que no me repetiré aquí: estudie por su cuenta.

Para una idea del problema, recomiendo encarecidamente el libro User Story Mapping: Discover the Whole Story, Build the Right Product (Jeff Patton and Peter Economy) .

Dos tipos de métricas (¡es importante corregir ambas!)

1. La respuesta formulada a la pregunta "¿Cómo entendemos que la tarea del usuario ha sido resuelta?" Lo que queremos obtener en forma de solución.
2. Digital: valores relativos y absolutos. Más a menudo sobre indicadores cuantitativos (financieros, velocidad, clientes, tiempo). ¿Cómo entendemos que la decisión es exitosa? Hay un truco: a menudo en las presentaciones, los valores relativos están ocultos, exagerados o pierden la escala objetiva de la decisión. Por ejemplo, "el crecimiento de la audiencia fue del 3%", ¿es mucho o poco? Si se trata de 150,000 personas (un asentamiento de tipo urbano, con escuelas y jardines de infantes, tiendas y su propia administración), entonces este es un número impresionante, aunque parecen pequeñas cosas. Por otro lado, "300% de crecimiento de ganancias", si es de 300 rublos por mes, ya es un indicador dudoso. Y nuevamente, si 150,000 personas son un error estadístico en el tamaño de la audiencia de todo el producto (por ejemplo, visitando la página principal del motor de búsqueda por año), entonces estos tamaños probablemente se descuiden, aunque estamos hablando de la población de la misma aldea de tipo urbano.

A menudo resulta que las métricas surgen después de que un producto o característica ya se ha hecho. Para informar y una hermosa presentación. Esto es triste y no muestra habilidad, pero, por el contrario, arruina la imagen y crea una falsa sensación de calma (siempre se produce un ajuste de cuentas). La situación se ilustra muy bien con el chiste sobre el mejor arquero del mundo.

Hipótesis: la respuesta a la pregunta sobre la forma más rápida de resolver el problema del usuario

Siempre hay varias soluciones al problema. En el desarrollo (diseño) no se puede limitar a uno! Nadie sabe de antemano cuál funcionará mejor.

Haz un trabajo mental y encuentra al menos tres soluciones diferentes.

Tenga en cuenta que "desarrollar" una idea en forma de diseño que cambia progresivamente es una solución, no tres (o cuántos diseños diferentes ha logrado hacer).

Para simplificar, pruebe tres enfoques:

1. Solución de interfaz. También puede haber varios.
2. Automático (por ejemplo, una tarea se realiza en el servidor cuando se produce un evento), sin intervención del usuario.
3. Procesos: lo que se puede cambiar en los procesos para que el usuario no encuentre ninguna tarea, pero reciba una solución en el momento adecuado.

La mejor solución se encuentra exclusivamente de forma empírica (ver "Método científico"). Debe comprobarse incluso la solución / idea más salvaje a primera vista. Las hipótesis deben ser verificadas. El caso ideal es probar las tres hipótesis realizadas en forma de MVP. Harás un prototipo para esto.

El mapa del recorrido del cliente se sumerge en el contexto

Si tiene un producto pequeño con una sola función, CJM le permite ver todo el proceso de resolución de un problema por parte del usuario e identificar puntos débiles, darse cuenta de la finalización real de la tarea.

Si la tarea es desarrollar una característica en una aplicación existente, CJM se sumerge en el contexto y proporciona una solución perfecta al problema. A menudo, ignorando el contexto, los diseñadores y gerentes de producto crean una "nueva sección", propagando entidades, complicando la navegación y creando confusión en la interfaz.

Se ha escrito mucho sobre CJM, debe estudiarlo usted mismo y aplicarlo en su trabajo.

Puede comenzar con el libro " Historias personalizadas " de Jeff Patton.

Un prototipo de trabajo. MVP Desarrollo de clientes.

Acuerde con el desarrollador y haga un prototipo funcional para probar cada hipótesis. Esta no será necesariamente la solución ideal tanto técnica como estéticamente: es importante crear un producto mínimamente viable ( MVP ), en el que las pruebas puedan involucrar a clientes nuevos y existentes (Desarrollo de clientes).

« . Lean Startup -» . .

MVP, . .

,

Durante el desarrollo de MVP y las pruebas de prototipo, seguramente refinará muchas cosas pequeñas en cada entrega y después de cada sesión de comentarios de los usuarios. Lo máximo que tendrá que hacer es alinear las pantallas de la solución preparada con estilo y volver a probar. Una nueva mirada al producto puede sugerir nuevas soluciones, simplificar algo aún más y repensar, hacer que el resultado sea aún más conveniente y más bonito para el usuario: aquí es donde aparece el valor agregado.

Comida para llevar

Para informacion

Lo más grande que puedes hacer

, / , . , .

.

, - , . , , . -. : , - , . , , , .

: , , . . , , .

, . ( ), , , , . , ( , «»; — ).

: , . , . — -: , — . -, . , , , , . ( «»), /. / , : / , , .

, .

, .

?

, / (), , , , . . , , .

, .

: ?

? ?

?

30 ? ?

? , ?

?

, ?

— , . .

, . — , : , . .

.

« », .

Método cientifico

, . , . . , - . .

: .

? . ? .

. , — «» :-)

.

. : , , .

, , . ( ).

: , . : / .

:

1. , : , -, (// ). . ( ).
2. , , — . , : , «, » ( ), , «», . — .
3. , . , — . — /, . — , , , , . - . , — . « ».

Total

1. — .
2. — .
3. «» .
4. Todo lo que solo se apoya en la “opinión experta” y la “experiencia” (en soluciones específicas de interfaz / producto) se envía a la basura con valentía; solo debe centrarse en observar el comportamiento de los usuarios reales.

Y otro bono

Hice una colección temática, principalmente sobre diseño, y desde que abandoné el banco, también hay una reflexión inevitable sobre el tema del diseño en la corporación. Una mirada al trabajo sin gafas de color rosa.

Descargar ePub