it-swarm-pt.com

Práticas recomendadas para entregas de protótipos interativos?

Estou apresentando os protótipos do Axure a um cliente pela primeira vez. Embora o Axure ofereça anotações e especificações muito detalhadas, acho que é um exagero para este projeto - um aplicativo de agendamento para uso interno. O gerente de projetos está acostumado a fluxos do Visio e composições do Photoshop, mas está tão ansioso quanto eu para elevar o processo de design/aprovação. Quero descobrir qual nível de detalhe é recomendado na interface do usuário, anotações e especificações. Minha pergunta não é específica para o Axure, mas essa é a ferramenta que estou usando.

Revisado: eu gostaria de reorientar a questão para os resultados finais. Quais entregas são importantes para o cliente ver e até que ponto você as desenvolve? Por exemplo, as especificações do Axure podem ser úteis para a equipe de desenvolvimento, mas para o ciclo de aprovação de design de UX/UI, não acho que sejam úteis.

9
JK Hudson

A razão pela qual fazemos protótipos é transmitir idéias/conceitos/soluções que não podem ser transmitidas através da exibição de telas estáticas.

Eu sempre uso a regra de que, sempre que você quiser dar uma ideia ou entender o fluxo em seu aplicativo/serviço da web, faça protótipos.

É com os protótipos que você pode simular como algo pode parecer.

Por exemplo, se você deseja mostrar uma funcionalidade de pesquisa que funciona como o google sugere e é improvável que seu cliente saiba o que você quer dizer apenas com referência. Em seguida, faça um protótipo para mostrá-lo.

Acredito que o fluxo de qualquer aplicativo seja um dos pontos cegos do UX normal. Muito do que cria um aplicativo é o que acontece entre os cliques.

8
ThomPete

Para protótipos, eu diria que você precisa chegar ao nível de detalhe em que é capaz de explicar e ilustrar a funcionalidade de uma maneira fácil de entender.

No entanto, também é de grande importância que ninguém acredite que seu protótipo esteja finalizado (ou quase finalizado) ) produtos. Nesse caso, você corre o risco de que seu cliente pense que poderá entregar amanhã ... ou se encontrará preso em uma discussão sobre pequenos detalhes (cosméticos) - em um protótipo que não necessariamente se parece exatamente com o produto final, é isso!


Em geral, um protótipo ou modelo inacabado/não polido convidará a entrada do usuário, críticas e soluções alternativas. Pode fazer com que os usuários vejam potenciais transformações da prática existente (Ehn e Kyng 1991, p. 652). Além disso, dificilmente será confundido com um produto final (Ibid .; Beyer & Holtzblatt 1998, pp. 372-3). (É exatamente por isso que eu amo Balsamiq Mockups .)

Um protótipo funcional, por outro lado, possibilita aos usuários obter experiência prática em situações de uso concreto (Bødker & Grønbæk 1991, p. 198).

Em um protótipo, não há dúvida de uma tentativa de completude; sua função é lançar luz sobre aspectos específicos do sistema de informação. Haverá ênfase particular nos aspectos sobre os quais há mais incerteza. ... Protótipos são usados ​​para verificar a precisão das suposições feitas sobre esses aspectos. Ao contrário dos sistemas de produção, os protótipos geralmente são incompletos e não se destinam a funcionar sem falhas. (Vonk 1990, p. 20-1)


Referências

Beyer, H. & K. Holtzblatt (1998). Projeto contextual: definindo sistemas centrados no cliente. São Francisco, Califórnia: Morgan Kaufmann Publishers

Bødker, S. & K. Grønbæk (1991). "Design em ação: da prototipagem por demonstração à prototipagem cooperativa", em Kyng, M. & J. Greenbaum (Eds.), Design at Work (pp. 197-218). Nova Jersey: Lawrence Erlbaum Associates

Ehn, P. & M. Kyng (1991). "Computadores de papelão: zombando ou pronto para o futuro", em Wardrip-Fruin, N. & N. Montfort (Eds.), The New Media Reader (pp. 651 -62). Cambridge, MA: The MIT Press

Vonk, R. (1990). Prototipagem: O uso efetivo da tecnologia CASE (pp. 20-33). Englewood Cliffs, Nova Jersey: Prentice Hall Inc.

