Creo que lo que quieres hacer es asegurarte:
1) tenga claro quién es su usuario objetivo
2) Asegúrese de que las funcionalidades que tiene en la aplicación sean las que sus usuarios objetivo desean y que sean importantes para ellos
- ¿Por qué las estrategias solo móviles no funcionan para todos los países y categorías de productos?
- Como diseñador gráfico y UX / UI, ¿es mejor trabajar con un desarrollador o con el desarrollo de aplicaciones de outsourcing?
- ¿Has comenzado tu propia empresa de desarrollo de aplicaciones?
- ¿Cómo los desarrolladores de aplicaciones móviles pueden usar wearables?
- ¿Se puede hacer una aplicación móvil sobre un deporte determinado, incluso si ya existe una aplicación oficial?
3) ¡Asegúrate de que tu aplicación sea fácil de usar! de lo contrario, los usuarios dejarán la aplicación como una papa caliente
Para lograr esto, generalmente hago lo siguiente:
a) Obtenga un diseñador de UI / UX a bordo (incluso antes de hablar con cualquier desarrollador)
– Esto no debería ser solo un diseñador que hace bonitos diseños, sino uno que realmente entiende a su usuario objetivo y la psicología detrás de su pensamiento
– Este diseñador debe ser alguien que pueda tomar todos los requisitos, probarlos contra las suposiciones de los usuarios y crear un conjunto de maquetas.
– Si es posible, haga que el diseñador ensarte todas las maquetas en una interfaz en la que se pueda hacer clic, como http://InvisionApp.com o http://Proto.io. Esto requiere 0 codificación y la mayoría de los diseñadores deberían poder aprenderlo fácilmente, incluso si nunca lo han usado antes
– InvisionApp y Proto IO pueden hacer que su aplicación parezca MUY REAL y la mejor parte es que puede ejecutarla en sus dispositivos móviles, al igual que una aplicación nativa
b) Pruebe las maquetas con sus usuarios objetivo
– Puedes hacer que los diseñadores hagan esto, o puedes hacerlo tú mismo
– Tome las maquetas de InvisionApp y Proto IO y muéstreselas a sus usuarios objetivo. Observe en qué tocan, en qué pantallas se confundieron, en qué botones nunca se molestaron en hacer clic, etc.
c) Iterar iterar e iterar como locos
– Las cosas son mucho más fáciles (y por lo tanto más baratas) de cambiar en la fase de diseño que en la fase de desarrollo
– Cambiar las características, el flujo y las especificaciones (especialmente cualquier cosa que implique un cambio en la estructura de la base de datos) es muy costoso en la fase de desarrollo y puede conducir a un código de muy mala calidad, especialmente si los desarrolladores tienen que hacer los cambios apresuradamente para adaptarse a un entorno ya ajustado cronograma
d) Una vez que las pantallas y el flujo estén finalizados, muéstreselo a los desarrolladores (Aquí es donde los desarrolladores deberían entrar)
– Esto les da a los desarrolladores una idea clara de qué características se requieren, cómo deben fluir las cosas y cómo diseñar la base de datos correctamente
– Pueden solicitar aclaraciones si es necesario
e) Comunicar líneas de tiempo en términos de pantallas
– Pregunte qué pantallas se realizarán en qué fechas. Pregúnteles si podrá tocar esas pantallas y probar esos módulos a medida que se completan para reducir la falta de comunicación y marcar cualquier módulo mal construido temprano
f) Tener un sistema adecuado de registro de errores / seguimiento de problemas
– Existen muchos rastreadores de problemas gratuitos y sistemas de registro de errores disponibles. Úselos para registrar sus errores con frecuencia mientras prueba la aplicación
– Esto les da a los desarrolladores y a usted mismo visibilidad sobre qué errores se han descubierto, el estado de cada error, si se requieren aclaraciones / discusiones, y cuándo se han solucionado para pruebas y verificaciones adicionales
¡Sip! Eso es todo en pocas palabras. De hecho, escribí una versión TLDR de lo anterior en un artículo medio para laicos que buscan trabajar con desarrolladores y diseñadores. Está aquí si desea leer más: Gestión remota de proyectos bien hecha
¡Todo lo mejor! 🙂
