As startups são notórias por trazer rapidamente uma ideia de um conceito para um produto finalizado .

Embora certamente haja algo a ser dito para dedicar nosso tempo e fazer pesquisas profundas a cada etapa, às vezes precisamos apenas ter uma ideia em funcionamento o mais rápido possível.

A criação rápida de protótipos em uma cultura de startups simplifica o processo típico de design e desenvolvimento para atingir os pontos altos e retocar os baixos após o fato. Podemos aprender muito com essa metodologia e aplicá-la diretamente ao nosso próprio trabalho, mesmo que esse trabalho não seja para uma startup.

Estranhamente, essa metodologia geralmente requer menos trabalho e muito mais pensamento e planejamento.

Esboçar tudo, seriamente ... tudo.

A prototipagem rápida refere-se tradicionalmente aos ensaios e testes de produtos antes de serem enviados para a produção em massa para o consumidor em geral. Vamos procurar algo semelhante aqui com esta abordagem, mas com a ideia de manter o tempo de design e desenvolvimento ao mínimo.

Para que isso funcione, precisamos ter uma ideia clara do que estamos construindo e por que ele está sendo construído. O recurso rastejante pode facilmente matar suas idéias apenas pela complexidade, por isso vamos querer manter as coisas mínimas e barebones para o nosso produto principal.

Retire sua ideia até que seja puramente um nome de produto e um único recurso central. (Qual é o problema que você está tentando resolver?) Então construa em torno disso. Você pode adicionar mais recursos essenciais, se for absolutamente necessário, mas saiba que recursos adicionais adicionarão ainda mais complexidade à sua estrutura de tópicos.

É sempre melhor fazer uma coisa de forma elegante e bem, em vez de fazer cinco coisas mal.

Ramificando e aumentando seu produto

Agora que você tem um núcleo para focar, você pode começar a adicionar os recursos mais específicos. Ramificar significa que esses recursos não são essenciais para o foco principal do produto, mas agregam valor à sua existência. Esses “ramos” são complementos, quesitos adicionais que adicionam interesse e acabam se tornando pontos de venda que o separam da concorrência.

Mas enquanto eles certamente adicionam interesse ou valor, eles também acrescentam tempo de pesquisa e desenvolvimento, então tenha isso em mente. Você vai querer jogar o suficiente para abastecer o design e o desenvolvimento futuros, mas não tantos a ponto de fazer seu contorno parecer uma teia de aranha.

Falando de teias de aranha, elas são uma maneira fantástica de descrever visualmente esses dados. No centro, você tem seu objetivo principal. Adicionar um anel adicional de recursos fora do núcleo são seus recursos não essenciais mais importantes. Cada anel depois disso cresce menos e menos importante. Usar essa ideia para delinear visualmente seu produto pode ajudar a organizá-lo de uma maneira mais natural - com o foco fluindo da maioria para os elementos menos importantes.

Desenvolva um MVP e corra com ele

Seu produto mínimo viável (MVP) é a essência do seu produto. Só ele e é o núcleo e o foco principal a partir do qual tudo se ramifica.

Lembre-se desse esquema que você provavelmente passou dias ou semanas? Ignore tudo o mais agora, exceto as coisas necessárias para tornar seu produto funcional. Isso é realmente um produto mínimo viável. O que você vai acabar não é apenas uma lista de tarefas para obter o produto funcional mais básico possível, mas também um esboço claro de recursos para focar depois, bem como uma ideia geral do que esperar ainda mais abaixo. estrada. A ideia aqui é ter um roteiro para design e desenvolvimento para o próximo ano ou mais. Quando você chegar ao fim deste esboço, seu produto terá amadurecido o suficiente para ter uma direção clara com a qual construir mais, ou você terá visto o que funcionou e não funcionou a partir do seu esboço e ajustado de acordo.

Planeje e delineie agora, projete e desenvolva durante a execução - essa é a chave.

Agora é também a hora de fazer uma pesquisa leve sobre quais tecnologias e práticas você usaria para concretizar essa sua ideia - incluindo alguns dos recursos mais distantes. Isso só poderia envolvê-lo ou exigir que uma equipe inteira discutisse as opções e decidisse o que seria melhor. É importante fazer sua pesquisa depois de planejar um MVP para que todos, desde o design até o desenvolvimento, tenham uma ideia clara do que esperar. Não apenas concentrando-se no núcleo, mas também olhando para os ramos mais distantes e garantindo também o planejamento dos mesmos. Afinal de contas, não há nada pior do que ter seis meses de desenvolvimento apenas para perceber que ninguém planejou um recurso altamente antecipado, mas não essencial…