12
jensgram

A natureza de suas entregas depende honestamente do escopo do projeto, do trabalho que você está realizando e com que tipo de cliente você está lidando. O maior desafio que você precisa enfrentar é determinar o que o cliente espera e depois fornecê-lo (ou ajustar as expectativas, quando necessário).

Por exemplo, um colega meu criou recentemente um protótipo interativo para um cliente no setor de energia em HTML, CSS e Javascript. A interface do usuário que precisava ser copiada (era uma reformulação) era tão complicada que a melhor maneira de conversar sobre o assunto com o cliente era de alta fidelidade. Como ele pegou o cliente pela mão e o conduziu pelo processo de iteração no protótipo, o cliente também foi capaz de aprender muito sobre o que sua UI atual estava fazendo de errado, por que nossas melhorias eram necessárias e valiosas, e isso lhes deu uma boa visão da quantidade de trabalho envolvido na recriação de uma interface do usuário como esta. O trabalho era apenas entregar o protótipo interativo - com base nesse trabalho, o cliente avaliaria seus próximos passos. (Basta dizer que agora fomos contratados para redesenhar e implementar toda a próxima versão do aplicativo.)

Principais conclusões deste processo:

  • Combine a fidelidade do seu protótipo com as expectativas do cliente. Um bom gerenciamento de projetos tem tudo a ver com gerenciar expectativas, e isso não é diferente para um projeto de prototipagem. Então, descubra o que seu cliente precisa ver e, em seguida, combine o tipo de protótipo com o que melhor comunica seu trabalho. Na prototipagem interativa, interpreto "alta fidelidade" como ir além das telas cinza e branco e modelar cores, tipografia, tamanho etc. o mais próximo possível do aplicativo final. A única coisa que deixamos de fora no processo acima mencionado foi a aplicação do estilo da casa (por exemplo, transformando tudo em um horrível tom de verde ;-))

  • Seja o mais transparente possível sobre seu processo de design. Como vários outros já mencionaram, um perigo durante o processo de prototipagem é que o cliente de alguma forma começará a pensar que o protótipo é o mesmo que o produto final. No exemplo acima, meu colega não se concentrou na capacidade de manutenção da base de código ou em algo assim - ele apenas a cortou para o caso de uso específico para o qual estava projetando. Mas como ele comunicou bem seu processo de design com o cliente, explicando cada etapa do caminho e sublinhando o fato de que nada disso era final, o cliente conseguiu entender o que estava recebendo. É uma armadilha importante a ser evitada, mas o bom gerenciamento de expectativas pode fazer um bom trabalho.

  • Documente o que você está fazendo e por quê. Um protótipo interativo não é suficiente. Você precisa apresentá-lo de uma maneira que o cliente possa entender - não apenas o proprietário do produto com o qual você está trabalhando diretamente, mas todas as partes interessadas na cadeia que não estará envolvido no processo de design. Meu colega criou um site em miniatura apresentando aspectos das telas nas quais ele havia trabalhado e escreveu um código simples para destacar várias partes de como as coisas funcionavam. Esses metadados foram inestimáveis ​​para garantir que, conforme o resultado do protótipo fosse repassado dentro da organização após a conclusão, os fios não fossem cruzados ou confusos.

Então, as melhores práticas para entregas interativas de protótipos? Honestamente, trata-se de boa comunicação e gerenciamento de expectativas. Você precisa descobrir o que o cliente espera ver. Depois de fazer isso, a parte mais difícil fica para trás - agora você pode prosseguir e fazer seu trabalho de design!


PS. Não para conectar nosso produto, mas meu colega o utilizou durante esse processo e várias vantagens da ferramenta vieram à tona. Por exemplo, o fato de todos os nossos protótipos serem instantaneamente compartilháveis ​​on-line fez com que fosse fácil manter o cliente atualizado sobre o progresso e poderíamos até orientá-lo nas coisas por telefone. Isso foi uma grande melhoria em relação a situações antigas em que os clientes tinham que estar em nossos escritórios ou não podiam ver o que estava acontecendo.

6
Rahul

Tentei o Axure e algumas outras ferramentas para criar protótipos e cheguei à conclusão de que os protótipos eram uma perda total de tempo com um ROI terrível. Voltei a um método muito mais bem-sucedido, usando o PowerPoint para criar storybaords.

