Design centrado no Usuário — Planejamento

Dando continuidade ao resumo sobre o livro “Design Centrado no Usuário”, hoje trago o resumo do capítulo 4, que aborda o planejamento de projetos. Tentei incorporar minha visão e enfatizar a importância de cada etapa, além de oferecer sugestões de como realizá-las

Devemos investir tempo para pensar no que estamos tentando realizar com nossos projetos. Ter e documentar um plano estratégico garantirá que desenvolveremos de maneira padronizada. Investir tempo em atividades que não estejam diretamente relacionadas à implementação de código contribui para o foco e alinhamento dos requisitos. Desta forma, ao finalizarmos nosso desenvolvimento, teremos efetividades e evitaremos retrabalho, pois saberemos o que deve ser feito, sem depender de suposições.

Definição de missão de equipe

A missão tem o poder de relembrar qual o propósito da equipe. Embora toda organização tenha sua missão, é importante que cada equipe defina a sua, especificando o que está tentando alcançar.

Como fazer: Ler e compreender a missão da organização e customizá-la para criar a da equipe.

Por quê: Assim evitaremos sair do foco, possibilitando sempre uma reflexão sobre se estamos caminhando em direção à nossa missão ou nos desviando para atender a solicitações que fogem do nosso escopo.

Definindo o projeto

Para nos direcionarmos corretamente em relação à nossa missão, devemos ser capaz de resumir o que estamos tentando alcançar com o nosso produto.

Como fazer: Façam questionamentos a si mesmos, considere alguns exemplos citados no livro:

• Qual é o propósito?
• Por que você esta desenvolvendo isso?
• A quem essa funcionalidade servirá?
• Como agrega valor ao produto? E por fim, a organização?

Por quê: Ao nos questionarmos somos capazes de compreender até onde se estende o nosso domínio em um determinado assunto. Ao realizarmos esse processo em equipe, nosso conhecimento sobre o produto será complementado pela compreensão individual de cada mebro. Devemos pensar em nossos produtos como um sistema completo, entendendo como cada função se integra em algo maior e funcional.

Coletando requisitos de usuário

Esse processo consiste em coletar todas as solicitações dos usuários e concentrá-las em uma documentação de requisitos. É importante ter em mente que esse procedimento não se refere aos requisitos técnicos e sim às necessidades do usuário. Para nós, desenvolvedores, pode ser desafiador separar as duas fases.

Como fazer: Coletar os requisitos junto ao usuário e sintetizá-lo em uma documentação, apresentando o documento para validação pelo usuário

Por quê: Essa etapa é crucial para assegurar que estamos utilizando a mesma linguagem que o usuário. “Ao mostrar os requisitos a seu usuários, você poderá garantir que entendeu corretamente suas necessidades”. Não é incomum que os usuários nos solicitem algo, e, devido ao nosso gosto por desafios, possamos imaginar algo super complexo, com “incrementos” desnecessários que, por vezes, nos afastam das reais necessidades deles.

Criando requisitos funcionais

Aqui discutimos o que o sistema necessita; são as funções individuais que planejamos entregar por meio do sistema.

Como fazer: Associar os requisitos do usuário aos requisitos funcionais. Um requisito de usuário resultará em um ou mais requisitos funcionais.

Por quê: Isso garante que os requisitos de usuários coletados serão implementados, além de servir como evidência de que, se o usuário decidir alterar um requisito, isso adicionará tempo a todo o processo, pois será necessário revisar também os requisitos funcionais. Essa prática ajuda o usuário a compreender a complexidade do que está sendo solicitado.

Documentando modelos de dados e fluxo de trabalho

O uso de diagrama permite visualizar quais dados estarão disponíveis e como poderão ser acessados.

Como fazer: Utilizar diagramas de bancos de dados e/ou diagrama de fluxo de dados

Por quê: “Prefiro um diagrama limitado a não ter nada.” Esta etapa pode parecer ser lenta e facilmente dispensável, pois muitas vezes confiamos apenas em nossa memória e subestimamos a complexidade dos dados e suas interações. Ao documentarmos, podemos garantir que consideramos todos os fluxos e condições, evitando lacunas.

Documentando protótipos

Nesta etapa, tornamos os requisitos, tanto de usuários quanto os funcionais, mais concretos. “A revelação dramática não deveria ser nosso motivador”; frequentemente, ficamos imersos no nosso mundo, criando algo, e esquecemos do mais importante: incluir os usuários nesse processo, garantindo assim que estamos alinhados com suas expectativas.

Como fazer: Atualmente, existem diversos frameworks que nos permitem criar protótipos de alta fidelidade. No entanto, o livro me fez refletir muito sobre a importância de não pular etapas e começar primeiro com protótipos de baixa fidelidade, seja usando lápis e papel ou, em ambientes remotos, criando protótipos com figuras geométricas simples

Por quê: Esta fase, além de mostramos de forma tangível todos os requisitos, serve para realinhar as expectativas criadas pelo usuário e também evitar retrabalho. Ao mostrarmos o protótipo de baixa ou média fidelidade para o usuário, damos a eles a oportunidade de fornecerem feedback antes mesmo de iniciarmos o desenvolvimento. Se começarmos diretamente com um protótipo de alta fidelidade, podemos criar a ilusão de que estamos mais próximos da entrega final. O usuário pode não compreender a complexidade e o tempo necessário para o resto do desenvolvimento, causando falsas expectativas. Além disso, prejudica a qualidade dos feedbacks, já que o usuário pode acreditar que a funcionalidade já foi desenvolvida.

Revisando sua documentação

Não faz sentido escrever algo para ser esquecido, certo? Dessa forma, todo o esforço de documentar pode ser em vão. A importância da documentação vai além do processo de desenvolvimento, pois fornece um histórico e algo ao qual podemos recorrer sempre que necessário. “Descobrir e acumular conhecimentos sobre como seu projeto mudou ao longo do tempo consistem em uma ferramenta poderosa.”