Uma abordagem de projeto ágil ou Agile Development permite definirmos iterações/sprints semanais e fazermos deploy para testarmos uma nova funcionalidade com mais rapidez e eficiência. Do ponto de vista da UX: Se nossos usuários aceitarem e usarem essa nova funcionalidade, manteremos-na.
Em cada início de iteração (XP) ou sprint (SCRUM), definimos o que será desenvolvido com a certeza que em 1 semana (ou 1 mês) determinada funcionalidade estará em produção para testes A/B, por exemplo. Ou simplesmente ser mantida para ver como os usuários reagem ou se interessam por ela.
Já uma abordagem em cascata (em inglês waterfall approach) é a mais tradicional e utilizada. Ela trata as etapas do projeto separadamente, como fases distintas e tudo isso num processo só de escopo fechado. O maior problema dessa abordagem é que uma etapa precisa que a anterior esteja 100% completa para que possa ser iniciada.
Isso muita vezes tem um impacto significativo nos usuários. Como o escopo é muito grande, a quantidade de complexidade que o usuário terá que aprender de uma só vez quando o software for atualizado, pode ser destrutivamente frustrante.
Se definirmos um escopo de projeto fechado para desenvolver um produto e lançarmos todas as funcionalidades planejadas de um só vez, as chances dos usuários tirarem o devido proveito disso tudo é bastante remoto. E o pior de tudo: custa muito dinheiro. Então, é melhor sermos cautelosos quanto a funcionalidades pré-definidas em escopos robustos. Talvez seja mais interessante lançar uma versão mais enxuta do seu produto e fazer seus usuários aprenderem a tirar proveito de cada nova feature aos poucos, progressivamente. Isso custa menos, melhora a experiência do usuário e otimiza a imagem da marca do seu produto no mercado como algo bem estruturado e testado (sem bugs).
Um produto enxuto desde o início atende um dos doze princícipios do Agile Manifesto, que é a simplicidade. Ela agiliza a criação de um produto com a funcionalidade mínima que seja fácil de usar. Não confunda simplicidade com a criação de um produto simples. Seu produto não precisa ser o mais robusto já no lançamento, pois com seu amadurecimento, talvez você decida mudar algumas estratégias, ou até mesmo, reformular por completo o modelo de negócio e a proposição de valor como um todo. Seja flexível e amadureça-o de forma progressiva e de um "respiro mental" para seus usuários aprenderem aos poucos.
"O senso comum parece sugerir que, para vencer a concorrência, é preciso ter um produto superior e com mais funcionalidade. Costumamos pensar que ter maior quantidade de recursos é ser melhor e mais desejável. Não é bem assim" - 37 Signals (2006).
Sempre que sua equipe ou você mesmo tiver uma idéia para um novo recurso, questione-se de forma mais crítica se a nova funcionalidade é realmente necessária para o sucesso do produto. Se você achar que não, descarte-a. Isso resulta em um produto simples e arrumado, que oferece apenas os recursos que o usuário precisa. A partir desse ponto, você pode pensar em novas funcionalidades e lança-las aos poucos, com isso você economiza e os usuários do seu produto/sofware não ficam confusos.
Design Responsivo Parte I: Arquivos CSS e Breakpoints
Design Responsivo Parte II: Listagens e Galerias
Comentários
Included file post/disqus_thread.html not found in _includes directory