Joel on Software

Joel on Software Joel sobre Software

 

Projeto de Interface com Usuário para Programadores
Capítulo 1
Capítulo 2
Capítulo 3
Capítulo 4
Capítulo 5
Capítulo 6
Capítulo 7
Capítulo 8
Capítulo 9

Outros artigos de "Joel on Software" em Português

Outros artigos de "Joel on Software" em Inglês

Envie email para o autor (apenas em Inglês)

 

Projeto de Interface com Usuário para Programadores
Capítulo 9: O Processo de Projetar um Produto


Por Joel Spolsky
Traduzido por Rosana de Oliveira
9 de Maio de 2000

Nós falamos sobre os princípios da bom design, mas princípios somente dão a você uma maneira de avaliar e melhorar um design existente. Mas... como você imagina que o design deveria ser em primeiro lugar? Muitas pessoas escrevem esboços grandes, funcionais de todas as características que elas pensam. Então elas fazem o design de cada uma, e fixam no item de menu (ou página da web). Quando elas terminam, o programa (ou web site) tem toda a funcionalidade que elas queriam, mas não resultam bem. As pessoas sentam e não sabem o que aquilo faz, e elas não sabem como realizar o que elas queriam.

A solução da Microsoft para isto é alguma coisa chamada Plano Baseado em Atividade. (Como eu posso dizer, este conceito foi inventado por Mike Conte da equipe do Excel, que ficou aborrecido com aquilo e se dedicou a uma segunda carreira como piloto de carro de corrida). A chave da compreensão é imaginar a atividade que o usuário está fazendo, e focar em fazer isto fácil de modo a realizar aquela atividade. Isto é melhor ilustrado com um exemplo.

Você decidiu fazer um site que permite que as pessoas criem cartões de saudações. Usando uma aproximação, você pode chegar a uma lista de características como esta:

1. Adicionar texto ao cartão
2. Adicionar uma figura ao cartão
3. Pegar modelos de cartões da biblioteca
4. Enviar o cartão:
           a. Usar email
           b. Imprimi-lo

Pela falta de qualquer maneira melhor de pensar sobre o problema, isto pode levar a uma interface de usuário típica da Macintosh, circa-1984: um programa que começa com um cartão em branco, com itens de menu para adicionar texto, figuras, carregar cartões da biblioteca, e enviar cartões. E então o que o usuário vai ter que fazer é sentar e procurar através dos menus, tentando descobrir todos os comandos disponíveis, e então fazer a sua própria síntese de como colocar estes pequenos comandos juntos para criar um cartão.

Agora, o plano baseado na atividade diz que você precisa providenciar uma lista de atividade que os usuários podem fazer. Então, você conversa com os seus usuários potenciais, e você monta esta lista com "os três itens mais importantes":

  1. Saudação de Nascimento
  2. Convite de Festa
  3. Saudação de Aniversário

Agora, ao invés de pensar sobre o seu programa como um usuário (em termos de quais características você precisa ter para fazer um cartão), você está pensando sobre isto como um usuário, em termos de, quais atividades o usuário está fazendo, especificamente:

  1. Enviando um cartão de nascimento
  2. Planejando uma festa, e convidando as pessoas
  3. Enviando uma cartão de aniversário

De repente, todos os tipos de idéias passaram pela sua cabeça. Ao invés de começar com um cartão branco, você pode começar com um menu como este:

O que você quer fazer?
  • Enviar um cartão de nascimento
  • Enviar uma cartão de aniversário
  • Enviar um convite para festa
  • Iniciar com um cartão em branco

De repente os usuário acharão muito mais fácil iniciar com seu programa, sem pesquisar nos menus, já que o programa virtualmente os guiará através dos passos para completar a atividade. (Existe um risco que se você não escolher as atividades corretamente, você alienará ou confundirá os usuários que podem ter sido capazes de usar o seu programa, digamos, para enviar um cartão de Hanukah, mas não vêem este como uma opção. Portanto seja cuidadoso ao selecionar atividades que cubra a maioria do mercado que você quer atingir.)

Ao olhar para a nossa lista de três atividades sugere algumas boas características que você pode querer adicionar. Por exemplo, se você está enviando um cartão de data de nascimento ou aniversário, você pode querer ser lembrado no próximo ano a enviar um cartão para a mesma pessoa... então você pode adicionar um checkbox que diga "me lembre no próximo ano". E um convite de festa precisa de uma maneira de RSVP, portanto você pode adicionar uma característica que deixa você receber as RSVPs das pessoas eletronicamente. Ambas estas idéias de características quase se parecem com a atividade que os usuários estão executando ao invés das características na aplicação.