Alta fidelidade pode passar fome, baixa fidelidade pode enganar você

Todo mundo adora os lindos mockups de alta fidelidade postados no Dribbble ou nos portfólios dos designers. Seria incrível trabalhar com essa clareza para todos os produtos também. Mas geralmente esses modelos levam semanas, se não meses, de trabalho e iteração para atingir esse nível de fidelidade. Mesmo assim, às vezes esses modelos são mais focados em estética do que qualquer análise orientada por dados ou dados de usuários.

Embora a super alta fidelidade esteja obviamente fora de questão, os esboços de baixa fidelidade ainda são uma opção certa? Bem, provavelmente não. Mostre alguns esboços em guardanapos a um desenvolvedor e eles não terão ideia de como seu produto parecerá ou, mais importante, como será a sensação de uso.

A fidelidade média é geralmente a resposta certa para um ambiente de design e desenvolvimento rápido. Combine isso com o contorno textual gerado acima e ambos os lados devem ter um bom entendimento da UX por trás dos recursos.

A fidelidade média ainda gera simulações, mas elementos mais granulares são inicializados usando padrões de pesquisa ou de uso existentes, não baseados em pesquisas personalizadas de análises de usuários anteriores ou testes A / B.

Design e desenvolvimento não tem atalhos

A nota mais importante a fazer aqui é que não há atalhos. Ninguém pode economizar tempo de projeto ou desenvolvimento e passar despercebido.

Embora possamos nos ater aos casos de uso comum e implementar bibliotecas de código populares para resolver os problemas de hoje, a maioria dos produtos, se não todos, pode se beneficiar de alguém em uma atenção em design e desenvolvimento.

Metodologias de projeto e desenvolvimento rápidas estão adotando a abordagem tradicionalmente mais personalizada nessas áreas e reduzindo as coisas para serem revisitadas posteriormente. Espera-se que os produtos sejam revistos para dar a devida atenção ao design e para otimizar ou até mesmo executar com uma solução desenvolvida mais personalizada. Portanto, embora possamos economizar tempo e recursos hoje, adotando uma abordagem mais rápida ou ágil ao nosso fluxo de trabalho, ele deve ser sempre com a expectativa de que revisitemos as coisas após o fato para garantir que nosso trabalho seja sólido.

Quando o núcleo estiver completo, revisite e personalize. Quando a próxima rodada de recursos não essenciais estiver completa, revisite e personalize. Geralmente, isso requer apenas um trabalho de front-end e não um completo redesenvolvimento do código de back-end. Por isso, é tipicamente limitado ao posicionamento, cor, tamanho ou outros atributos estéticos dos elementos. Em termos de desenvolvimento, revisitar aqui significa simplesmente otimizar o código para execução de desempenho.

Tick, tock vai o ciclo

Ter um ciclo de estilo “tick-tock” para revisitar nossas soluções de design e desenvolvimento rápidas é a melhor maneira de abordar a revisitação em minha experiência. Enquanto o desenvolvimento está trabalhando em consubstanciar o próximo lote de recursos, o design pode revisar o último lote para garantir que tudo seja mantido ou vice-versa. A qualquer momento, o design ou o desenvolvimento é um ciclo à frente do outro e o outro está sendo revisado. Durante esse processo, as duas equipes trabalham juntas não apenas para revisar, mas também para distribuir o próximo lote também.

Metodologias de design rápido são difíceis

O desenvolvimento geralmente pode se dar bem com o uso de bibliotecas existentes ou soluções de código aberto para concretizar as ideias de produtos. Mas quando se trata de design, é muito mais difícil cortar coisas ou terceirizá-las para soluções existentes.

O design por natureza é mais individual do que o desenvolvimento e, se você estiver em um nicho de mercado, será difícil, se não impossível, encontrar casos de uso semelhantes para basear o trabalho. Design é uma daquelas áreas onde quanto mais você cortar, mais qualidade você vai perder no final. A experiência do usuário e a estética desempenham um papel muito importante na forma como um produto “funciona”.

Embrulhando as coisas

No final, devemos nos encontrar com produtos sólidos que se destacam contra os concorrentes que se engajaram nos processos mais tradicionais de projeto e desenvolvimento “lentos”.

O objetivo não é pular partes de P & D completamente, mas arquivá-las para cuidar mais tarde, assim que tivermos mais dados sobre nossos usuários e como eles usam nosso produto.

Prototipagem rápida pode levá-lo a um MVP e além em uma fração do tempo que levaria tradicionalmente, mas tome cuidado para não confundi-lo com cantos de corte.