Eu uso o slide mestre para colar um espaço em branco de baunilha do meu aplicativo ... a pele como papel de parede. Depois, tenho alguns controles salvos em um slide final, como caixas de combinação e coisas do tipo. Finalmente, tenho uma imagem de um cursor que animei para mostrar onde o usuário clicaria.

Muito rápido, muito fácil, todo mundo tem a capacidade de abri-lo e modificá-lo. E o melhor de tudo, comunica a visão do design com muita clareza.

Eu espero que isso ajude.

2
Glen Lipka

A resposta também pode depender de que tipo de protótipo você estava tentando entregar. Se fosse apenas para uma página da Web (estática), você teria muitas opções, por exemplo ferramentas de design como Photoshop ou Illustrator e até esboços desenhados à mão. Para uma história mais completa/complexa que pode incluir páginas da Web de vários estados, fluxos do usuário e/ou interface do usuário personalizada, normalmente uso uma combinação de Balsamiq , PowerPoint e Word.

  1. Balsamiq para criar os modelos.
  2. PowerPoint para compilar os modelos e/ou capturas de tela; e adicione frases de destaque para adicionar os detalhes necessários. Isso é muito útil, especialmente. ao ilustrar sobre fluxo.
  3. Word (ou qualquer processador de texto) para documentar as decisões de plano de fundo e design mais detalhadas. Pela minha experiência em trabalhar com várias ótimas pessoas e designers de produtos, acho esse um bom hábito a ser desenvolvido, porque muitas vezes não conseguimos lembrar sobre o que decidimos em detalhes.

Eu sei que a pergunta era mais sobre encontrar as ferramentas eficazes, mas, IMHO, nada supera a chance quando você pode conversar pessoalmente sobre suas decisões de design (ou também pode ser via meios virtuais).

2
moey

"Quais entregas são importantes para o cliente ver e até que ponto você as desenvolve?"

Um produto que comunica totalmente a interação e a intenção da interface do usuário é importante. Você o desenvolve na medida do necessário para conseguir isso. Os detalhes dessa resposta são totalmente dependentes do projeto e do cliente.

Como um aparte, é com isso que o desenvolvimento Agile tenta ajudar. A idéia é que você obtenha entregas 'tocáveis' para os clientes mais rapidamente, para que os inevitáveis ​​ajustes ocorram mais cedo ou mais tarde.

2
DA01

Eu usaria o Balsamiq www.balsamiq.com ou o Mockingbird gomockingbird.com para prototipagem rápida. Se você precisar fornecer um plano de interação mais detalhado, vá para o Axure.

Eu tive bons resultados combinando desenhos criados (no Photoshop) e Axure para produzir uma demonstração muito realista, para vender idéias de design para partes interessadas (mais seniores) que não têm a capacidade/desejo de interpretar quadros de arame.

0
Rob Varney

Como outros indicaram, isso depende do que está sendo revisado. Se sim, como os modelos do Balsamiq para diminuir a estrutura e a interação. As imagens do Balsamiq fazem um bom trabalho em transmitir o que a maquete é (uma estrutura proposta) e não (uma composição de design), e vamos nos concentrar na estrutura em vez do design gráfico. É só depois que essa parte é concluída que eu passo para o design visual e, se a estrutura já estiver de acordo, você poderá usar arquivos simples para as aprovações de design. O que você realmente deseja evitar é entrar em uma discussão sobre o tom adequado de verde para usar quando você ainda não decidiu como o aplicativo deve funcionar.

0
ThatSteveGuy

Para recapitular:

Práticas recomendadas para protótipos interativos

  • Mostrar o fluxo entre telas
  • Mantenha a interface do usuário não refinada para definir as expectativas de que o aplicativo não seja concluído e convidar comentários.
  • Use a metodologia Agile e forneça várias iterações ao cliente para resolver problemas de design antes do início da codificação
  • Conclua a interface do usuário e as anotações apenas no nível de integridade que o cliente precisa para entender a interação; O nível de abrangência varia de acordo com o cliente

Estes são os meus principais tópicos. Alguém com mais alguma coisa a acrescentar?

0
JK Hudson