Planificación de contenidos y wireframing. Muchos clientes no quieren oír hablar de esto

Question

A veces me encuentro con clientes que huyen o evitan la planificación de contenidos o el wireframing. Odio trabajar con lorem ipsum, necesito el contenido, necesito planificar todo para diseñarlo, ¿no es esto de lo que se trata?

La mayoría de los diseños de sitios web requieren un plan, sin embargo, siento que a algunos clientes no les gusta que se les cobre por el wireframing.

¿Debería pasar por alto a estos clientes, o existe un enfoque para convencer al cliente de que tener, planificar y esquematizar el contenido es la base del diseño del sitio web?

Pocas veces he tenido clientes que me dijeran "aprecio tu manera profesional de tratar esto".

La mayoría de las respuestas que recibo al enviar los wireframes son "Me parece bien, procedamos" y ningún otro comentario. No es de extrañar que luego exijan cambios estúpidos en el diseño.

¿Cómo lo afronta?

Answer 1

No estoy 100% seguro de que esto esté relacionado con el "freelance" tanto como con el flujo de trabajo. Pero...

El encuadre de los cables me parece fundamental. Pero a menudo hay que explicárselo al cliente. Como mínimo, el nivel de importancia debe explicarse a los clientes.

• Este es el esqueleto o la columna vertebral de su sitio. Muestra el tamaño relativo y el posicionamiento de las áreas generales de contenido que hemos discutido.
• La aprobación de esta estructura de contenidos será la base del diseño posterior.
• Los cambios solicitados en una fecha posterior que se desvíen de esta columna vertebral pueden incurrir en costes adicionales y el tiempo para completarlo.

Si un cliente lo deja pasar con un "de acuerdo, procedamos", más tarde, cuando quieran cambios en el diseño, es mi trabajo señalar el esquema y explicar "usted aprobó esto" junto con "habrá costes adicionales".

Answer 2

Veo dos problemas potenciales:

1: Su proceso de ventas y la articulación de la propuesta de valor.

2: Posiblemente su anotación y marcado de los wireframes

En primer lugar, estás separando el wireframing y el diseño, pero ambos son tipos de diseño. En segundo lugar, si un cliente no puede entender un wireframe, entonces no lo has explicado lo suficientemente bien. Nosotros entendemos los wireframes porque estamos acostumbrados a ellos, pero para un cliente será árido. Puedes usar algo como Lucidcharts para construir un wireframe que sea navegable - yo lo uso y es como Visio en la web por cien dólares al año.

Cuando se presenta el trabajo, el primer proceso es el wireframing, porque define la disposición y la usabilidad (ambas partes del diseño) y, como dice Scott en su respuesta, permite seguir las desviaciones de la columna vertebral del sitio propuesto.

No trate el wireframing como algo que no es necesario. Yo he dejado de llamarlo wireframing (es decir, la palabra "wireframing" no aparece en el presupuesto) y en su lugar lo hago parte de la fase de conceptos de diseño. Los clientes parecen ser más capaces de entender la frase "conceptos de diseño" (puedes seguir explicando que sólo contendrá la forma y la estructura del sitio).

Answer 3

Estoy de acuerdo. Creo que la respuesta más frecuente es que están pagando a un proveedor de servicios externo (autónomo o agencia) para que les quite el tiempo y la responsabilidad. No quieren formar parte del proceso, ya que creen que para eso les pagan.

Así que, en cierto modo, se trata más bien de que el wireframing y la UX son partes realmente ágiles que a menudo se presentan de nuevo en un proceso en cascada. Hay que intentar venderles agilidad, y no que haya que hacer todo el proceso iterativo hasta el final. Sólo que si forman parte del proceso en algunas etapas, el producto crecerá a su alrededor y se adaptará mucho mejor y se venderá mejor a los clientes.

He visto esto como freelance y como contratista de una agencia en los últimos 3 años. La parte que es una apuesta en un proyecto es si usted consigue un buen propietario del producto en el cliente. ¿Conseguirás a alguien que tenga el tiempo para darte 1-3 días a la semana para hacer, no su trabajo normal (que a menudo es la clave, este proyecto no está pagando sus facturas o la descripción del trabajo).

Así que intento mejorar dando pequeños pasos con la persona o personas del cliente para ver si entienden el concepto y tienen tiempo. Algunas de las personas que establecen el contrato no son las que lo van a utilizar y no tienen ningún interés, aparte de conseguir un buen precio, así que no importa el proceso que les des, lo máximo que harán son sesiones informativas visuales periódicas y la aprobación.

Si puedes vender Scrum ágil con reuniones de planificación de lanzamientos y luego reuniones de planificación de sprints, sabes que al menos dedicarán algo de tiempo a la planificación contigo y así pueden estar abiertos a entender lo que es la ux y los wireframes. La mayoría de los clientes no tienen ni el tiempo ni el vocabulario para tratar con ello. Por ejemplo, cuando les pido que ponderen los bloques de la página a un total de 10, se alegran de que lo haga.

Así que, si se mantiene el wireframing como un costo y estar feliz de que no se comprometen y que han tenido que pagar por más de pensamiento por adelantado por usted. O lo mantienes todo en casa y no cobras por ello. Dale a los clientes 10 años más y algunos podrían estar más metidos en el proceso.

Answer 4

Me gusta la forma en que Scott responde definiendo lo que son los wireframes en términos sencillos.

Sin embargo, es posible que siga teniendo muy poco significado para el cliente.

Como muchas cosas nuevas, porque si nunca se muestra un ejemplo, el cliente puede entenderlo/interpretarlo "a su manera". Por ejemplo, al presentar el wireframe al cliente, éste pensará que es "el diseño" (sea lo que sea que signifique para el cliente).

Por lo tanto, creo que la mejor manera de explicarlo es simplemente mostrar un proyecto pasado (o un proyecto falso) que pase por todos los pasos: desde las ideas/la lluvia de ideas, a las especificaciones, a los wireframes, a más especificaciones, a los wireframes actualizados, a photoshop, a la implementación del código. Cada uno de los pasos debe ilustrarse con los documentos pertinentes (capturas de pantalla).

También me gusta recalcar algo como "Ten en cuenta que la fase de maqueta es tan importante como la de codificación, si no más, ya que sienta las bases para todo el resto del proyecto."

Como menciona Scott, esto también debería formar parte del contrato con una declaración del tipo "los cambios solicitados en una fecha posterior que se desvíen de esta columna vertebral pueden suponer costes y tiempo adicionales para su realización (si se supera el número máximo de revisiones acordado)". Puedes recordarle amablemente al cliente esta declaración, explicándole que protege a ambas partes de desviaciones en el proyecto (para el cliente: horas extras inesperadas/injustificadas de ahí la factura. para ti: cambio de especificaciones en total contradicción con los vagos requisitos UX/UI).

Este es un ejemplo de la página de detalles del producto de Amazon

La maqueta

El diseño