¡Muerte para procesar máquinas!

Encuentre su proceso de diseño ideal siguiendo algunos principios simples en lugar de un guión rígido.

Escuchará un montón de consejos diferentes sobre la forma correcta e incorrecta de diseñar una aplicación o sitio web.

"Deberías estar usando Sketch".
"Sistemas de diseño o GTFO".
"Los diseñadores reales diseñan 100% en código".
"Wireframes son una pérdida de tiempo".
"Si no está haciendo prototipos, no lo está haciendo bien".
“Necesitas comenzar en papel”.

Uno pensaría que no hay acuerdo alguno sobre la forma correcta de diseñar, pero hay un punto que está en gran parte libre de controversia: que su proceso debe ser lineal.

El enfoque lineal clásico se parece a esto:
investigación → bosquejo → estructura metálica → compilaciones estáticas → prototipo → código

Es algo así como esas máquinas de fabricación al estilo Rube Goldberg que usan para hacer Doritos y Ding-Dongs. Deje caer una idea en la máquina de proceso, y después de ser machacado y moldeado a medida que avanza por los escalones, ¡un producto terminado sale por el otro lado! ¡Previsible! ¡Eficiente!

Mas o menos.

Las máquinas de proceso funcionan, pero solo cuando funcionan. No se adaptan, y eso los hace frágiles. Todo lo que se necesita es un pequeño Sabot para detener su máquina de proceso.

Hank, también conocido como "el Sabot"

He estado viendo Finding Dory con mi hijo últimamente, y parte de la filmación de la "toma de decisiones" no deja de sorprenderme.

En la película, hay un pulpo llamado Hank:

Disney / Pixar

Septopus, técnicamente. Trabajar con su modelo de personaje era tan oneroso que cortaron un tentáculo para hacer posible la animación de él. Aún así, con 4.000 controles separados con los que era increíblemente difícil trabajar.

En este punto del proceso, ya han pasado bocetos, representaciones y animaciones, esas etapas de baja fidelidad que lo ayudan a examinar un montón de ideas de manera rápida y económica. Ya se pusieron reales también. Se construyó la plataforma de personajes, se resolvieron los detalles técnicos y se respondieron preguntas fundamentales.

Están en la etapa final de animación: modelos 3D en entornos 3D. Podrían haberse vendido a expensas del cronograma y el presupuesto de producción. En cambio, hicieron algo realmente interesante: volvieron a dibujar.

Disney / Pixar

Al esbozar el complejo movimiento de los tentáculos de Hank sobre el papel, podrían lograr la animación perfecta y fluida que estaban buscando en una fracción del tiempo. Una vez que estaban contentos con la secuencia, se animaban en 3D para combinar. Obtuvieron un mejor producto en menos tiempo porque decidieron valorar los principios del proceso en lugar de una prescripción del proceso.

La cura para un proceso prescriptivo

El equipo de Finding Dory hizo un mejor producto más rápido al tomar decisiones que priorizaban la velocidad y la calidad en lugar de apegarse a un proceso de memoria.

Puede elegir otras cosas para valorar, pero si está trabajando en un entorno comercial, centrarse en el punto óptimo entre velocidad y calidad debe estar en la parte superior de su lista. Convertir un gran trabajo rápidamente es un gran problema para los diseñadores y artistas profesionales, después de todo.

Definir los principios que impulsan su proceso es solo el comienzo. Así es como puedes ponerlos en práctica.

Comience con las grandes preguntas

Si valora la velocidad, comience un proyecto descubriendo cuáles son las preguntas más importantes y fundamentales. En Getting Real, esto se llama "diseño de epicentro":

