A metodologia mais usada no Brasil para projetar a Experiência do Usuário (UX), segundo pesquisa realizada pelo Guilhermo Reis, é baseada numa metáfora de prédio, onde cada etapa do projeto representa um andar. O princípio básico é que não se deve construir o próximo andar antes de terminar o anterior.
Mas não é assim que prédios são feitos hoje em dia. A demanda por agilidade na construção civil fez os modelos cascata se tornarem obsoletos há muito tempo. Tais demandas são similares no desenvolvimento de aplicativos, mas as metodologias de UX atuais não estão preparadas para isso.
Palestra apresentada no Intercon 2011. Durante a palestra, convidei o Flavio Logullo, que trabalha na Webgoal para falar um pouco sobre a experiência de implementar Design de Serviços numa softwarehouse.
O que foi dito sobre a palestra:
Na sua apresentação, Frederick Van Amstel mostrou a importância de desenvolver aplicativos simples para tornar a experiência do usuário (UX) a melhor possível. Para isso é importante entender como os usuários se relacionam com o aplicativo e depois fazer a melhor adaptação para atender suas necessidades.
Ao traçar um paralelo com a construção de um prédio real, Fred mostrou que o Desenvolvimento Ágil de um aplicativo pode não seguir uma sequência tão lógica e direta, e sim transitar constantemente entre as diferentes camadas. Um modelo ágil de desenvolvimento deverá promover a modularidade das diferentes camadas, permitindo assim a flexibilidade do aplicativo para possíveis extensões ou customizações das suas funcionalidades.
Em março o pessoal do Faber Ludens apresentou o programa DRIFT, que deu start em nosso processo de inovação. Desde então os nossos processos e métodos de trabalho tem se transformado constantemente a medida em que aprendemos com eles. No case apresentado, o Fred falou um pouco sobre o DRIFT e eu, tive o prazer de explicar um pouco sobre o Service Blueprint do Granatum.
Siga-me no Twitter, Facebook, LinkedIn ou Instagram.
Programo há bastantes anos e, na minha opinião, qualquer projecto informático deverá sempre partir de uma boa análise através de pseudo-código ou de outra ferramenta similar. Os modulos deverão ser feitos um a um tal como se faziam os prédios antigamente. Detetar um erro em 500 ou 600 linhas de código acabar por ser fácil. Detetar um erro em dezenas de milhares de linhas de código é devastador.
Para finalizar a minha opinião, depois de um módulo feito, testado e aprovado, então devemos passar ao seguinte.
Assine nosso conteúdo e receba as novidades!
Atualizado com o Movable Type.
Alguns direitos reservados por Frederick van Amstel.
Apresentação do autor | Website internacional | Política de Privacidade | Contato