Quais princípios de design de UI, como “separação de preocupações”, posso usar para convencer os desenvolvedores de que a UI precisa de conserto?[fechado]

Question

Fechado.Essa questão precisa ser mais focado.No momento não está aceitando respostas.

---

Quer melhorar esta questão? Atualize a pergunta para que ela se concentre em apenas um problema, editando esta postagem.

Fechado 5 anos atrás.

Recentemente, tive uma grande discussão com a equipe relacionada ao design de UI para nosso projeto de software recente.

Precisamos integrar um sistema especial de controle de versão em nosso produto existente, que é uma ferramenta de teste de software para teste escrevendo e reproduzindo scripts de teste.

A equipe de design apresentou um design com o qual não consigo concordar e considera que vai contra as regras básicas de design.

O maior problema do design, do meu ponto de vista, é que eles adicionam coisas especiais de controle de versão (como criar uma visualização, script de check-in/out) em nossa UI existente (na verdade, copiam a UI existente, alteram-na e adicionam algo em ).Por exemplo, em nossa caixa de diálogo Abrir projeto, copie a UI e adicione dois botões para acionar algo especial de controle de versão (como antes de abrir o script.deve ter uma visualização de controle de versão que contenha o código-fonte do projeto).

Discuti muito com a equipe de design que é uma má ideia juntar coisas diferentes, em nosso exemplo, o recurso da ferramenta de teste de software e o recurso de script de controle de versão.E eu expliquei que ao fazer isso sairá UI duplicada, e mais situações para a mesma resolver, também um grande problema de manutenção.E eu prefiro separar os dois da UI, uma UI (uma caixa de diálogo ou assistente) deve focar apenas em uma das duas coisas diferentes.

Resumi como princípio de design de UI que "uma UI não deve conter duas coisas totalmente diferentes".Embora eles argumentem isso, eles querem pagar esse esforço e todos os esforços colaterais (como mais UI, mais situações para a UI resolver, mais esforço de desenvolvimento/teste/manutenção em comparação com um design de UI que separa as duas coisas diferentes), para o usuário para obter um software fácil de usar e com boa usabilidade.Claro, discordo totalmente dessa afirmação, como pode um software que não é bom em todos os outros aspectos ser bom para o usuário?E não há nada para medir, pois a equipe de design ainda não possui um projeto completo.

E acabei não conseguindo convencer a equipe.Tudo parece ainda objetivo.

Isso me levou a pensar: existe alguma boa orientação/prática/princípio de design de interface do usuário que cubra nossa situação (para separar diferentes preocupações, em detalhes, depurar/executar necessidades de script e necessidade de script de controle de versão, por não colocá-los juntos em uma UI especial, caixa de diálogo ou assistente, etc.)

Eu apreciaria qualquer comentário e sugestão relacionado a todo o problema, não especial à questão acima.também responderei qualquer coisa que não expressei bem aqui.

Por favor, não feche isto :) este é realmente um GRANDE problema para mim como gerente de desenvolvimento.

Answer 1

Concordo com @JanNeilson que os princípios de design não ajudarão você a convencer os desenvolvedores a mudar o design da IU.

O que funciona é Testando usabilidade. Observar alguns usuários travarem ao tentar usar o software fará com que os desenvolvedores se contorçam e queiram consertar a IU.Por outro lado, se você perceber que usuários reais podem usar o novo software perfeitamente, não há problema e os princípios de design não importam.

O teste de usabilidade pode ser um processo formal em que você traz clientes para um laboratório, pede-lhes que realizem tarefas específicas com seu software e grava vídeos do usuário e da tela.

Importante: Certifique-se de informar aos usuários de teste que você não os está testando;que você está pedindo ajuda para testar o software.Explique que você não ficará ofendido se eles não gostarem do software.Você quer reações honestas.Periodicamente, peça-lhes que digam o que estão pensando, ou seja,"pensar em voz alta" enquanto descobrem o que fazer.Não responda às perguntas de como fazer, a menos que eles fiquem totalmente travados.

O teste de usabilidade também pode ser um processo informal em que você pede a alguns colegas de trabalho aleatórios para experimentá-lo.Eu fiz isso no refeitório, apenas mostrando a alguns colegas de trabalho uma nova UI e perguntando o que eles acham que alguns novos ícones significam (representam).

Faça anotações durante ou logo após cada teste.Você pode fazer com que os desenvolvedores assistam ao vídeo gravado posteriormente (edite as partes de espera para que os desenvolvedores assistam tudo) ou assista ao vídeo em outra sala durante o teste.Ou, sem o vídeo, você pode trazer um desenvolvedor de cada vez para a sala para assistir, mas peça-lhes que fiquem quietos.O desenvolvedor não deve responder às perguntas do usuário sem primeiro dizer "Sinto muito por ter construído uma interface de usuário tão ruim".

Se o seu software não estiver pronto para esses testes, você poderá fazer testes de usabilidade com uma maquete de papel.

Existe um campo inteiro dedicado aos testes de usabilidade.Existem especialistas bem treinados.Você pode contratar consultores experientes para fazer isso ou aprender sobre isso e experimentar você mesmo.

Uma pesquisa na web revela muitos artigos e livros.Aqui está um artigo muito bom para começar:http://alistapart.com/article/usability-testing-demystified

O primeiro parágrafo de Wikipedia sobre testes de usabilidade diz:

Testando usabilidade é uma técnica usada no design de interação centrado no usuário para avaliar um produto testando-o nos usuários.Isso pode ser visto como uma prática de usabilidade insubstituível, pois fornece informações diretas sobre como os usuários reais usam o sistema.Isso contrasta com os métodos de inspeção de usabilidade, onde os especialistas usam métodos diferentes para avaliar uma interface do usuário sem envolver usuários.

Eu adicionei o itálico.Em outras palavras, você não é possível obter uma boa usabilidade sem testes de usabilidade. Por outro lado, ter especialistas avaliando uma IU usando princípios e experiência pode ajudar, mas não é essencial.

Answer 2

Você aborda vários aspectos diferentes nesta questão;Vou me concentrar na gestão do Experiência do usuário.

Em vez de discutir generalidades como "separação de preocupações", reviso questões específicas com um design de UI específico, tanto de uma perspectiva de UX quanto de noções mais abstratas ou gerais.Para fazer isso, você precisará de um modelo de UI.E antes do modelo da IU, você precisará de um conjunto básico de descrições da intenção da IU que orientará os modelos da IU.Depois de criar os modelos de IU, você poderá falar sobre os casos de uso da IU e destacar por que os problemas de UX são preocupantes por causa de separação de preocupações ou outros princípios específicos.

Na minha experiência, é ineficaz argumentar as generalidades porque quem entende não precisa ouvir e quem não entende precisa do modelo para ter contexto suficiente para entender.

Se você estiver preocupado com os recursos necessários para construir o modelo da IU, considere limitar o tempo do esforço, por exemplo, "reserve 3 horas para montar um modelo da IU no papel e vamos revisá-lo".