Como construir produtos melhores gastando pouco em menos tempo O protótipo é uma das principais ferramentas para a construção e validação de uma hipótese de produto. Isso mesmo, ferramenta. Em nossa área de desenvolvimento de software existe uma certa confusão quanto às definições de “layout” e “protótipo”. Segundo…
Você sabia que User Experience (Experiência do Usuário/UX) pode ser mensurado e mostrar retorno sob investimento (ROI)? Mesmo que o cálculo do ROI seja desafiador por si só, é perfeitamente possível e muito valioso para justificar o investimento em UX.
Abaixo, trouxemos números interessantes para serem considerados na hora de construir seu case. As informações foram baseadas no infográfico Making a Strong Business Case for The Roi of UX, da Experience Dynamics, empresa americana de consultoria em UX.
Em fábricas de software, a velocidade é imprescindível. Atividades de UX podem reduzir em 50% o desperdício de tempo no desenvolvimento. Isso acontece porque elas ajudam a definir requisitos de usabilidade logo de início, prevenindo o retrabalho.
O tempo de desenvolvimento, por si só, já é reduzido em cerca de 33% a 55% quando o usuário é envolvido no processo. É assim pois a tomada de decisão e a priorização de atividades dos desenvolvedores ganha mais clareza.
Quando o termo User Experience (em português, Experiência do Usuário) foi cunhado por Don Norman, no início dos anos 90, podíamos contar nos dedos as empresas que realmente pensavam em entregar produtos alinhados às expectativas dos usuários. Por muitos e muitos anos, o que era levado em conta na hora de entregar um produto era simplesmente a capacidade de algo funcionar e ponto final. Não havia muito tempo (ou recurso) disponível para tentar entender quais eram os problemas reais dos usuários e o que eles realmente queriam. Se considerarmos que a maioria dos softwares produzidos na época eram voltados às empresas, fica ainda mais fácil de entender porque o usuário era jogado pra escanteio: o produto tinha que se adequar ao que o cliente quer, afinal, é era ele quem estava pagando.
Entretanto, no “mundo dos usuários”, a tecnologia era vista como vilã e a “arte” de entendê-la era restrita a poucos. Isso foi, um grande problema para os usuários, que se sentiam intimidados por esse novo cenário. Isso demandava um alto tempo de treinamento e utilização do produto, o que era custoso demais para todos os envolvidos no processo: os desenvolvedores.