Comience desde el centro de la página y construya hacia afuera
El diseño del epicentro se centra en la verdadera esencia de la página, el epicentro, y luego se desarrolla hacia afuera. Esto significa que, al principio, ignora las extremidades: navegación / pestañas, pie de página, colores, barra lateral, logotipo, etc. En cambio, comienza en el epicentro y diseña primero el contenido más importante.
Cualquiera que sea la página sin la que no pueda vivir es el epicentro. Por ejemplo, si está diseñando una página que muestra una publicación de blog, la publicación de blog en sí es el epicentro. No las categorías en la barra lateral, ni el encabezado en la parte superior, ni el formulario de comentarios en la parte inferior, sino la unidad de publicación de blog real. Sin la unidad de publicación de blog, la página no es una publicación de blog.
Solo cuando esa unidad esté completa comenzará a pensar en el segundo elemento más crítico de la página. Luego, después del segundo elemento más crítico, pasaría al tercero, y así sucesivamente. Ese es el diseño del epicentro.
El diseño del epicentro evita el modelo tradicional de "vamos a construir el marco y luego soltar el contenido". En ese proceso, se construye la forma de la página, luego se incluye la navegación, luego las "cosas" de marketing
 se inserta, y luego, finalmente, la funcionalidad principal, el propósito real de la página, se vierte en cualquier espacio restante. Es un proceso hacia atrás que toma lo que debería ser la máxima prioridad y lo guarda para el final.

Aquí hay un ejemplo de por qué esto es crucial. Estaba trabajando en una pequeña aplicación de proyecto de iOS que utilizaba una interfaz de audio única, posiblemente inviable. Si no valorara la velocidad, podría haber pasado innumerables horas diseñando los innumerables detalles que se basaban en esta idea única. El diseño viene antes que el código en el proceso lineal clásico, después de todo.

En cambio, comencé en código para descubrir si esta idea era viable o no. ¡No lo fue! Así que ajusté mis planes y me ahorré una enorme cantidad de tiempo y energía.

Solo pregunte, WMGMTCATMQITLAOT?

Una vez que sepa las preguntas que necesitan respuestas primero, pregúntese:
"¿Qué medio me da la respuesta más clara a mis preguntas en el menor tiempo posible?"

En el caso de mi proyecto paralelo, la respuesta fue el código. Para una página en Basecamp.com, la respuesta suele ser texto o un boceto. Para ti, podría ser algo completamente diferente.

Saber cuándo cambiar de marcha

Eso le da un lugar para comenzar, pero ¿cómo sabe cuándo es el momento de cambiar a un medio diferente? Cuando golpeas la resistencia.

Piensa en conducir un auto. Estás navegando por la carretera: el motor ronronea como un gatito satisfecho. Pero luego comienzas a conducir cuesta arriba. El equipo en el que estás fue genial para navegar, pero no para escalar colinas. Para mantener tu velocidad, cambias a una nueva marcha.

Lo mismo aqui. Pero a diferencia de los automóviles, no hay un indicador sólido de que haya encontrado demasiada resistencia en su medio de elección. Afortunadamente, la mayoría de los diseñadores y artistas tienen un control sólido cuando necesita cambiar a un medio que ofrezca más fidelidad. Esta es la parte que se alinea con el clásico proceso lineal de baja fidelidad → alta fidelidad después de todo. Usted sabe que está listo para pasar del boceto cuando el boceto deja de brindarle información útil.

Una vez que llegue a este punto, descubra el siguiente conjunto de preguntas más importantes y pregúntese nuevamente: "¿qué medio me da la respuesta más clara a mis preguntas en el menor tiempo posible?"

El segundo caso, volver a una fidelidad más baja, es más difícil. Tanto porque las personas son menos practicadas, como porque es complicado. Toma trabajar en código. Estás trabajando al 100% de fidelidad, por lo que no hay límite para la capacidad del medio para responder preguntas. Pero hay un límite en su capacidad para responder preguntas rápidamente.

Cuando sienta que no está siguiendo caminos porque se siente como demasiado trabajo, es una buena señal de que necesita retroceder. Cuando las cosas parecen que simplemente no están haciendo clic como deberían, es hora de volver a evaluar. Tenga en cuenta y comenzará a desarrollar una sensación.

Usando un medio para su ventaja

Hay un tercer caso para cambiar, o quedarse con, un medio. A este no le importa la resistencia, solo le importa una verdad fundamental; El proceso influye en el resultado. Al igual que dibujar algo con un lápiz se verá diferente a dibujarlo con un marcador, el diseño en el navegador producirá un resultado diferente al diseño en Sketch.

