Um desenvolvedor deve fazer modelos de interface do usuário se não houver designers no projeto?

Estou trabalhando com uma equipe pequena que cria um aplicativo da web proprietário e o UX não é uma prioridade, pois nosso pessoal será quem o operará, mas tentamos facilitar o trabalho deles.

Como desenvolvedor, devo criar uma maquete da interface do usuário antes de começar a criar uma nova tela? Nada muito chique, principalmente o layout geral para conversar com os colegas e ter um modelo de referência. Eu o comparava com a criação de alguns diagramas UML antes de começar a escrever o código cegamente.

Um dos meus colegas de trabalho diz que isso é absurdo e não é meu trabalho fazer isso.

Muitas vezes trabalho nesses projetos, e a resposta é um retumbante SIM, e o mais cedo possível.

As pessoas acham muito mais fácil criticar a melhoria de algum rascunho do que apresentar uma solução do zero. Então, começo a desenhar cedo por dois motivos:

• Dê aos especialistas do assunto uma impressão de como as informações podem ser apresentadas.
• Mostrar minha compreensão atual do problema e das estruturas informativas.

Em casos raros, também foi bom ter algumas provas de que realmente entreguei o que combinamos ...

Os modelos são fantásticos e não há razão para que um desenvolvedor não os faça. (Pode até ser útil para um desenvolvedor fazer um rascunho de um layout de interface do usuário, mesmo quando você tiver designers de interface do usuário no projeto.)

Eu recomendo que você não faça modelos que pareçam telas reais. Se você as compartilhar com usuários finais, muitas vezes focam em coisas que não importam, como cores e temas. O que eu recomendo que você faça é criar desenhos desenhados à mão em papel ou em quadros brancos. Ou, se você quiser que eles estejam no computador, use algo como Pencil Project ou Visio ( aqui estão alguns stencils do Visio de Jonathan Abbett que parecem desenhados à mão).

Sim absolutamente.

Não deixe que outra pessoa lhe diga como fazer seu trabalho. E você está certo, é muito parecido com fazer UML para o seu modelo de dados. Supondo que você seja um desenvolvedor, seu trabalho é fornecer software de qualidade. Se as maquetes o ajudarem a fazer isso, isso fará parte do seu trabalho.

Faça modelos de baixa fidelidade - não os faça parecer telas reais. Você perderá muito tempo ajustando fontes, pixels e bordas, e seus usuários ficarão obcecados com esses detalhes, em vez de se concentrarem na funcionalidade. Algo como o balsamiq é ótimo para isso, não há dúvida de outras ferramentas semelhantes. Com a maquete em mãos, fica muito mais fácil discutir os recursos do projeto com seus usuários e com os outros membros da equipe de desenvolvimento.

Ao projetar "uma nova tela", você deseja discutir primeiro a idéia aproximada da interface do usuário com um usuário e / ou seus colegas. Você não pode discutir isso com um usuário "no código" ou "na UML", que simplesmente não funciona (nem funciona entre os programadores). E você deve esperar jogar fora seus dois ou três primeiros scetches ou, pelo menos, reorganizar os elementos da interface do usuário.

Portanto, se você possui uma ferramenta gráfica de design de interface do usuário que permite fazer isso rapidamente, faz sentido usá-la. No entanto, se você precisar codificar os elementos da interface do usuário manualmente e jogar fora ou reorganizar os elementos da interface do usuário exige muito esforço, obviamente faz mais sentido não "codificar" a interface do usuário primeiro. Será muito mais eficaz criar modelos separados, usando uma ferramenta de desenho gráfico ou simplesmente usando lápis e papel.

Não necessariamente. Há pelo menos duas razões pelas quais os modelos podem ser pouco úteis.

Primeiro, se houver práticas bem estabelecidas da indústria em fazer as coisas que você está prestes a fazer, basta seguir em frente e fazer exatamente isso. Você não estará avançando na arte do design da interface do usuário, mas isso também é bom.

Segundo, seus usuários finais geralmente não sabem o que é bom para eles e por quê. Eles não sabem até que começam a usar o programa (com dados reais ou simulados). Nenhuma quantidade de modelos estáticos ajudará nisso.

Com uma estrutura da Web modestamente flexível, para "apenas outra tela da interface do usuário, como as N telas anteriores", você pode começar com um protótipo funcional e reorganizar à medida que avança. Faça uma maquete e discuta com os colegas sempre que estiver prestes a fazer algo sofisticado.

SEMPRE!

Eu trabalho para uma pequena empresa e sou a única pessoa de TI "Soft". Eu faço todos os requisitos, design, codificação, testes (embora alguém sempre valide meus testes), design de banco de dados etc.

NUNCA CORTE OS CANTOS NAS ETAPAS DE PROJETO - seus usuários finais agradecerão. Você vai agradecer a si mesmo também, porque você vai acabar re-trabalhar-lo para fazer os usuários finais felizes. Mesmo que sua maquete não seja nada além de um pedaço de papel rabiscado à mão, ela fornece uma idéia do que esperar. Levar 10 minutos para rabiscar algo pode economizar o tempo de trabalho de uma semana (esteve lá, fez isso)

Também ajuda na sua codificação. Isso lhe dá a chance de pensar sobre o que você precisa fazer, a maneira mais eficiente de realizá-lo e quaisquer obstáculos que possam estar no caminho.

Por exemplo, você pode achar que o relatório "simples" que você precisa criar é mais difícil do que você imaginou, porque não está capturando alguma data na tabela xyz. Ele também amplia seus horizontes e mostra que sua equipe, superiores ou mesmo pode ser usada para possíveis oportunidades futuras de carreira que você faz mais do que o mínimo necessário e pode sair dessa caixa de "não é meu trabalho" (<--- sério, NÃO seja esse cara, todos nós o odiamos) ou isso lhe dá uma chance de aprender mais.

Vejamos isso de uma maneira mais geral:

• Criar rascunhos é uma boa ideia?
• Quem deve criar os rascunhos?

Criar rascunhos é uma boa ideia?

A criação de rascunhos fornece principalmente 2 benefícios. Primeiro, ele fornece foco, o que leva a uma aceleração no trabalho real sendo realizado. Segundo, torna a discussão da direção do trabalho antes que o trabalho seja concluído muito mais simples.

A desvantagem de criar um rascunho é que ele usa tempo. Não faz sentido gastar 2 horas criando um rascunho elaborado para algo que leva 4 horas para ser criado.

No seu caso, o nível da maquete precisa levar em consideração a quantidade estimada de trabalho que entra no projeto e os benefícios do rascunho. Dependendo disso, sua maquete pode estar em qualquer lugar entre 10 segundos em um post-it e um site totalmente interativo. Para projetos muito grandes e caros, não é incomum que equipes inteiras trabalhem em um rascunho por semanas e criem rascunhos de rascunhos enquanto fazem isso.

Quem deve criar os rascunhos?

Não há necessidade de uma resposta elaborada aqui: Se você se beneficiar da criação de um rascunho, crie um rascunho. Se você se beneficiar de alguém fazendo um rascunho para você, peça a alguém que faça um rascunho para você.

Seu colega está absolutamente correto. Aplicativos internos geralmente têm uma aparência predefinida. Também para esses aplicativos, os usuários não procuram uma interface de usuário de ponta. Tudo o que eles querem é algo que funcione e seja razoavelmente fácil de usar. A menos que você planeje alterar radicalmente a interface do usuário (contra a qual eu recomendo fortemente ... para aplicativos internos), basta seguir a aparência existente. Os modelos são ótimos, mas no seu caso, apenas aumentam sua dor.