Prós / Contras de modelos PSD versus modelos HTML

Se você estiver criando um site ou aplicativo, as maquetes em HTML são muito superiores porque você está criando a maquete no formato o mais próximo possível do produto final. Isso permite que você defina as expectativas com muito mais facilidade, restringe o que é possível no produto final e oferece uma flexibilidade muito maior.

Esta convenção está gradualmente se tornando conhecida como "design no navegador". O design no navegador contorna o método em cascata por sua própria natureza. As maquetes do Photoshop introduzem uma barreira entre o designer visual e o designer de interação/UX: a pessoa que trabalha no Photoshop pode estar localizada longe, pensando completamente em termos de fidelidade visual, sem considerar o produto final e as restrições que acompanham o navegador. Quando o modelo do photoshop está pronto, ele é "jogado fora" para a equipe de UX para passar para o próximo estágio. Isso não promove um processo iterativo, orientado a comentários.

Eu escrevi m post no blog há alguns meses sobre essa filosofia, que usamos na construção de nossa ferramenta de prototipagem. Aqui estão alguns artigos aos quais mencionei que podem ser úteis (incluindo o de Megan Fisher ao qual você vinculou):

Outros designers e desenvolvedores concordam com ele:

• 37signals ' Por que pulamos o Photoshop explica o processo deles: os modelos do Photoshop não são interativos; eles não dão uma ideia do fluxo do aplicativo; eles incentivam você a se concentrar nos detalhes cedo demais.
• Artigo 24ways.org de Meagan Fisher Make Your Mockup in Markup fala mais sobre os princípios de Clarke e explica como o início da estrutura HTML permite que os designers iterem rapidamente em vários layouts de página.
• Essas 12 dicas para projetar no navegador no Design Shack também oferecem algumas boas idéias.

É uma questão de fidelidade.

O problema é que um dos documentos pode ter maior fidelidade que o outro, dependendo do que você está focando.

Um protótipo de HTML é realmente a única maneira de simular qualquer interação de complexidade moderada. Simplesmente não há como documentar completamente o design de interação em um arquivo PSD.

Por outro lado, se você estiver em um ambiente em que o design visual seja constantemente aprimorado/aprimorado/iterado, o PSD pode ser o melhor 'documento de registro' para lidar com os elementos do design visual.

No final, acho que não se trata de PSD versus HTML. Você precisa de ambos em quantidades diferentes, dependendo das especificidades de suas necessidades, com base no projeto e nos membros da equipe.

Uma desvantagem potencial do uso de maquetes em HTML é que o cliente pode pensar que você terminou o aplicativo - mesmo que tenha dito a eles o que é.

Sério, eu conheci pessoas - clientes e gerentes - que, ao verem uma maquete usando as ferramentas que você normalmente usa para criar o produto real, pensam que você fez a maior parte do trabalho e ficam surpresas quando dizem que serão necessárias outras 6 semanas (ou por muito tempo) para realmente fazer o trabalho.

Remover os modelos de uma etapa pode ajudar a dissipar esse mal-entendido.

No entanto, tendo dito que uma maquete dinâmica permitirá que você e o cliente tenham uma melhor compreensão de como o sistema funciona e como você navega pelo aplicativo.

Não é tarefa do designer visual preparar maquetes interativas, mas sim a do designer de UI/UX. É verdade - muitas vezes eles são a mesma coisa, principalmente devido a razões orçamentárias, mas seus empregos são muito diferentes.

De fato, sua pergunta pode ser reformulada como estática versus dinâmica maquetes.

Na minha opinião, os modelos dinâmicos são quase sempre superiores aos estáticos:

A principal razão na minha opinião é que eles podem ser usados ​​para testes de usabilidade precisos - imaginar que você está fazendo algo é muito diferente de realmente fazê-lo, percebendo o tempo que leva, a quantidade de cliques, o movimento etc. sensação real do fluxo no sistema.

No entanto, nada fica sem preço - criar uma maquete dinâmica geralmente requer muito mais tempo. Além disso, ele cria expectativas mais altas com o cliente - se você pressionar um botão e executar algo no sistema, espera que todos os botões tenham o mesmo desempenho (e alguns podem ser menos relevantes para o cenário principal).

