Como sei se meu design está concluído?

A parte mais difícil do design é saber quando parar

Tiffany Eaton Seg. 23 de jul · 5 min ler

Se você não trabalhou em muitos projetos, pode ser fácil tratar seu trabalho como um bebê recém-nascido. Você quer protegê-lo e fazê-lo parecer incrível. O problema com o gerenciamento excessivo do seu trabalho é que ele pode ser mais do que o refinamento ou o medo de fazer alterações quando necessário. Ele obscurece seu julgamento de que o design faz parte do processo de solução de problemas e mudará de acordo com a situação. A diferença é que algumas mudanças são necessárias para resolver o problema ou ser desejado, porque isso fará com que pareça mais polido, mas não necessariamente crítico no tratamento do problema.

Um design é concluído quando você define restrições ou escopo acionáveis. Uma vez que você valide seu design é necessário e funciona bem, então pode fazer sentido voltar a ele e iterar, mas de outra forma restrições e escopo do seu design melhor resolvem um problema e os usuários são bons o suficiente. Isso geralmente é a parte mais difícil.

Aqui estão algumas maneiras específicas para ajudar a ditar quando seu design estiver concluído:

Se ele aborda o problema central e as necessidades do usuário

Para mais contexto, leia O que faz um bom projeto de design?

Como você pode saber se está ou não resolvendo o problema certo em seu processo de design? Você pode basear-se no teste do usuário ou avaliar cada parte do seu resultado e perguntar se ele atende a uma necessidade principal do usuário. Se tudo se conecta, das explorações iniciais ao resultado, você está acabado. Se o resultado ou o visual realmente não comunicarem o problema ou o usuário, você deve voltar e refinar. Como você poderia fazer isso? através do mapeamento de histórias .

Um exemplo de um mapa de história

O mapeamento de histórias permite mapear visualmente como sua solução funcionaria na jornada do usuário e ajudar você a tomar decisões visuais que se conectam à sua pesquisa e aos seus objetivos. Ele pode ajudá-lo a priorizar o que você precisa trabalhar ou se você está deixando algo de fora que é crucial na jornada do usuário.

Aqui está um exemplo de como estruturar um mapa:

Título, objetivo, usuário (papel)

2. Primeira linha é o que o usuário precisa para atingir seu objetivo (atividades do usuário)

3. Segunda linha são as tarefas que precisam fazer para atingir seu objetivo (tarefas do usuário)

4. Terceira linha e por linhas são as histórias específicas, as ações que eles podem fazer usando sua solução para alcançar as tarefas. Você os combinaria nas tarefas. Empilhe-os com base no que você está medindo (ou seja, prioridade, isso resolve melhor o problema neste momento, etc.). Você também pode adicionar as histórias com padrões de design específicos que você pode usar para as ações.

Se você tem pouco ou nenhum tempo, por causa de um prazo

Dependendo de quão longe você está no seu projeto, priorizar o que é essencial em seu resultado deve ajudá-lo a entrar na mentalidade de saber quando seu projeto é feito.

Não coloque muita ênfase em um projeto, uma vez que ele atende a um prazo e resolve a necessidade essencial do usuário. Isso se aplica especialmente no trabalho, onde seu trabalho está constantemente mudando, sendo dilacerado, e você continuará a trabalhar mais.

Quando o design estiver concluído, você sempre poderá voltar a um design, se há uma necessidade urgente de refiná-lo, adicioná-lo para uma documentação precisa ou para propósitos de portfólio e entrevista.

Se satisfizer os requisitos mínimos do produto *

Em uma organização, baseamos o progresso de nosso trabalho em OKRs (objetivos e resultados-chave). P0 ou P1 são essenciais e fazem parte da experiência mínima do produto viável. Estes geralmente ditam um lançamento, que às vezes se correlaciona com a conclusão do produto em um determinado período de tempo até que o trabalho de acompanhamento seja necessário.

P2, P3 e outras coisas são boas de se ter, mas não são necessárias. As coisas P0 e P1 são cruciais para a função do produto e a experiência do usuário. Uma vez que você os conhece, não precisa se preocupar muito com o resto, porque as chances são de que os recursos não estejam fora do escopo. Você pode ajudá-lo com seu PM, mas uma vez que o produto principal é feito e resolve o problema principal, o resto não é crucial para o funcionamento do produto, a menos que haja mais tempo para trabalhar nele antes que outro projeto apareça.

Pergunte se o produto é capaz de funcionar com ou sem recurso x? Se é capaz de funcionar sem isso, você está feito (por enquanto).

Por mais que eu queira continuar construindo e dimensionando um produto, uma vez que ele é lançado, o restante é tipicamente manutenção, até que coisas novas precisem ser adicionadas com base em usuários e métricas, ou nós temos os recursos necessários para seguir em frente. Com isso em mente, tentaria equilibrar o tempo em outros projetos que têm um cronograma mais agressivo. Eu desestimularia fazer um trabalho exploratório para um projeto lançado com P2 e P3 + OKRs, a menos que seja necessário progredir imediatamente, você tem a largura de banda necessária para isso e será implementado o mais rápido possível.

Notas finais

Lembre-se de que existe uma linha tênue entre o refinamento e o uso para ditar que seu projeto não é feito. O design excessivo pode atrapalhar o processo geral se você não pensar em como o refinamento ajudará o usuário ou resolverá o problema. Se houver um bom motivo para refinar, faça-o. Caso contrário, uma vez que um projeto é "concluído" com base em prazos, ou se você tiver outros projetos para trabalhar, então você está feito na maior parte. Isso não leva em consideração o fato de que, em uma organização, as métricas depois de um projeto podem exigir que você analise seu projeto e trabalhe nele, mas as chances de refazê-lo são pequenas, especialmente se sua organização passar por uma infinidade de revisar processos.