Cuanto más comprenda cómo un medio afecta su trabajo, el tipo de herramienta que deja, más puede usarlo para su ventaja. ¿Quieres que tu diseño sea expresivo? Probablemente sea mejor trabajar con una herramienta visual como Sketch, Illustrator o incluso * jadeo * Photoshop. ¿Quieres un diseño minimalista y liviano? Se adhieren al diseño en código.

Un ejemplo práctico

Ahora que he comentado sobre los peligros del proceso prescriptivo, me gustaría compartir con ustedes ... mi proceso. ¡No es para que lo sigas paso a paso! Solo para darle un ejemplo de la vida real de cómo puede usar los principios para guiar su proceso.

Estamos lanzando una nueva forma de trabajar con clientes en Basecamp, y mi trabajo consistía en crear una nueva página en Basecamp.com para comercializarla. Así es como se desarrolló:

Determinar grandes preguntas, elegir un medio

Este no es un sitio nuevo o un diseño completamente nuevo. Primero, necesitaba averiguar el propósito de esta página, lo que está tratando de decir y la estructura general.

"¿Qué medio me da la respuesta más clara a mis preguntas en el menor tiempo posible?"

Comps y bocetos están fuera. Esto se inserta en un diseño existente y una plantilla existente. Podría saltar directamente al código, pero el marcado es ruido en este punto. El texto es correcto.

Un montón de copia a medio hornear

Fidelidad creciente

No me quedé con el texto el tiempo suficiente para terminar toda la copia de la página. Una vez que tuve un esquema y una idea de cómo quería hablar sobre la función, cambié los engranajes al código.

¿Por qué?

Un documento de texto no podía decirme nada sobre si una línea dejaría a una viuda, si un párrafo "se sentía" largo, cómo fluirían las imágenes, etc. Necesitaba más fidelidad. Algunas de las nuevas preguntas podrían haber sido respondidas por una compilación estática, pero eso no habría respondido preguntas sobre el ajuste de copia a menos que perdiera el tiempo haciendo coincidir la compilación exactamente con el código. No, gracias.

Trabajando a través de ediciones de copia en código

Disminución selectiva de la fidelidad

Después de algunas rondas más de revisiones de copias, la página comenzaba a tomar forma. Visualmente, fue mecánico y decepcionante. Quería que fuera más expresivo, así que me cambié a Sketch para analizar algunas ideas.

Podría haber permanecido en el código en su mayor parte, pero con Sketch podría disparar un montón de ideas mucho más rápido de lo que podría codificarlas. También me permitió comparar directamente esas ideas entre sí, y no dejaría un nido de ratas CSS de toda la rotación. Ganar ganar ganar.

Un montón de composiciones de Sketch a medio hornear

¿Te das cuenta de que ninguno de ellos está completamente horneado? ¡Es porque no importan! Estos no son para una presentación del cliente o para la transferencia del desarrollador. Están allí para ayudarme a resolver algo, luego son basura. Invertir tiempo para pulirlos habría sido una pérdida total de esfuerzo.

Terminando

Una vez que tuve una idea de la dirección, fue el código el resto del camino. Pulido de copias, capturando capturas de pantalla y siempre evaluando con respecto a la última pregunta clave: "¿Está listo para enviar?". Puedes echar un vistazo a la página de Clientes en vivo en Basecamp aquí.

No es así como se desarrolla cada proyecto. A veces esbozaré algo en Procreate, a veces comenzaré con una composición visual rápida y sucia, a veces escribiré una copia en Sketch, a veces trabajaré al 100% en código. Todo depende del proyecto en cuestión.

Con suerte, eso le dará una idea de cómo puede usar los principios para guiar su proceso caso por caso sin sentir que reinventa constantemente la rueda.

Piensa en tu proceso y el tipo de trabajo que haces. Defina los principios que son importantes para usted, enfóquese primero en las cosas importantes y siga preguntándose si el medio en el que está trabajando es el correcto por el momento. Tu trabajo será mejor por ello.