Que ocorre cando un prototipo é demasiado bo?
Na xuntanza co cliente, Sabela usou un prototipo feito en Figma para facer unha demostración da interacción co usuario. O cliente suxeriu uns poucos cambios pero estaba encantado, e no final da xuntanza preguntou canto tardaría en estar rematado o programa. Cando Sabela respondeu que tardaría varios meses, puxo cara de confusión.
—Pero logo, eu pensaba que estaba ben adiantado. Non me acabas de facer unha demostración?
Os prototipos e as demostracións son unha ferramenta moi útil para comunicármonos cos clientes e comprobar que o noso deseño cumpre as súas expectativas, pero ás veces inducen a pensar que o proxecto está moito máis avanzado que na realidade.
Desconfiade dos prototipos!
Para o cliente, a parte visible dun programa é a interface de usuario, así que non é de estrañar que haxa esa confusión, especialmente cando o prototipo está moi elaborado, con interaccións completas e funcionalidade implementada total ou parcialmente.
Para evitar enganar aos vosos clientes debedes limitar o voso prototipo o máximo posible. Desta maneira non malgastades tempo engadindo cousas superfluas e facedes que se note ben que é un prototipo e non o produto final. Por exemplo, se queredes demostrar a estrutura dunha páxina, non vos molestedes en poñer os tipos de letra, cores e imaxes; se queredes demostrar os estilos, poñédeos nunha páxina de mostra, non nunha demostración da interface; para demostrar a interface de usuario, implementade só unhas poucas interaccións predeterminadas.
Moitas veces, o mellor prototipo é un debuxo nunha folla de papel. Se o cliente quere un cambio, borrade e debuxade outra vez ou facede outro debuxo nunha folla nova para poder comparar despois: moito máis rápido que andar fedellando no Figma e ninguén vai pensar que ese é o produto final.
Era un deses proxectos complicados, así que Lois decidiu facer un prototipo para comprobar que era factible. Tres semanas despois, amosouno ao resto do equipo.
—Excelente, vou marcar esa parte como rematada no Jira e imos facer o resto do proxecto — dixo o seu xefe.
—Non! Este é só un prototipo feito ás bravas! Hai que tiralo ao lixo e facelo ben.
—Non digas parvadas. Levouche tres semanas facer isto, non imos perder todo ese tempo.
Non é só un erro que cometan os nosos clientes. Nós mesmos temos a tentación, moitas veces, de usar os nosos prototipos no produto final, aínda sabendo que os fixemos ás présas, sen tests nin revisións de código nin nada. “Só hai que engadir os tests e xa está listo”, pensamos con optimismo.
O código dun prototipo está feito para usar e tirar, non para perdurar. Normalmente ten tantos atallos e spaghetti e sitios no que o programador cambiou de idea pero non modificou o resto do código para acompasalo que, cando chega a hora de facer o código de produción, é máis rápido escribilo de novo da maneira correcta que tratar de adaptalo.
O tempo empregado nun prototipo que vai para o lixo non é tempo desperdiciado: é tempo que se usou para pescudar se a tarefa é factible e cal é a mellor maneira de acadala. É moito mellor facer un prototipo pequeno no que se pode fedellar rápido e despois facelo sobre seguro no código do proxecto, que tentar facelo á primeira no código principal, no que é máis difícil e lento facer cambios.
Se os vosos xefes (ou vós mesmos) teñen tendencia a querer reutilizar os prototipos, a solución é semellante á anterior: facede que os prototipos sexan o menos útiles posible para incorporalos no voso proxecto. Escribídeos nunha linguaxe de programación distinta (ou nun idioma diferente), infrinxide todas as regras da guía de estilo e facédeos o máis limitados posible.
A ilustración desta Folla procede de “Les merveilles de la science”.
1 comentario