Prototyping cycles during product development
Currently during development projects, when we talk about prototype, specially when it cames about designers, we thought in terms of information archictechtury and the prototype as a rudimentar screen canvas of a website. But I suggest we go more further, think in the meaning that we usually apply the word protype, in a general way, in terms of design project, we associate prototype as a tangible object with the purpose of get you out of the idea plan and made it fiseable in same way, the more closest possible, but not necessarally, more faithful. The mean idea is that people can touch, Interact, see it and secondly, became a starting point to better comprehension of what you are designing.
In furniture product area, we develop as prototype what we call “mockup”, in fashion design: pilote piece, in digital products: “prototype”, and it can be produce in diferente levels of fidelity and complexity, but it evolve throught continuous cycles, each one, marked by a implementation. This process can happen in several phases or moments: when the product or service wasn´t lauched, while it´s development, or during it’s improvement. When we talk about digital, there is always a prototype, if it is not online or at the internet, it is a prototype.
And what about MVP? In what part of this process we can talk about it? I must confess, there isn´t such a thing as a consensus in what specifically can be considered a MVP, just, like the name says is the Minimum Viable Product, and I can explained as what in your own perspective, considered the basic starter point to your idea/project/product or service. In my projects, I prefer work as MVP being the most small, easy and fast way to validate an idea during a lean cycle. In Prisma, for example, my starter point was just a internet form, with general questions that guide me to next steps.
In another hand when we talk about construct a software as Project, and not a website, I think it is essencial we discuss another matter: the analysis requirements. And why do that? Because each Project is different in level of complexity, if you don´t think in several different aspects of each one, you will just designing empty flows, without consider actions and goals interface´s.
In order of it, now you ask me, Anne, what is a good requirements analysis? For where can I begun my prototype? When we talk in Design Thinking as aprouch, I sugest make the requeirements analysis as parto f the cocriation process, bringing the front-end to be part of the cocreation team, besides designers thinkers, PO´s and Market analysts.
How you have a multidisciplinary team that will delivery a technology without a person of this area?
Here is na example how we can do this: everyone write na requirement in a post-it, all the team do it together, and they put it in a canvas and groups the post-its in order of time, dificulty, and cost. From there you just have to organize the information in formo f cycles and priotitaze it. And don´t forget to think in how validate each cycle, I would say this is the most importante parto f the process.
Another thing is very import to say is: “to every level of fidelity of your prototype it´s necessary a specific kind of validation”.
© 2017- 2018 Anne Freitas All Rights Reserved
