Jugando al Mago de Oz

Es posible que le resulte más fácil realizar esta forma de prueba en parejas. Uno de ustedes tendrá que actuar como computadora, por lo que necesita una segunda persona para registrar sus resultados. Pruebe con un solo usuario a la vez, no con un grupo. Esto es para evitar que las acciones y opiniones de un usuario influyan en los resultados de otros usuarios.

Pídeles de cinco a diez minutos de su tiempo, y si están de acuerdo, comienza por darles un poco de contexto de lo que estás a punto de mostrarles. Por ejemplo, si la aplicación en cuestión es NUSMods, puedes decirles que acaban de recibir un enlace de un amigo que les dice que prueben una nueva aplicación para organizar su horario de NUS. También puede darles un objetivo explícito para lograr, como "le gustaría registrarse para obtener una cuenta". Tendrán que lograr este objetivo interactuando con tus wireframes. Si está llevando a cabo esto virtualmente, la persona que actúa como la computadora puede compartir su pantalla.

Indíqueles que piensen en voz alta y usen su dedo para señalar dónde harán clic o tocarán, o si está haciendo esto virtualmente, puede intentar usar las herramientas disponibles en su aplicación de conferencias (Zoom tiene Spotlight y Arrow disponibles en su panel de anotaciones). Una forma rápida de explicar "Piensa en voz alta" a tus usuarios es " Vocaliza tus pensamientos. Háganos saber lo que está pensando durante todo el camino". Explícales que estarás actuando como la computadora y asegúrales que no hay una respuesta incorrecta. También dígale al usuario que le notifique si ha terminado de usar la aplicación / sitio web o si no tiene nada más que hacer. Esto le dejará claro cuándo el usuario ha perdido totalmente el interés, ha renunciado a su interfaz de usuario o ya no tiene uso para su sitio web / aplicación.

Ahora muestra la primera estructura alámbrica que se supone que deben ver. Observa con qué interactúan primero, segundo, tercero, etc. Recuerde hacer una "transición" entre sus esquemas como se ilustra en sus flujos de usuario a medida que el usuario interactúa con ellos. No digas nada durante todo el proceso. Si los usuarios se pierden o se confunden, que se pierdan o se confundan. Solo pídales lo que están pensando si parece que no están pensando en voz alta. Si se atascan, simplemente pasa al siguiente conjunto de wireframes.

Al mismo tiempo, esté atento a su lenguaje corporal. Fíjate si parecían vacilantes o desinteresados en algún momento. Tal vez, tuvieron que entrecerrar los ojos e inclinarse para leer cierto texto que era demasiado pequeño. Muchas veces, los usuarios no informarán de tales problemas, ya que asumirían que el problema radica en ellos y no en su diseño.

Para cualquier botón o pantalla que no haya diseñado, puede reutilizar cualquier estructura alámbrica existente y decirle a los usuarios lo que deben ver: "Hizo clic en el enlace Escuela de Computación. Hoy no tenemos esas pantallas. Así que por favor finja que ve los resultados de la Escuela de Computación en esta pantalla. ¿De acuerdo?". Alternativamente, puede describir el resultado de la acción al usuario con palabras: "Ve una ventana emergente abierta con un triángulo de advertencia amarillo, el texto 'Esto eliminará sus resultados. ¿Continuar?', y los botones 'Aceptar' y 'Cancelar'".

Permanezca lo más neutral posible durante las pruebas. Solo haga preguntas de seguimiento después de que la sesión de prueba del usuario haya terminado por completo. Esta sería tu oportunidad de preguntar:

• ¿Has notado el botón "X" en esta pantalla?
• ¿Por qué hiciste clic aquí y no allá? ¿Qué esperabas que sucediera cuando hiciste clic aquí?
• Parecías perdido en esta página. ¿Por qué te perdiste? ¿Qué esperabas que pasara?

Enjuague y repita con tres a cinco usuarios diferentes. ¿Te parece una muestra demasiado pequeña? Ver Por qué solo necesitas probar con 5 usuarios.

Una vez que haya completado las pruebas, ahora es el momento de revisar los resultados y mejorar su flujo de usuarios. Por ejemplo, puede preguntarse:

• ¿En qué hizo clic primero el usuario? ¿Era eso lo que querías que el usuario hiciera clic primero?
• ¿Qué características se perdieron por completo los usuarios? ¿Significa eso que esas características no son importantes? Si no son importantes, deséchalos. Si es así, ¿cómo puedes revisar tu diseño para que los usuarios noten las características y hagan clic en ellas?
• ¿Hay demasiados pasos para que el usuario logre su objetivo? ¿En qué momento el usuario se sintió visiblemente frustrado?
• ¿Qué suposiciones hiciste cuando creaste este diseño? ¿Las pruebas de usuario confirmaron o rechazaron estas suposiciones?

