Maquetes: Codificação vs Desenho?


9

Não se trata de web design, mas de design de interface em geral. É melhor codificar os Mockups de interface ou "desenhá-los" em um programa gráfico, como GIMP, Photoshop, etc.?


3
Eu sempre sou instruído a "esboçar sua interface, se você fizer isso no photoshop ou o que as pessoas acharem que você é mais do que você realmente é. Deixe suas maquetes parecerem incompletas, basta baixar o básico para que seu cliente saiba o que esperar e depois expanda na sua interface do usuário mais tarde. "
21711 Hanna

11
É totalmente dependente do projeto. Não existe uma 'melhor' resposta universal.
DA01

Respostas:


14

Faça a si mesmo estas perguntas:

  • Quantos layouts / opções de interface do usuário você pode explorar em 30 minutos codificando? Quantos você pode explorar esboçando?

  • Com que frequência você obtém um design de interface do usuário exatamente na primeira tentativa? Se não com muita frequência, com que rapidez / facilidade é alterar um esboço versus uma maquete codificada?

  • Você pode identificar instantaneamente uma cor apenas observando seu código hex / rgb (não apenas uma estimativa, mas a tonalidade / cor exata)? Quando você imagina uma cor em sua mente, pode traduzi-la imediatamente para o hex? Quão rápido você pode escolher um esquema de cores digitando códigos hexadecimais e usando um seletor de cores real?

O fato de você estar fazendo essa pergunta me diz que você provavelmente é um programador, não um designer, treinando. Se você fosse um designer, seria tão absurdo quanto desenvolver um aplicativo sem planejar a estrutura da classe, o design do banco de dados, a arquitetura do aplicativo etc. e apenas entrar diretamente na codificação - e se você é um desenvolvedor experiente, sabe que tipo de problemas esse tipo de desenvolvimento de baixo para cima causa.

Da mesma forma, se você pular direto para o código sem realmente projetar sua interface do usuário primeiro, os resultados não serão bonitos, apenas porque é impraticável aperfeiçoar um bom design, codificando cegamente.


O OP poderia ser talinkg sobre como usar um editor de código WYSIWYG, com ele você pode escolher as cores ou mesmo "desenhar" os objetos ...
jackJoe

2
Na verdade, a codificação sem projetar a interface do usuário primeiro é uma técnica bastante válida. Isso é claro, se "codificação" não significa partes da interface do usuário ou UX :). A maioria das APIs e bibliotecas são projetadas de fato sem levar em conta a interface do usuário - isso seria impraticável.
thebodzio

11
@ lese, você está lançando um método em cascata. O que pode ser bom, mas a tendência atualmente é de agilidade, na qual é muito provável que você esteja trabalhando em código desde o primeiro dia.
DA01 15/12

@ DA01: Você está trabalhando no código desde o primeiro dia, mas ainda está aplicando uma metodologia de cima para baixo. Não há nada no ágil que diga que você não pode planejar sua arquitetura de dados ou definir a interface do usuário antes da codificação (que eu acho que a maioria das empresas ágeis prefere à UML, diagramas de classes etc.).
Lèse majesté 15/12/11

2
@thebodzio: Sim, claro, é para isso que serve a separação de preocupações. Mas não estou me referindo à codificação do back-end. Quando digo codificar em termos da parte de design da pergunta (não a analogia de programação que usei para ilustrar o ponto - eu sei, um pouco confuso), quero dizer codificar a maquete (CSS + HTML ou qualquer que seja sua linguagem de interface do usuário) )
Lèse majesté

5

Eu votaria no "desenho" primeiro. Na GUI, o layout / apresentação adequado é a chave e exige meios visuais a serem projetados. O design visual da GUI permite alterar rapidamente seu design sem ter que "imaginar" cada alteração, "traduzir para código" e, finalmente, testá-lo. A outra maneira também é possível, mas raramente é melhor (por exemplo, o projeto é extremamente pequeno, como apenas alguns botões e você está familiarizado e costuma trabalhar no nível "código"; durante o design, alguns padrões podem surgir, que podem ser apenas reutilizado com pequenas modificações).

Se você estiver projetando um kit de ferramentas de widget específico, também poderá usar algum aplicativo "GUI designer", se disponível. Ele acelerará ainda mais o processo de design da GUI, porque mostra exatamente como a GUI projetada será exibida no programa em execução e pode exportar a descrição da GUI pronta para usar no nível da apresentação.


2
"e você está familiarizado e costuma trabalhar no nível" código "" -> É importante que a equipe da UI / UX possa trabalhar no nível do código. Todo designer não precisa ser um codificador, mas a equipe precisa ser capaz de criar tudo o que projetar e entender tanto a engenharia quanto o design visual.
DA01 15/12