Este exemplo é trivial; para qualquer aplicação séria, as recompensas do plano baseado na atividade são ainda maiores. Quando você está projetando um programa do rascunho, você já tem uma visão de quais atividades seus usuários vão estar fazendo. Imaginar esta visão não é tão difícil, isto quase não requer nenhum esforço para fazer um brainstorming com os cooperadores, escreva uma lista de atividades potenciais, e então decida qual delas você quer focar. Entretanto forçar você mesmo a listar estas atividades no papel ajudará enormemente seu projeto global. 

Plano baseado na Atividade é muito mais importante quando você está trabalhando na versão dois de um produto que as pessoas já estão usando. Aqui, pode ter um assunto de observação de uma amostra de clientes para ver para que eles estão usando seu programa. 

Nos dias do Excel 1.0 até 4.0, a maioria das pessoas na Microsoft pensavam que a maioria das atividades dos usuários comuns era fazer o que fosse cenários financeiros, onde você faz coisas como alterar a taxa de inflação e ver como isto afeta sua lucratividade. 

Quando nós estávamos desenvolvendo o Excel 5.0, a primeira distribuição principal para usar o plano baseado em atividade seriamente, nós tínhamos somente que observar cinco clientes usando o produto antes nós percebemos que uma número enorme de pessoas usam o Excel somente para armazenar listas. Eles não estão entrando com qualquer fórmula ou fazendo qualquer cálculo de modo algum! Nós não tínhamos se quer considerado esta possibilidade antes. Armazenar listas passou a ser muito mais popular do que qualquer outra atividade com o Excel. E isto nós forçou a inventar uma quantidade enorme de características para tornar mais fácil manter listas: mais fácil a classificação, entrada automática de dados, a característica de AltoFiltro que ajuda você a ver uma parte da sua lista, e características de multi-usuário que permite que várias pessoas trabalhem na mesma lista ao mesmo tempo enquanto o Excel automaticamente harmoniza tudo.

Enquanto o Excel 5 estava sendo projetado, Lotus trouxe um "paradigma novo" as planilhas chamadas Improv. De acordo com a versão da imprensa, Improv era uma nova geração inteira de planilha, que ía esmagar tudo que existia anteriormente. Por várias razões estranhas, Improv estava disponível primeiro no NeXT, que certamente não ajudou na sua venda, mas uma quantidade de pessoas espertas acreditavam que o Improv seria para o NeXT o que o VisiCalc era para o Apple II: ele seria a aplicação matadora que faria as pessoas sair e comprar todo hardware novo só para rodar um programa.

Naturalmente, o Improv é hoje um rodapé na história. Procure por ele na web, e os únicos links que você encontrará são de gerências de lojas extremamente organizadas que têm, por alguma razão, feito um web site com um inventário de todas as coisas que eles têm pegando pó.

Por quê? Porque no Improv, era quase impossível somente fazer listas. Os projetistas do Improv pensaram que as pessoas estavam usando planilhas para criar modelos financeiros multi-dimensionais complicados. Em contrapartida, se eles tivessem perguntado às pessoas, eles descobririam que fazer listas era muito mais comum do que modelos financeiros multi-dimensionais complicados, e no Improv, fazer listas era um perfeito martírio, se não impossível.

Portanto o plano baseado na atividade é útil na versão inicial da sua aplicação, onde você tem que fazer suposições sobre o que as pessoas querem fazer, mas é ainda mais útil quando você está planejando o upgrade, porque você entende o que os seus clientes estão fazendo.

Um outro exemplo, da web, é a evolução do deja.com, que começa como um imenso, índice de busca do Usenet chamado dejanews. A interface original basicamente tinha uma caixa de edição e dizia "procura Usenet por blá," e era isto. Em 1999 um pouco de plano baseado na atividade mostrou uma atividade comum de usuário que era fazer pesquisa de um produto ou serviço, da natureza "qual carro eu deveria comprar". Deja era completamente reorganizado, e hoje, é muito mais um serviço de pesquisa de opinião de produto: a habilidade de pesquisa do Usenet está quase completamente escondida. Isto aborrecia o pequeno número de usuários que estava usando o site para pesquisa se o seu cartão de vídeo Matrox funcionava com Redhat Linux 5.1, mas ele deliciou uma população muito maior de usuários que simplesmente queria comprar a melhor câmara digital.