A medida que itera en su diseño, recuerde refinar sus bocetos y mejorar su calidad. Sé audaz en tus iteraciones anteriores. Es perfectamente normal tirar pantallas enteras en esta etapa temprana. Con cada iteración, debes solidificar tu diseño: mientras que las iteraciones anteriores pueden requerir un gran rediseño, las iteraciones posteriores solo deben producir ajustes menores. Por supuesto, asegúrese de que estos cambios estén bien fundamentados y documentados.

Fase 4 — Diseño de maquetas/prototipos + más iteraciones

Ahora que tienes planeada la arquitectura básica de la información y las interacciones con los usuarios, es hora de añadir más carne a tu wireframe. Convierte tu wireframe en una maqueta utilizando la herramienta de creación de prototipos que hayas elegido.

En comparación con un wireframe, una maqueta generalmente se parecerá más a cómo resultará la aplicación final. Los colores, las fuentes, los logotipos, las imágenes y los elementos de la interfaz de usuario de la plataforma de destino se utilizan en lugar de cajas de cable. Sin embargo, al igual que los wireframes, las maquetas permanecen estáticas y requerirán una transición manual cuando se realicen pruebas de usuario con ellas.

Fuente: https://www.nngroup.com/articles/wireflows

Puede resultarte útil desarrollar un conjunto de activos compartidos, como el logotipo de la aplicación, la combinación de colores, la fuente y los elementos comunes de la interfaz de usuario, para que tu maqueta parezca coherente cuando la construyan diferentes miembros del equipo. Soportes de Figma Componentes, que es una forma de crear elementos que puedes reutilizar en tus diseños. Puedes dar propiedades a los componentes de Figma y componerlas juntas, de forma similar a los componentes de la biblioteca de la interfaz de usuario en React/Vue/Angular. Untitled UI y Riddle UI son kits de interfaz de usuario / sistemas de diseño de Figma que contienen una buena cantidad de componentes de sistemas de diseño gratuitos que puedes usar en tu prototipo. Los componentes de Figma, utilizados con variables de Figma, permiten a los equipos crear diseños coherentes.

Si tu equipo se siente preparado para la tarea, también puedes optar por lanzarte directamente a la construcción de un prototipo, que es de mayor fidelidad que los wireframes y es interactivo. Las pruebas con un prototipo de alta fidelidad deberían ser la mejor alternativa a las pruebas con un prototipo funcional real. Esto permite una mayor Suspensión de la incredulidad, lo que permite al usuario actuar de forma más realista. La herramienta de creación de prototipos elegida debe permitir al usuario hacer clic directamente en los elementos, lo que debería hacer que el prototipo pase a la siguiente pantalla o estado. Esto también lo libera de actuar como la computadora, lo que le da más tiempo para observar al usuario.

Si planea trabajar en un prototipo, no es necesario enviar el diseño y los flujos de usuario por separado. Simplemente envíe el archivo interactivo en una sola carpeta, ya que las transiciones / interacciones del prototipo son básicamente sus flujos de usuario.

Fuente: https://medium.com/sketch-app-sources/what-is-a-design-prototype-the-complete-guide-f79cce54c50e

Una aplicación bien desarrollada tiene muchos componentes móviles: inicio de sesión, registro, estados activos, inactivos, etc. Si bien no tiene que incluir todas las posibilidades que encontrará su usuario, debe ser suficiente para que sus usuarios lo prueben satisfactoriamente.

¡Más pruebas! ¡Más iteraciones!

Al igual que en Milestone 6, ahora debes probar tu maqueta o prototipo de alta fidelidad con usuarios reales. En esta etapa, tu maqueta debería ser más completa, por lo que debería haber menos movimiento alrededor del papel o haciendo clic en las diapositivas. Todavía puede intervenir en la computadora para cualquier pantalla o estado que no haya agregado, o para interacciones como arrastrar y soltar, que son menos fáciles de prototipar, pero debería haber menos intervención de su parte.

Recomendamos encarecidamente probar al menos una vez con un prototipo interactivo. Las herramientas modernas de creación de prototipos permiten una configuración precisa de las transiciones, y sería bueno probar si las transiciones que planea usar entre pantallas son intuitivas para los usuarios.

Como ya deberías tener bastante confianza en tu estructura de información y en la interacción básica con el usuario, puedes centrarte en los detalles del diseño, la usabilidad y la experiencia del usuario. Por ejemplo, es posible que desee verificar si el color y el diseño elegidos de su primario Llamado a la acción es suficientemente diferenciado y perceptible. Además, dado que utiliza colores, fuentes y elementos de la interfaz de usuario de "producción", puede probar una gama más amplia de problemas, como la legibilidad, la interacción y la rentabilidad (las propiedades de un objeto que muestran las posibles acciones que los usuarios pueden realizar con él, sugiriendo así cómo pueden interactuar con ese objeto).