Posso concordar desde que você queira dizer uma equipe como um todo. Eu acho que, quando você está apenas projetando UI / UX, e não codificando, o conhecimento do funcionamento interno do código pode impedi-lo, porque você tenderá a evitar algumas soluções em potencial apenas porque as considerará "muito difíceis de entender". implemento". Isso significa que seus projetos podem ser despojados de algumas idéias brilhantes, porque o "pensamento do conjunto de ferramentas" bloqueará partes de sua imaginação. Então, novamente ... é apenas um lado da lâmina :) Além disso, a pergunta era apenas sobre "modelos".
thebodzio

11
Eu ouço muito o argumento 'contenha você', mas acho que ele vem apenas de designers visuais que são teimosamente contra o aprendizado do código da camada de apresentação. Essas pessoas também tendem a fazer tudo no Flash. :) Gosto de sugerir que não é diferente do design de impressão. Saber como a impressão funciona não o impede de ser um designer de impressão. Em vez disso, impede a criação de arquivos que obstruem o RIP ou fazem com que a impressora grite com você por 300% de cobertura de tinta. É apenas entender o meio e as restrições associadas.
DA01 15/12

11
O WYSIWYG não é para facilitar o 'pensamento visual'. É para deixar as pessoas que não querem aprender algo flácido. ;) Quanto às restrições, elas definem o meio. Um arquiteto que pode desenhar ótimas imagens, mas não entende o básico de cargas e vãos, é retido em grande medida ... pois nada que eles desenham pode realmente ser construído.
DA01 15/12

11
(e muita da minha opinião foi formada trabalhando com equipes de UX ou que não têm idéia de como criar qualquer coisa que elas inventem. Elas não inovam na maioria das vezes ... mas sim projetam apenas idéias soluções que não são práticas em termos de implementação, cronogramas, usuários ou orçamentos [que são restrições adicionais que, em vez de serem 'paredes', são o que ajuda a definir a solução de design]) PS: boa discussão!
DA01 15/12

3

Para o design da interface do usuário, tenho três estágios com objetivos diferentes:

  1. Desenhando. Primeiro, você deseja ter uma idéia básica de quais elementos existirão e como eles se encaixam. Qualquer detalhe fino ou perfeccionismo estético nesta fase é uma distração. Eu uso um quadro branco e uma caneta apagável e gorda, para que seja impossível se distrair com muitos detalhes e fácil rabiscar um monte de idéias diferentes e começar de novo a qualquer momento. Já ouvi falar de pessoas que só desenham pequenas notas post-it ou usam apenas a mão secundária (por exemplo, mão esquerda, se você é destro) para se forçar a não prestar atenção à estética e se concentrar 100% na idéia e função. (imagem não minha, de Frank Prendegast )

Foto da estrutura de arame do quadro branco

  1. (2!) Simulando.Segundo, você deseja analisar e obter feedback, descobrindo o máximo possível sobre quais são as intuições das pessoas e as respostas não solicitadas antes de iniciar o demorado trabalho de implementação. Isso deve estar no que você trabalha com mais eficiência, já que, se estiver fazendo o certo, deve voltar ao papel frequentemente, buscando críticas e buscando identificar o maior número possível de problemas inesperados o mais cedo possível. Se você é uma máquina de codificação louca e é nisso que trabalha mais confortavelmente, então a codificação é boa, mas a maioria das pessoas trabalha mais rapidamente em algo como Fireworks, Photoshop, software de wireframing dedicado ou talvez um construtor de interface orientado à interface do usuário como o Flash Catalyst (se o produto final não for Flash, o objetivo é obter um bom feedback antes de iniciar a implementação).

  2. (3!) Implementando. Finalmente, você implementa a coisa e pretende fazê-lo de uma maneira que permita obter mais feedback com antecedência e frequência.

Essas três partes do ciclo do projeto têm objetivos diferentes; portanto, se for um projeto grande, faz sentido usar a ferramenta mais adequada para o trabalho em cada estágio.


2

Esta pergunta é um pouco vaga e, como tal, como são as respostas.

Além disso, os projetos variam muito, assim como as equipes.

Dito isto, não há 'melhor'. Trata-se de usar todas as ferramentas em um fluxo de trabalho que faça mais sentido para você e sua equipe.

Em termos gerais, eu diria que este é o tipo de fluxo de trabalho que você deve visar:

  1. Esboço. Lápis + papel. Quadros brancos. Iterar. Trabalhe com o maior número possível de membros da equipe.
  2. modelos de baixa fidelidade. Pode ser PSD, pode ser visio. Pode ser papel. Usuário teste estes.
  3. Comece a construir protótipos. É aqui que você deseja começar a fazer o máximo possível no código de trabalho. Entre no Photoshop conforme necessário e coloque tudo no código o mais rápido possível. Continue testando / iterando pelo usuário.

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.