A outra grande coisa do plano baseado em atividade é que deixa você fazer uma lista de quais características não fazer. Quando você cria qualquer tipo de software, a realidade é que você terá três vezes mais características do que você tem tempo para fazer. E uma das melhores maneiras de decidir quais características serão feitas, e quais características ficam fora, é avaliar quais características suportam a atividade mais importante do usuário.

Usuários Imaginários.

Todos os melhores designers de IU na indústria concordam com uma coisa: você tem que inventar e descrever alguns usuários imaginários antes que você possa projetar sua IU. Você pode lembrar na introdução deste livro, eu introduzi um usuário imaginário Pete:

Pete é um contador para um publicitário que tem usado Windows por seis anos no escritório e um pouco em casa. Ele é competente e técnico. Ele instala seu próprio software; ele lê PC Magazine, e ele tem até mesmo programado algumas macros simples no Word para ajudar as secretárias em seu escritório a enviar faturas. Ele está adquirindo uma modem em casa. Pete nunca usou um Macintosh. "Eles são muito caros," ele lhe dirá. "Você pode obter um PC de 700 Mhz com 128 Meg RAM pelo preço de..." OK, Pete. Nós entendemos.

Quando você lê isto, você pode quase imaginar um usuário. Eu poderia também ter inventado um outro tipo de usuário:

Patricia é uma professora de Inglês que escreveu vários livros de sucesso sobre poesia. Ela tem usado computadores como processadores de texto desde 1980, entretanto os únicos dois programas que ela já usou são Nota Bene (um antigo processador de texto acadêmico) e Microsoft Word. Ela não quer perder tempo aprendendo a teoria de como o computador trabalha, e ela tende a armazenar todos seus documentos em qualquer diretório que eles forem se você não tiver conhecimento sobre diretórios.

Obviamente, desenvolver software para Pete é bem diferente do que para a Patricia, que em contrapartida e bem diferente de Mike, um garoto de 16 anos que usa Linux em casa, conversa no IRC por horas, e não usa o software "Micro$oft".

Quando você inventa estes usuários pensando se o seu design é apropriado torna-se muito mais fácil. Por exemplo, muitos programadores tendem a sobrestimar a habilidade do usuário típico por imaginar coisas completamente fora. Sempre que eu escrevo alguma coisa sobre interfaces de linha de comando ser difícil de usar, eu recebo o email inevitável dizendo que a interface de linha de comando são ultra poderosas porque você pode fazer coisas como 'gunzip foo.tar.gz | tar xvf -'. Mas tão logo você tenha que pensar sobre fazer Patricia digitar "gunzip..." torna-se óbvio que aquele tipo de interface não vai atender as necessidades dela, nunca. Pensando sobre uma pessoa "real" dá a você a empatia que você precisa para fazer uma característica que atenda aquela necessidade da pessoa. (Naturalmente, se você está fazendo o backup do software Linux para administradores avançados, você precisa inventar um personagem como "Frank" que se recusa a tocar no Windows, o qual ele somente se refere como um "sistema operacional" entre aspas, usa a sua versão personalizada modificada de tcsh, e roda X11 com quatro xterms durante todo o dia. E aproximadamente 11 xperfs.)

Para resumir, projetar um bom software leva aproximadamente seis passos:

  1. Invente alguns usuários

  2. Imagine as atividades importantes

  3. Imagine o modelo do usuário -- como o usuário esperará realizar aquelas atividades

  4. Desenhe o primeiro rascunho do design

  5. Interaja com seu design repetidas vezes, tornando mais fácil até que esteja bom dentro das capacidades do seu usuário imaginário

  6. Observe humanos reais tentando usar o seu software. Perceba as áreas onde as pessoas têm problemas, que provavelmente demonstra áreas onde o modelo do programa não coincide com o modelo do usuário.

Boas IU vendem software, mas também faz as pessoas felizes, porque as pessoas são felizes quando elas realizam a tarefa que elas queriam realizar. Que é o porque que o design de IU é um campo bom de se satisfazer e estar. Onde mais você vai ter a chance de fazer milhões de pessoas um pouco mais felizes?





Esse artigo apareceu originalmente em Inglês com o título User Interface Design for Programmers Chapter 9: The Process of Designing a Product  

Joel Spolsky é o fundador da Fog Creek Software, uma pequena empresa de software na cidade de Nova York. Formou-se na Universidade de Yale, e trabalhou como programador e gerente na Microsoft, na Viacom e no Juno.


O conteúdo dessas páginas reflete exclusivamente a opinião do autor.
Todo o conteúdo Copyright ©1999-2005 Joel Spolsky. Todos os direitos reservados.

FogBUGZ | CityDesk | Fog Creek Software | Joel Spolsky