Sin embargo, recuerde que el objetivo principal de las pruebas sigue siendo observar al usuario interactuar con la aplicación. Si necesita hacer preguntas específicas sobre elementos del diseño que el usuario no comentó durante la prueba, solo debe hacerlo al final de la prueba.

Prototipo final

Con los resultados de las pruebas de usuario del borrador anterior, deberías llegar a una buena conclusión sobre cómo debería actuar y verse tu MVP. El prototipo interactivo final debe estar completo y ser lo suficientemente detallado como para ser entregado a un desarrollador para que lo realice. El prototipo debe incluir los flujos de incorporación, primer uso y (si corresponde) inicio de sesión. Consulte las instrucciones de la Fase 0 para conocer el formato de envío esperado para cada una de las herramientas de creación de prototipos.

¡Ahora es el momento de demostrar cómo debería funcionar tu aplicación! Reúnanse como un equipo (es decir, todos los miembros de su equipo deben estar presentes) y graben una demostración recorriendo los caminos felices de su aplicación, es decir, los principales escenarios de éxito para sus flujos de usuarios identificados. Mantén el video corto y conciso: da una breve introducción sobre el problema que tu equipo está tratando de resolver antes de demostrar los flujos de usuarios. El video debe durar menos de 5 minutos y enviarse como un archivo. .mp4

Queremos que sepas que los diferentes hitos de la Tarea 1 se han estructurado para que tengas una buena idea de lo que se necesita para producir un Documento de Requisitos del Producto (PRD), un documento utilizado en las empresas (Meta, Amazon, Google, muchas otras empresas tecnológicas...) para describir el producto que se está construyendo. El PRD generalmente es producido por el Gerente de Producto y debe ser aprobado antes de que se pueda llevar a cabo un desarrollo posterior del producto. Una vez producido, impulsa los esfuerzos de todo el equipo de productos y los esfuerzos de ventas, marketing y atención al cliente de la empresa.

La estructura general del PRD es la siguiente:

1. Propósito del producto (hitos 1-3)

• Descripción del problema que está tratando de resolver
• Descripción de alto nivel de lo que hace el producto y cómo resuelve el problema
• ¿A quién va dirigido el producto?

2. Análisis Competitivo (No incluido en la Tarea 1)

• Identificar a los competidores que están lanzando productos similares
• Identificar las características de los productos de la competencia que vale la pena emular o evitar
• Identificar las formas en que las características de nuestro producto pueden ofrecer un mayor valor que la competencia.

3. Características (Hitos 4-8)

• Describir cada característica a nivel de diseños de interacción y casos de uso
• Trazabilidad de los requisitos: identificación de los requisitos que respaldan cada objetivo
• Métricas que se van a medir (no se tratan en la Tarea 1)

4. Cronograma para el desarrollo de productos (no cubierto en la Tarea 1)

• Hitos clave y cronograma general para el desarrollo de productos

En particular, la mayor parte de la importancia del PRD está en la articulación del propósito del producto (Hitos 1-3) y las características construidas para servir a su propósito (Hitos 4-8). Esto es también en lo que nos estamos enfocando en esta tarea. Por lo tanto, además de tener en cuenta cómo y por qué la Tarea 1 está estructurada de esta manera, también debe ilustrar (lo mejor que pueda) cómo cada característica aborda un aspecto particular de un problema al que se enfrenta su usuario objetivo, lo que se conoce como trazabilidad de requisitos, para demostrar que su característica se desarrolló e iteró pensando en el problema que enfrenta el usuario objetivo y no simplemente porque sea genial o original.

Para obtener más información sobre los PRD durante su tiempo libre, no dude en consultar esto enlace.

Fase 5 — Growth Hacking

El growth hacking se define como el proceso de experimentación rápida a través de un embudo de marketing, desarrollo de productos, segmentos de ventas y otras áreas del negocio para identificar las formas más eficientes de hacer crecer un negocio. Un concepto erróneo común sobre el término es que tiene que ver con la codificación.

¡Una aplicación maravillosa es inútil si no hay usuarios que la usen! En esta sección discutiremos algunas formas de obtener usuarios.

Página de aterrizaje

¿Cuándo deberías lanzar un sitio web para tu aplicación? Si su respuesta es iniciar solo después de que se haya lanzado la aplicación, ¡se lo está perdiendo! Al igual que los avances de películas, que se lanzan meses antes del lanzamiento real de la película, puede lanzar una página de destino, que es un sitio web diseñado para medir el interés y convertir a los visitantes en clientes potenciales / usuarios.

Una página de aterrizaje de una aplicación que no se ha lanzado debe:

