Lo primero que se tiene que decir sobre el desarrollo de un producto digital es que lo más importante no es la parte tecnológica, sino las consideraciones que se tengan al momento de diseñar el producto en principio.
Para este tema pienso que es indispensable tomar referencias para evitar gastar tiempo dilucidando lo que ya está dicho, sugeriría basarse en dos pilares; el primero es el clásico del diseño centrado en el usuario “Desing of everyday things” de Don Norman. Intentaré extraer brevemente lo más relevante para el tema:
- El diseño es esa cosa que existe para comunicar un objeto con su usuario con el fin de hacer la experiencia de uso placentera (que ayude a alguien a algo).
- Un buen diseño debe de dar a notar qué acciones son posibles con el producto y cómo ejecutarlas.
- El error humano debe de ser visto como la excepción a la regla. Y la regla es, si el usuario se equivoca al interactuar no es su culpa, sino culpa de un mal diseño.
El Diseño Centrado en el Usuario
Aunque el libro propone mucho más que esto, y también lo señala, decidí ponerlo aparte porque no son aportaciones propias de dicho autor. El Diseño Centrado en el Usuario o Human Center Design es una visión de cómo se debe concebir un producto o servicio, a pesar de que distintos autores presentan variantes, se ve más o menos así:
Este proceso que propuso el British Council of Design menciona que primero hay que investigar, sintetizar lo investigado, pasar por el proceso de ideación y luego establecer los requerimientos para la implementación. En mi experiencia las primeras tres fases del proceso se dan por sentado cuando se está preparando un producto digital.
Otro autor relevante en el tema es Stephen Wendel, su libro se llama “Designing for Behavioral Change” y está enfocado en el desarrollo de productos digitales, para este autor, los principios para un buen producto digital están en la intersección de las ciencias del comportamiento, el análisis de datos y el product developmet. Su modelo es muy similar en cuanto al modelo anterior, solo que él le agrega el componente de la economía del comportamiento a algunos entregables durante el proceso de investigación y de diseño, lo pueden ver a continuación:
Si por acá estás ya un poco perdido, entonces te recomiendo que revises este Framework de Rebecca Smith de D-Labs sobre investigación de usuario.
Documenta los requerimientos
Ahora bien, una vez que sabemos que idealmente le tenemos que dedicar un buen tiempo a entender al usuario, y entonces establecer los requerimientos de un sistema podemos confesar que esto muy rara vez sucede. De hecho, las empresas/emprendedores tenemos como peor enemigo al tiempo y nos cuesta mucho entender que los recursos que se gastan en este tema, tendrán un retorno a la inversión claro (aunque francamente incierto) en el largo plazo.
Dicho lo anterior, entonces ya podemos pensar en cómo se debería de ver un proceso de desarrollo de software, lo primero es tener documentados los requerimientos, a pesar de que uno de los valores de Agile es “Working software over comprehensive documentation” yo estoy seguro de que tener un documento que nos de una base común de entendimiento a la parte técnica y a la parte de negocios es algo que vamos a agradecer en un futuro.
Requerimiento y especificación
Acá lo siguiente que debemos diferenciar es un Requerimiento y una Especificación de Sistema, el primero está en términos del usuario común; por ejemplo: Una persona debe de poder colocar un bote en la parte superior de un auto, el segundo está en términos del sistema:
- El bote debe pesar menos de 50 kg
- Debe tener de dónde sujetarse
- El rack del auto debe de estar acolchonado
También existen los requerimientos no funcionales, que describen las limitaciones de un sistema en temas de seguridad, usabilidad y desempeño o que pueden estar predefinidos por la empresa o por el entorno.
Entonces, un requerimiento es algo que el usuario quiere hacer (cosa que no tendremos ni idea a menos que lo investiguemos formalmente) y la especificación es cómo el sistema atiende esa necesidad.
Ahora la pregunta es:
¿Cómo se escribe un documento así?
El Institute of Electrical and Electronics Engineers estableció un documento llamado, Software Requirements Specification (SRS) que nos da muy buena idea de qué debe de saberse del producto digital antes de desarrollarlo.
En MiCochinito (empresa donde colaboro) nos habría encantado que alguien nos informara de esto hace algunos años, en el inter nos tuvimos que inventar nuestro propio mecanismo de documentación tras malas experiencias con equipos de programación que no lograban capturar bien la idea de un cliente, o con clientes que no sabían con mucha precisión qué querían obtener como producto final. Le llamamos Hoja de Requerimientos.
Posterior a trabajar este documento base con el equipo de programación, entonces es momento de que el diseñador experto en UX tome su turno y entregue un manual de identidad digital del producto y si es muy pro, que comience a preparar el sistema de diseño que se utilizará para desarrollar el prototipo y el subsecuente producto final.
Tener una maquetación que refleje la estructura de la interfaz y que aterrice el diseño es indispensable antes de iniciar la programación del sistema. Es más, es recomendable que con el prototipo se realicen algunas pruebas de usabilidad.
Ahora sí, el momento que todos esperaban…