Com uma maquete estática, também pode ser mais fácil orientar os clientes e desenvolvedores pelos casos de uso - você simplesmente mostra as telas uma por uma na ordem "correta", certificando-se de que todos os casos de uso sejam cobertos como você pretendia. O uso de um dinâmico pode dar aos usuários "muita liberdade", fazendo com que eles percam os principais casos de uso etc.

BTW - você não precisa ser um programador para criar modelos html. Existem muitas ferramentas (por exemplo, Axure, Balsamic, Flair Builder e muitas outras) que permitem a criação de tais maquetes por não programadores.

Com a crescente popularidade do design responsivo, faz até mais usar um modelo dinâmico (HTML presumível). Ao projetar o layout inicial inicial, encontro-me constantemente redimensionando o navegador para ver como o layout funciona em várias larguras.

Não é possível tentar especificar um design responsivo com uma imagem estática e expressá-lo com várias imagens estáticas que consome tempo e é excessivamente complexo.

Resposta anedótica

Recentemente, trabalhei em um site em que o modelo principal foi criado no Photoshop (que vou chamar de "PS"), mas as seções individuais do site ainda precisavam ser projetadas. Eu estava trabalhando em várias seções com alguns requisitos de interface do usuário não padrão e tive que decidir se iria zombar deles no Photoshop ou apenas fazê-los com HTML/CSS. Eu escolhi o último e fiquei MUITO grato por isso.

Na verdade, comecei marcando o conteúdo da página e os elementos de navegação em HTML. Depois disso, comecei a brincar com CSS e a ver o que funcionava. Consegui criar rapidamente vários layouts totalmente diferentes e testá-los em um navegador imediatamente. Havia várias opções que eu sabia que não funcionariam quase instantaneamente e fui capaz de abandoná-las rapidamente (onde normalmente eu terminaria o design no PS). Também pude adicionar elementos interativos (show/hide/etc) que não seriam possíveis no Photoshop.

Existem algumas coisas que simplesmente vão caminho mais rápido em HTML vs PS, tabelas por exemplo. É preciso algum esforço real para projetar visualmente tabelas no PS com conteúdo de texto variável dentro das células e cabeçalhos. É super rápido em HTML e você realmente vê como será realmente.

É claro que isso só leva você longe, porque você não pode fazer tudo com CSS. Ocasionalmente, eu voltava ao Photoshop e criava essa e aquela imagem para uma parte específica, mas na maioria das vezes fiquei surpresa ao ver o quanto eu poderia fazer apenas com CSS.

Minha vez

Ainda vou levar isso caso a caso. Mas definitivamente vou me inclinar para maquetes de HTML no futuro.

Se eu estiver certo, acredito que o VB foi inicialmente escrito como uma maneira de eliminar rapidamente alguns modelos ... Com isso em mente, eu diria que a resposta "certa" é provavelmente seguir o caminho das maquetes em HTML.

No entanto, estou no processo de criação de maquetes para um novo produto enquanto digito e, francamente, não acredito que o esforço envolvido na criação de maquetes em html com uma aparência tão boa quanto no formato PSD valha a pena. Conseguir que um pouco de texto, imagem ou etc. apareça exatamente onde você deseja, com um design de layout complexo, levará mais tempo para um desenvolvedor web do que para um artista de photoshop com níveis semelhantes de habilidade.

Além disso, se você vai fazer mais do que textos e designs básicos, provavelmente usará o Photoshop (ou pacotes de gráficos semelhantes) para fazer esse trabalho de design - por que se preocupar em complicar o assunto?

É verdade que, se houver uma justificativa real para o uso de modelos interativos (por exemplo, um grande grupo de usuários para demonstrar como você acha que uma determinada tela interativa funcionará), vale a pena o esforço extra.

Mas se você está apenas mostrando a um cliente como você acha que várias janelas de um aplicativo devem aparecer, não acho que haja justificativa para o esforço extra?