• Explique de qué se trata su aplicación y tiene como objetivo generar interés en ella.
• Contener un formulario que le permita registrar la información de un visitante (por ejemplo, correo electrónico). Las empresas a menudo prometen algún tipo de oferta o promoción para los primeros X usuarios que se registren. Otra táctica de marketing inteligente es permitir que los usuarios reclamen/reserven su nombre de usuario en su producto, lo que crea una sensación de escasez (p. ej. Cal.com).

Aquí hay algunos recursos y ejemplos para crear páginas de destino atractivas:

• Amor de una página
• Ejemplos de páginas de aterrizaje de SaaS
• 6 Ejemplos De Landing Pages Próximamente Para Construir Una Lista De Espera Para Tu Próximo Lanzamiento
• Ejemplos de diseño de páginas de destino para inspirar la tuya en 2023
• 20 excelentes ejemplos de páginas de destino que querrás copiar en 2023

Utilice una biblioteca/marco de CSS como Tailwind UI o Bootstrap para ahorrarte algo de tiempo. ¡Recuerda que el diseño tiene que ser atractivo y que tu mensaje tiene que ser conciso! Incluso puedes considerar soluciones sin código o con poco código como Framer o Páginas de destino de MailChimp para saltarse todo el trabajo.

Estrategia de marketing

Una página de aterrizaje no puede convertir eficazmente a los visitantes en clientes potenciales/usuarios si no hay visitantes para empezar. Volviendo al ejemplo de los trailers de películas, sería como crear un tráiler de película pero no mostrarlo a través de pantallas públicas y anuncios de televisión. Por lo tanto, debe pensar en algunas posibles estrategias de marketing para correr la voz sobre su aplicación.

Ejemplos positivos:

• Haz videos promocionales.
• Griddit, una aplicación de sala de chat en vivo, consiguió que el profesor Ben Leong hiciera un AMA utilizando su servicio.
• Letterbox tenía a un miembro recorriendo la escuela en una rueda de aire y repartiendo folletos.

NO:

• Pega pegatinas irremovibles en los bancos de la Escuela de Computación.
• Coloque carteles en lugares inapropiados como los baños.

Los videos no son la única forma de comercializar una aplicación: para obtener calificaciones en el codiciado 30%, piense fuera de la caja para estrategias de marketing no disruptivas, creativas y efectivas. Queremos un plan de marketing bien pensado que incluya detalles sobre cómo lo implementaría. Tu estrategia debe ser obviamente realista, es decir, no sugieras dar 10 dólares a cada usuario que descargue tu aplicación si no tienes un buen plan de conseguir esos fondos o un millonario en tu equipo.

Redacción de la tarea final

Su presentación incluirá un escrito que describa cómo su grupo ha cumplido con todos los hitos para esta tarea:

• Debe contener las respuestas a los hitos 1-4 y 10-11.
• También debe resumir sus hitos 5-9. Más concretamente, debería:
  • Deja claro cómo se organizan los diseños. ¿Cuáles son wireframes, maquetas o prototipos?
  • Resuma brevemente los resultados y las observaciones de los resultados de las pruebas de usuario.
  • Resalte los principales flujos de usuario presentados en cada borrador / iteración presentado.

Esquema de evaluación

La calificación del trabajo se divide en dos componentes: el cumplimiento de los hitos obligatorios (70%) y el factor de frialdad (30%). Excluyendo el Hito 0, hay 11 hitos obligatorios en total, junto con un Hito 8b opcional. Los hitos 5a y 5b valen un 2,5% cada uno. Los hitos 6, 7 y 9 valen un 10% cada uno. El resto vale un 5% cada uno.

El 30% restante se otorgará en función de los resultados relativos de los distintos equipos. El mejor equipo puede recibir hasta un 30%, mientras que el equipo con peor rendimiento menos del 5%. Los hitos opcionales también pueden contribuir a ello.

En general, la tarea de diseño del producto vale el 10% de su calificación final.

Modo de presentación

Antes del lunes 2 de septiembre de 2024 a las 23:59 horas, debes subir a Coursemology lo siguiente:

• Su artículo final llamado group-<number>-milestones.pdf
• Sus diseños y resultados de pruebas, comprimidos juntos, llamados group-<number>-designs.zip

En el caso de las entregas con un tamaño de >1 GB (que es el tamaño máximo de carga que Coursemology tiene actualmente), cargue el archivo zip en Google Drive y envíe un archivo PDF que contenga el enlace a sus diseños y resultados de pruebas. Asegúrese de que la última fecha y hora de modificación de su archivo ZIP cargado en Google Drive sea anterior a la fecha límite de envío.

Las aclaraciones y preguntas relacionadas con esta tarea deben publicarse en el foro de Coursemology.

¡Buena suerte y diviértete!