COM O FAZER UM BOM TRABALHO EM EXPERIÊNCIA
DO USUÁRIO APESAR DAS LIM ITAÇÕES
Andressa Vieira
Gerent e de Experiência do Usuário da Locaw eb, Brasil. Diret ora e co-fundadora do Capít ulo de São Paulo da Usabilit y Professionals´ Association, Brasil.
E-mail: [email protected]
M arcos Eduardo Vigorito de Oliveira
Bacharel em Comunicação Social com Habilit ação em Publicidade e Propaganda pela Universidade de São Paulo, Brasil. Designer de Experiência do Usuário da Locaw eb.
E-mail: marcos.vigorit [email protected]
Gabriela M ühlbach
Bacharela em Comunicação Digit al pela Universidade do Vale do Rio dos Sinos, Brasil. Designer de Experiência do Usuário da Locaw eb, Brasil.
E-mail: [email protected]
Paula Sato
Bacharel em Comunicação Social com Habilit ação em Jornalismo pela Universidade de São Paulo, Brasil. Designer de Experiência do Usuário da Locaw eb, Brasil.
E-mail: [email protected]
Resumo
Nem sem pre é possível seguir as boas prát icas e m et odologias no dia-a-dia do m ercado de t rabalho. Nest e art igo, designers de experiência do usuário cont am com o driblam as lim it ações (de t em po, t ecnologia e pessoal) para conseguir elaborar as m elhores int erfaces possíveis. Com o os aut ores do art igo t rabalham em um a empresa de infraest rutura de int ernet , usam casos reais do cot idiano de t rabalho para ilust rar problem as e soluções. Assim , são apresent ados exem plos de int erfaces de cont rat ação de domínio e hospedagem , plat aform a de loja virt ual, ferram ent a de help desk e w ebsit e, enquant o casos reais para exem plificar as m et odologias adot adas pela equipe.
Palavras-chave: Usabilidade. Experiência do usuário. M et odologia. M ercado de t rabalho.
1 INTRODUÇÃO
Nos livros, congressos e cursos, arquit et os da inform ação e designers de int eração ouvem m uit as lições sobre com o fazer um bom t rabalho em experiência do usuário. Soment e em um a obra, Nielsen e Loranger (2007) afirm am t er docum ent ado m il diret rizes de usabilidade, que podem ser ent endidas com o boas prát icas a serem seguidas no desenvolvim ent o de w ebsit es.
Ent ret ant o, os profissionais de áreas ligadas à disciplina de experiências do usuário nem sem pre t em a oport unidade de im plement ar as m elhores diret rizes ou mesm o fazer t est es de usabilidade da m aneira indicada. Os prazos apert ados, as equipes pequenas, as rest rições t écnicas e as ordens e exigências de gest ores, que nem sem pre ent endem a im port ância de oferecer um a boa usabilidade ao client e, fazem com que os projet os desenvolvidos no m ercado não sejam desenvolvidos da m aneira ideal.
desenvolver projet os de qualidade nessas condições. Com o os aut ores do art igo t rabalham em um a em presa de infraest rut ura de int ernet , usam casos reais do cot idiano de t rabalho par a ilust rar problem as e soluções. Assim , são apresent ados exem plos de int erfaces de cont rat ação de dom ínio e hospedagem , plat aform a de loja virt ual, ferram ent a de help desk e w ebsit e. Não é int enção dos aut ores crit icar livros e docent es da área, m as sim t ent ar enxergar m aneiras de m elhorar a prát ica da profissão em vist a da realidade do m ercado de t rabalho brasileiro at ual.
2 QUANDO A EQUIPE DE EXPERIÊNCIA DO USUÁRIO DEPENDE DE GERENTES DE PRODUTO E DESENVOLVEDORES
A m aior part e do quadro de funcionários da em presa de hospedagem abordada nest e art igo é form ada por desenvolvedores de diversas plat aform as. A equipe de experiência de usuário, que cont abiliza nove pessoas, t rabalha diret am ent e ligada a esses profissionais e t am bém aos gerent es de produt o (ou PO, do inglês "Product Ow ner” ). No dia-a-dia, designers de experiência do usuário t êm de conversar m uit o com esses dois t ipos de profissionais para ent ender as exigências, det alhar as especificações (layout s e wireframes) e t am bém negociar com o um a nova funcionalidade pode ser im plem ent ada no m enor espaço de t em po e agregando o m áxim o de valor ao produt o.
Essa relação est reit a ent re designers de experiência, gerent es de produt o e desenvolvedores t em pont os positivos e negat ivos. Por um lado, desenvolvedores nem sem pre enxergam o valor de deixar as int erfaces m ais sim ples e fáceis de usar. Se melhorar a usabilidade significar m ais t rabalho e m ais t em po de desenvolviment o, em m uit os casos os program adores t ent am burlar o w ireframe para ent regar o t rabalho m ais rápido. O m esm o acont ece com gerent es de produt o, que reconhecem o valor de ent regar um a int erface com boa usabilidade, m as t êm pressa em ent regar as funcionalidades. Ao m esm o t em po, quando um arquit et o de inform ação sent a para discut ir com PO e desenvolvedores sobre um a hist ória, pode t irar im ediat am ent e dúvidas sobre im plem entação, descobrir as rest rições t écnicas e regras de negócio. Dessa m aneira, poder pensar em um a solução que cont em ple as lim it ações e possibilidades já no com eço do ciclo, evit ando o ret r abalho.
No livro Design Thinking, Tim Brow (2010, p. 18-19) defende a ideia de que o design t em de lidar com t rês t ipos de rest rição: a prat icabilidade, a viabilidade e a desejabilidade. O ideal é t rabalhar esse t rio de fat ores para que eles est ejam em equilíbrio, levando em consideração que os projet os podem se concent rar m ais em um ou out ro aspect o. Norm alm ent e, o designer de experiência do usuário se preocupa m ais com a desejabilidade, o que significa t ornar o produt o agradável às pessoas. Já PO est ão m ais concent rados com viabilidade, ou seja, criar um m odelo de negócio efet ivo e sust ent ável. Por fim , desenvolvedores est ão ligados à praticabilidade, para que possam colocar o produt o no ar o m ais rápido possível. Nessa sit uação, os profissionais de usabilidade t êm o papel de t ent ar harm onizar essas t rês frent es, assegurando que as out ras equipes não se esqueçam de que t er um a int erface am igável e agradável t am bém é essencial para conseguir um produt o de sucesso.
A seguir, é apresent ado um exem plo em que a conversa ent re desenvolvedores e designers de experiência do usuário result ou em um bom design.
2.1 Logo na vitrine de lojas virtuais
O desafio para a equipe de experiência do usuário era fazer com que a ident idade visual de cada um a das lojas fosse respeit ada, levando em cont a que, na época, exist iam m ais de 800 e-commerces, que vendiam produt os de t odos os t ipos (incluindo serviços e doações). Tam bém era necesário considerar que cada um dos client es (usuários do sist em a) pode ut ilizar logos de t am anhos e cores diferent es (incluindo t ransparência), descrições m ais ou m enos com plet as e at é escrever t odos os t ext os com o caps lock ligado.
A quest ão m ais com plicada era a exibição do logot ipo. Algum as lojas não possuem logo, out ras usam im agens coloridas ou em t ransparência com fundo branco (aplicadas sobre um fundo colorido). Com o fazer com que os logos fossem exibidos de m aneira sat isfat ória em t odos os casos?
Nest e caso, a equipe de experiência do usuário não podia chegar a um a solução sozinha, já que precisaria levar em cont a as rest rições t écnicas e t am bém as dificuldades de im plem ent ação. Assim , para definir de que m aneira o logo seria exibido (qual seria o t am anho, se haveria ou não um a cor de fundo at rás da im agem ), foi necessário conversar com o responsável pela program ação de int erface. Logo que foi apresent ado ao problem a, o desenvolvedor sugeriu que a Vit rine exibisse o logo sobre a cor de fundo ou im agem de fundo que o usuário possuía em sua loja. Porém , nest e caso, seria necessário que o sist em a puxasse essas inform ações da int erface de administ ração da loja virt ual, o que t razia algum as com plicações de im plem ent ação. Para a equipe de experiência do usuário, a dificuldade era fazer com que, caso o usuário t ivesse um a im agem de background, ela não aparecesse dist orcida na vit rine. Acont ece que, na loja, o header do sit e pode cont er um a im agem de fundo, que não é redim ensionada em nenhum caso, m as caso seja m enor do que a área de exibição da t ela, é cent ralizada e repet ida infinit am ent e vert ical e horizont alm ent e. Na vit rine, essa im agem t am bém não seria redim ensionada, m as t eria de ser alinhada à esquerda em um a área de exibição bem m enor do que a área do header. Dessa m aneira, corria-se o risco de a exibição do logo e da im agem de fundo não ficarem sat isfat órias (ou seja, legíveis e com um bom layout ) para t odos os casos. Apesar desses problem as, a equipe de experiência do usuário decidiu seguir com a sugest ão dada pelo program ador de int erface.
Porém , quando o w ireframe já est ava pront o e chegou a hora de apresent ar a solução para a equipe de desenvolviment o, foram encont rados out ros problem as. Alguns usuários não haviam cadast rado um a im agem de logot ipo e usavam o banner ou a im agem de fundo com o ident idade do sit e. Nest es casos, lojas que haviam invest ido em personalização do layout seriam prejudicadas na vit rine. Tam bém foi levant ada a quest ão de que t razer a im agem e cor de fundo para o sit e dem andaria bast ant e t em po de im plement ação e t alvez essa solução seria cust osa dem ais levando em consideração que poucos usuários t inham logos t ransparent es. Ou seja, seria dem orado im plem ent ar e, ainda assim , a solução não at enderia a t odos os usuários. Para t ent ar encont rar a m elhor m aneira de lidar com esse problem a, t rês pessoas da equipe de experiência do usuário se reuniram com a gerent e de produt o, o program ador de int erface e m ais quat ro desenvolvedores. Nest a conversa, um dos program adores sugeriu que fosse acrescent ada ao painel de adm inist ração da loja virt ual um a área para que o usuário cadast rasse um logot ipo específico para a vit rine. Os desenvolvedores consideraram que essa solução dem andaria m enos t rabalho e, para a equipe de experiência do usuário, dar ao usuário a possibilidade de cont rolar a m aneira com o sua ident idade visual seria exibida na vit rine era m elhor m aneira de lidar com o problem a.
Figura 1 - A versão 1 traz cor e im agem de fundo para o logot ipo. Na versão final, aplicada na Vit rine de WebSt ore, o logot ipo é exibido sobre fundo branco.
Font e: dados de trabalho dos aut ores na Locaw eb
É int eressant e observar nessa hist ória que a solução adot ada pela equipe de experiência do usuário veio das conversas com os desenvolvedores. Sem essa conversa, não seria possível ent ender as rest rições t écnicas e nem que solução seria m enos cust osa para o desenvolvim ent o e t raria m elhores result ados para o usuário.
3 DRIBLANDO AS RESTRIÇÕES TÉCNICAS E LEGADOS
A em presa em que os aut ores t rabalham est á no m ercado de hospedagem há m ais de dez anos. Assim , m uit os dos sist em as ut ilizados para gerenciar a base de dados de cerca de 240 m il client es surgiram há m ais de um a década e nunca foram subst it uídos – apenas foram agregando m ais e m ais cont eúdo criando um legado gigant esco.
Faz part e do t rabalho da equipe de experiência do usuário criar novas funcionalidades para o painel de cont role usado pelos client es e t am bém planejar ou m elhorar os processos de cont rat ação de t odos os pr odut os. Nesses dois casos, é preciso t rabalhar levando em cont a as rest rições im post as pelos sist em as – por exem plo regras de senha ou dados im prescindíveis para o cadast ro no sist em a cent ral de gerenciam ent o de client es. Out ra dificuldade é t rabalhar com a int erface de um painel de cont role que é dest a m aneira há pelo menos set e anos e est á cheio de problem as e rest rições.
Assim , não bast a aos profissionais de usabilidade det ect ar problem as – seja at ravés do feedback de client e ou por análises heuríst icas. É sem pre necessário conversar com desenvolvedores e gerent es de produt o para ent ender com o funcionam as regras, quais são as rest rições e os legados do sist em a para, só ent ão, poder t rabalhar em propost as e w ireframes. Um problem a com um nas int erfaces de soft w ares é a dist ância ent re o m odelo m ent al do usuário e o funcionam ent o dos m ecanism os. Cooper (2007) discut e essa quest ão, ressalt ando que para as pessoas com uns é m uit o difícil ent ender o funcionam ent o das ferram ent as e a m elhor m aneira de não confundir o usuário é escondendo o que se passa no backend. Para Cooper (2007, p. 29):
A discrepância entre m odelos de im plement ação e ment ais é part icularment e cham ativa no caso de soft wares, onde a com plexidade de im plem ent ação t orna quase im possível para o usuário perceber a conexão m ecânica entre suas ações e as reações do program a1.
Nesses casos, a equipe de experiência do usuário sem pre procura explicar para o client e o que est á acont ecendo, at ravés de m ensagens am igáveis e de fácil com preensão. Out ra abordagem possível é discut ir com desenvolvedores alt ernat ivas para " burlar" as rest rições ou minimizar o im pact o delas para o usuário. A seguir, apresent am os um caso em que foi possível driblar rest rições do sist em a para facilit ar o ent endim ent o dos client es.
3.1 Apresentação da descrição de planos da hospedagem de sites
Quando um client e cont rat a o serviço de hospedagem de sit es não est á apenas locando um espaço em disco no servidor. Out ros serviços vêm inclusos no plano, com o caixas de e-mail, serviço de e-mail m arketing, banco de dados, serviço de est at íst icas e out ros aplicat ivos com plem ent ares. Para o usuário final, t udo isso faz part e do plano pelo qual est á
1
pagando. Porém , para o sist em a da em presa, cada um desses serviços é um a ent idade separada, que precisa ser inst alada.
Por isso, quando um plano é cont rat ado e o client e clica no bot ão " Finalizar" , o sist em a recebe o aviso de que deve inst alar um a hospedagem de cert o t ipo (que, em geral, t em nom e com plicado), com t ant as caixas post ais e espaço de banco de dados. Para o client e, no passo de confirm ação da com pra, cost um avam aparecer o nom e que o sist em a de gerenciam ent o dava ao plano e t odos os serviços adicionais que est avam inclusos, com o pode ser visualizado na Figura 3:
Figura 3 - Processo ant igo de cont rat ação de hospedagem da Locaw eb Font e: dados de trabalho dos aut ores na Locaw eb
Essa form a de descrever os planos para o cont rat ant e era m uit o confusa. O usuário cost um ava ver um a list a enorm e de coisas que não faziam sent ido, que nem ao m enos sabia que est ava cont rat ando. Em m uit os casos, usuários que não são desenvolvedores não ent endiam o que cada um dos it ens significavam e podiam desist ir da cont rat ação por cont a disso.
O desafio para a equipe de experiência do usuário era t ornar esse passo m ais am igável. Porém , não era possível deixar de list ar essas inform ações, já que o sist em a precisava saber quais it ens est avam inclusos no plano para que a inst alação fosse feit a da form a corret a.
essenciais – as out ras inform ações cont inuam a ser t r ansm it idas para o sist em a, m as sem que isso seja visível para o client e.
Figura 4 - Novo processo de cont rat ação de hospedagem da Locaw eb Font e: dados de trabalho dos aut ores na Locaw eb
Talvez a solução encont rada pela equipe não t enha sido a ideal. Ent ret ant o, ela é eficient e em com unicar de form a fácil aos usuários o que est ão cont rat ando, enquant o não dem anda alt erações nos sist em as legados da em presa.
4 ENTENDENDO REGRAS DE NEGÓCIO
Para fazer um bom t rabalho de arquit et ura da informação e experiência do usuário é sem pre necessário conhecer e ent ender o que exat ament e é o produt o e qual é a função dele dent ro da organização. Em t odo projet o, é necessário com eçar o t rabalho ent endendo o que o produt o ou o serviço precisa at ingir, seja gerar lucro, reduzir cust os, t rabalhar a m arca ou qualquer out ra função (GOODWIN, 2009).
Na em presa em quest ão, além de lidar com t odas as regras dos produt os, de cobrança e dos sist em as, a equipe de experiência do usuário t am bém precisa ent ender os requisit os, regras de negócio e rest rições dos seus parceiros, com o Correios, Regist ro.br e PayPal.
Ant es de definir quais cam pos o usuário t erá de preencher para fazer um cadast ro, ut ilizar um meio de pagam ent o ou cont rat ar um serviço, é necessário est udar a fundo com o funcionam as regras do parceiro. Só ent ão é possível saber quais cam pos são obrigat órios, por que eles são necessários, que tipos de int erações são im possíveis e, assim , saber com o com unicar essas inform ações aos client es.
cont at o com a equipe de negócios da própria em pr esa e com parceiros, para ent ender as regras e est ar sem pre inform ada sobre m udanças.
A seguir, é det alhado um caso em que um a regra de negócio ext erna afet a a m aneira com o é est rut urado o processo de cont rat ação de serviços.
4.1 Seguindo as regras da Registro.br
Todos os dom ínios com final “ .br” são regulament ados pela Regist ro.br, pert encent e ao Com it ê Gestor da Int ernet no Brasil. Porém, out ras em presas podem servir de int erm ediárias, oferecendo o serviço de regist ro. Para isso, precisam exigir de seus client es os m esm os dados que a Regist ro.br, que depois serão enviadas à parceira. Em presas brasileiras t am bém podem oferecer domínios int ernacionais (sem a t erminação .br), fazendo parcerias com órgãos com o a VeriSign.
M as as regras de regist ro de domínio não são nem um pouco sim ples. A Regist ro.br possui em sua list a 68 Dom ínios de Prim eiro Nível (DPN), que são as ext ensões de cada endereço de int ernet (por exem plo .com .br ou .org.br).
Para alguns DPN, com o .com .br ou net .br, o regist ro pode ser feit o ut ilizando um Cadast ro de Pessoa Física (CPF) ou Cadst ro de Pessoa Juríudica (CNPJ). Já para DPN volt adas a profissionais liberais, com o adv.br (advogados) ou jor.br (jornalist as) , só é possível fazer o regist ro inform ando um CPF válido, e em alguns casos é necessário enviar à Regist ro.br docum ent os que com provem que a pessoa que est á requerendo o regist ro realm ent e est á habilit ada a exercer a profissão.
Já para dom ínios de pessoas jurídicas, com o t ur.br (t urism o) ou t v.br (t elevisão), é necessário possuir um CNPJ. E ainda exist em os casos de DPN especiais, com o am .br (rádios AM ) ou edu.br (inst it uições de ensino superior), para os quais são exigidos CNPJ e docum ent os especiais, que com provem a at ividade da em presa. Já para domínios int ernacionais não é necessário inform ar nenhum docum ent o.
Para a equipe de experiência do usuário, o desafio foi t ornar o regist ro de um dom ínio o m enos confuso possível para o client e, m as sem pre levando em cont a as regras im post as pelos parceiros. Regras de regist ro são universais, ent ão, o ideal é sem pre com unicar conform e a Regist ro.br est abelece para não gerar confusão.
No at ual processo de cont rat ação de hospedagem , o usuário inform a o dom ínio que quer regist rar (incluindo DPN) e o sist em a aut om at icam ent e ret orna com cam pos para os dados que o usuário obrigat oriam ent e precisa inform ar. Caso seja necessário enviar docum ent os suplem ent ares ao Regist ro.br, o client e t am bém já recebe essa inform ação na hora e pode analisar pront am ent e se est á ou não apt o a regist rar t al dom ínio. Out ra m aneira de ajudar os usuários é um link para um a página que inform a em det alhes t odas as regras para regist ro de dom ínio, quais são as DPN especiais e que precisam de docum ent ação suplem ent ar e com o fazer o envio dessas inform ações.
Figura 5 - O sist em a exibe cam pos e inform ações de acordo com as regras para o DPN do domínio que o usuário est á t ent ando contrat ar
Font e: dados de trabalho dos aut ores na Locaw eb
5 COORDENANDO O TRABALHO DE VÁRIOS SETORES DA EM PRESA E EQUIPES EXTERNAS
Um arquit et o da inform ação que t rabalha em um a agência t em de lidar apenas com as equipes int ernas e um ou alguns represent ant es da em presa cont rat ant e. Quando o profissional t rabalha " no client e" , com o é cost um e dizer no m ercado, a hist ória é um pouco diferent e. O arquit et o t em de t rabalhar não só com as diferent es equipes int ernas, mas t am bém com parceiros, consult ores e free-lancers.
de experiência do usuário t em de se preocupar com quest ões que na verdade são de out ros depart am ent o.
O exem plo abaixo m ost ra com o a equipe de experiência do usuário t eve de assum ir o papel de pont e ent re várias equipes em um projet o com plexo que não t inha um gerent e de produt o.
5.1 Desenvolvendo um site com o envolvimento de equipes internas e externas
O projet o de reform ular o sit e int ernacional da em presa em janeiro de 2011 t eve m uit a dificuldade para com eçar a andar. O t rabalho era grande e envolvia a em presa int eira. Ao m esm o t em po, não havia uma equipe alocada soment e para est e projet o – ele dependia de que cada área parasse suas at ividades para priorizar sua part e no sit e. O t rabalho sem pre com eçava, m as não chegava a ser concluído e o projet o ia se arrast ando.
A sit uação ficou ainda m ais com plicada quando, no prim eiro t rim est re de 2011, o gerent e do produt o deixou a em presa. M esm o sem um dono, o projet o t inha de ser feit o e a equipe de experiência do usuário, que naquele m om ent o est ava envolvida no desenvolvim ent o do w ireframe, acabou assum indo a função de coordenar as dem andas das várias equipes.
Por um lado, esse novo arranjo fez com que arquit et os da inform ação assum issem funções que não a sua. Ao m esm o t em po, foi a part ir de ent ão que o projet o com eçou a andar. Com o a equipe de experiência do usuário est á sem pre em cont at o com t odas as equipes, foi m ais fácil conseguir com que t odas as áreas priorizassem as t arefas ligadas ao sit e int ernacional. O envolvim ent o de m ais de um a pessoa – em oposição à dependência do gerent e de produt o – fez com que f osse m ais fácil organizar as dem andas e as ent regas.
A part ir de ent ão, o projet o cam inhou com o envolviment o de algum as equipes int ernas da em presa (m arket ing, jurídico, produt os, sist em as, cobrança e experiência do usuário) e t am bém ext ernas (free-lancer de design, t radut or, consult oria de desenvolvim ent o). Sem pre sob a coordenação da equipe de experiência do usuário.
A prim eira et apa foi finalizar o wireframe, desenvolvido por dois arquit et os. As especificações t odas eram aprovadas com a equipe de m arket ing (que na em presa é quem cuida do sit e em port uguês e onde est avam alocados os desenvolvedores que cuidariam da im plem ent ação). A equipe de experiência do usuário ainda foi responsável por adapt ar e criar cont eúdo, já que nem t odos os t ext os do sit e em port uguês seriam ut ilizados na versão int ernacional. Foi necessário ainda coordenar com o m arket ing o envio para a em presa que faria a t radução para inglês e espanhol.
Na época em que o projet o est ava sendo desenvolvido, a equipe est ava com falt a de designers e, ent ão, opt ou-se por cont ar com o t rabalho de um free-lancer. Após um a reunião de briefing, que envolveu experiência do usuário e m arket ing, t odas as ent regas e apr ovações foram feit as por e-mail. Com o t am bém era necessário envolver o m arket ing no processo de aprovação, opt ou-se por fazer reuniões int ernas, em que t odos os envolvidos avaliavam o layout criado pelo designer e, só depois de chegar a um consenso dent ro da em presa, enviar um feedback só para o free-lancer. Com isso, a ideia era evit ar confusão com t roca exagerada de e-mails. O t rabalho do designer começou no fim de m arço e t erm inou apenas no m eio de junho, m as o result ado final foi m uit o bom .
Enquant o o design est ava em andam ent o, a equipe cont inuou t rabalhando com a t radução de cont eúdos junt o ao fornecedor , redação dos cont rat os com o jurídico e o desenvolvim ent o dos m ecanism os int ernos de cont rat ação e cobrança. Foi necessário t raduzir o processo de cont rat ação e im plem ent ar as versões em espanhol e inglês.
chat online, ainda não havia sido t raduzida. Com o ela foi desenvolvida em parceira com um a consult oria, foi preciso envolver os desenvolvedores dessa out ra em presa no levant am ent o dos cont eúdos que precisariam ser enviados para a t radução. Depois disso, eles t iveram de im plem ent ar as versões em inglês e espanhol e t am bém criar a funcionalidade de fuso horário, para que fosse possível at ender client es de out ros países.
Por fim , o sit e foi im plem ent ado pela equipe de desenvolvedores do m arket ing, que t am bém é responsável pelo sit e em port uguês. Após a validação t am bém da equipe de experiência do usuário, o sit e est á previst o para ent rar no ar na últ im a sem ana de julho.
As lições aprendidas foram que, para que um projet o envolvendo m uit as pessoas seja bem sucedido, é necessário um bom alinham ent o ent re as equipes. M elhor do que t rocar dezenas de e-mails, que acabam se t ornando confusos, é m ais fácil aproxim ar as pessoas, com conversas presenciais, para conseguir definições m ais claras. Tam bém foi im port ant e dest acar apenas um a pessoa para negociar com cada um a das part es. Assim , a conversa não se perde, os feedbacks e solicit ações ficam cent ralizados e a com unicação é m ais fácil. No fim das cont as, para fazer um bom design de experiência do usuário é preciso saber lidar com equipes, negociar e com unicar.
6 CRIANDO SOLUÇÕES PRÓPRIAS PARA PULAR PROCESSOS INTERNOS
Grandes em presas são administ radas por diferent es áreas de at ividade e, na m aioria das vezes, a criação de um serviço depende do alinham ent o de diversas equipes (Experiência do usuário, Depart am ent o Jurídico, Tecnologia, M arket ing et c). Os processos de cada equipe são guiados por m et odologias diferent es, acont ecem em ciclos independent es de t em po e de acordo com suas prioridades. Em função dessa dependência, percebem os que, m uit as vezes, soluções sim ples, porém com grande valor agregado, dem oram para chegar at é o client e.
Por exem plo, um a sim ples correção de t ext o no sit e da em presa precisa ser aprovada pela equipe de m arket ing, que é responsável pela página w eb. Se a m et odologia adot ada pela equipe de desenvolvim ent o for o Scrum, é preciso esperar at é o próxim o sprint para que a hist ória ent re na fila e ent ão passe pelo processo de im plem ent ação, t est es de validação e, ent ão, publicação no sit e. Ou seja, pode dem orar m ais de um a sem ana at é que o client e t enha acesso a um a m elhoria.
A seguir são apresent ados casos em que a equipe de experiência do usuário adot ou prát icas e ferram ent as para ent regar soluções rapidam ent e e evit ar a dependência de out ras equipes.
6.1 Repositório de arquivos da loja virtual
Para ent regar m elhorias e novas funcionalidades aos client es da ferram ent a de loja virt ual, a equipe deve seguir um processo longo e rígido, que garant e a qualidade dos serviços. Esse processo envolve: det alham ent o da at ividade com análise de requisit os, concepção dos fluxos, especificação, desenvolvim ent o na m áquina local do program ador, publicação em am bient e de hom ologação de acesso rápido, t est es de QA, ajust es de program ação, nova et apa de QA em am bient e de hom ologação sem elhant e ao am bient e ext erno, regist ro (no serviço cent ral de t ecnologia) das m odificações do sist em a, agendam ent o de at ualização – alinhament o com equipes de adm inist radores de sist em a que publicam os arquivos nos servidores dos client es – e, finalm ent e, processo de at ualização do sistem a.
Quando a equipe de experiência do usuário det ectou que m uit os client es da loja virt ual são carent es de cont eúdo sobre com ércio eletrônico e não t êm conhecim ent o t écnico suficient e para produzir o m at erial de personalização e divulgação da própria loja, o cam inho para t ent ar resolver o problem a foi fácil de encont rar. Porém não seria t ão rápido realizá-lo, em função dos pr ocessos e dependências.
Com o arquit et os e designers da equipe t êm facilidade para criar t ut oriais de ajuda, dar dicas e criar peças gráficas, poderíam os fornecer t emplat es de banners, e-m ail m arket ing, im agens para personalizar t emplat es da ferram ent a e t ut oriais diversos com dicas. Porém se o veículo de com unicação desse cont eúdo fosse o sit e inst it ucional da em presa ou a área adm inist rat iva da ferram ent a, cairíam os na dependência das equipes de t ecnologia e m arket ing.
A solução foi criar um sit e independent e, sem com prom isso com qualquer plano da ferram ent a ou dependência de funcionalidades do sistem a. O sit e foi program ado e é m ant ido pelos próprios arquit et os da equipe durant e os int ervalos livres. E a hospedagem foi fornecida pelo gest or de experiência do usuário. A única ligação com a ferram ent a acont ece at ravés de avisos no painel de adm inist ração, que são encaixados junt o com out ros a cada deploy. Out ro canal de com unicação é o blog inst it ucional, onde são com ent adas as novas funcionalidades na ferram ent a e t am bém link para fazer o dow nload dos m at eriais de apoio.
Figura 6 - Banner de Dia das M ães disponibilizado no sit e program ado pela equipe de experiência do usuário
Font e: dados de trabalho dos aut ores na Locaw eb
acom panham os as lojas ativas para verificar se os client es ut ilizam os mat eriais disponibilizados, e de que form a. Nos dois últim os lançam ent os, vim os que, no dia seguint e à publicação, diversas lojas já est avam personalizadas com as im agens fornecidas. Na prim eira sem ana após a publicação do post com o link, foram feit os t rês m il downloads de cont eúdo.
7 FALTA DE TEM PO PARA PESQUISA
A lit erat ura de arquit et ura da inform ação e experiência do usuário sem pre reforça a im port ância de realizar pesquisa com usuários ant es e durant e o desenvolvim ent o de produt os. Kuniavsky (2003), por exem plo, dedicou um livro int eiro para falar sobre a im port ância de pesquisar para ent ender o usuário e com o fazer isso. " Descobrir quem são seus client es, o que eles querem e o que eles precisam é o pont o de part ida para descobrir com o ent regar isso a eles" .2
Apesar de t er consciência da im port ância de realizar esse t ipo de pesquisa, nem sem pre a realidade do m ercado de t rabalho perm it e que seja dedicado t em po para fazer t est es de usabilidade, grupos focais, card sort ing ou pesquisa et nográfica. O risco de seguir com um projet o sem ent ender quem é o público alvo é cair no que Cooper (2007, p. 79) cham a de " usuário elást ico" . Para o aut or, quando não se faz um est udo para a criação de personas, o em prego da palavra " usuário" pode se t ornar perigoso, já que cada m em bro da equipe t em um a visão própria de quem é essa pessoa. " Quando chega a hora de t om ar decisões sobre produt os, esse ‘usuário’ se t orna elást ico, convenient em ent e se dobrando e est icando para se adequar às opiniões e pressuposições de quem est á falando” 3.
A quest ão para a equipe de experiência do usuário da em presa é conseguir ent ender quem é, de fat o, o usuário dos produt os que desenvolve, m esm o sem t em po para conseguir fazer t est es clássicos. Em alguns casos, é possível cont ar com um a consult oria para ajudar no t rabalho, fazendo t est es de usabilidade e ent revist as. M as, quando não há dinheiro ou t em po para isso, é necessário recorrer a out ras alt ernat ivas.
Com o est a equipe de experiência do usuário t rabalha com produt os desenvolvidos dent ro da própria em presa, t em algum as vant agens. Um a delas é t er acesso ao feedback dos client es, poder ent rar em cont at o com eles e t er ferram ent as de m onit oração para ent ender com o os produt os est ão sendo usados. A área de SaaS (ou Soft ware as a Service), ut iliza m et odologias de lean development , que prega a evolução const ant e do produt o, sem pre levando em cont a a opinião dos client es para decidir quais serão os próxim os passos ou quais m elhorias devem ser feit as. Com gerent es de produt o e desenvolvedores preocupados em ent ender as necessidades e problem as dos client es, fica m ais fácil para a equipe de experiência do usuário t am bém colher inform ações sobre os usuários para m elhorar a int eração deles com os produt os.
A seguir, é det alhada a m aneira ut ilizada pela equipe para conhecer os usuários e os problem as de usabilidade sem t er de recorrer a salas de espelho ou grupos focais.
7.1 Equipe dedicada a ouvir o cliente
M esm o disponibilizando m aneiras para que os clientes possam se com unicar com a em presa, nem t odos os usuários se sent em m ot ivados a dedicar seu t em po a escrever um a m ensagem , falar ao t elefone ou enviar um e-mail. Ainda assim , há client es que se sent em t ão
2
Do original: Finding out w ho your cust om ers are, w hat t hey w ant , and w hat t hey need is t he st art of figuring out how t o give it t o t hem.
3
frust rados ou t ão felizes com a ferram ent a que querem cont ribuir com suas opiniões, reclam ações, sugest ões ou pedidos. Para a equipe de experiência do usuário, esse t ipo de feedback ajuda a det ect ar pr oblem as de usabilidade nas ferram ent as, descobrir cenários de uso e ent ender quais são as necessidades dos usuários.
A em presa abordada nest e art igo possuiu vários canais para que os client es deem seu feedback sobre os produt os. No próprio sit e inst it ucional há um link cham ado " Sugest ões" . Quando clica nele, o usuário é redirecionado para a ferram ent a User Voice. Nela, as pessoas podem sugerir novas funcionalidades para cada um dos produt os da em presa e t am bém vot ar em sugest ões dadas por out ras pessoas. Já na área de adm inist ração de t odos os produt os de SaaS t am bém há um link de " Sugest ões" , m as que leva para um a out ra ferram ent a, desenvolvida pela própria em presa. At ravés desse link, o usuário t em acesso a um form ulário, em que pode escrever suas sugest ões ou opiniões sobre o uso de um produt o específico. Para os adm inist radores, a m ensagem chega acom panhada do nom e e w ireframe do usuário na ferram ent a. At ravés desses dois canais de feedback, a equipe de experiência do usuário consegue ent ender com o é que os usuários ut ilizam cada um dos produt os (já que os com ent ários m uit as vezes vêm acom panhados de descrições de cenários de uso) e t am bém det ect ar problem as de usabilidade. Houve casos de feedbacks em que os client es diziam sent ir falt a de um a funcionalidade que já havia sido im plement ada, deixando claro que o acesso ao cont eúdo desejado não era fácil ou int uit ivo.
Out ra vant agem de t rabalhar na em presa que desenvolve e dá suport e a seus produt os é a possibilidade de est ar em cont at o com as equipes de suport e e com ercial. Os profissionais de experiência do usuário t êm a possibilidade de conversar com out ras áreas para ent ender quais são as dúvidas e problem as dos client es. Quando algum a funcionalidade ou int eração causa m uit as dúvidas, a equipe de suport e avisa que est ão sendo abert os m uit os cham ados sobre t al assunt o e é possível t rabalhar im ediat am ent e em um a solução para o pr oblem a. Conversando com a equipe com ercial – ou m esm o t endo acesso às conversas realizadas at ravés do chat online – é possível descobrir quais são as dúvidas dos usuários quando ent ram no sit e da em presa e, com isso, pensar em m aneiras de m elhorar a arquit et ura e o cont eúdo das páginas.
Quando é necessário colher inform ações dos usuários, a equipe de experiência do usuário cont a com o banco de dados de t odos os client es da em presa. É possível pesquisar quais usuários abriram cham ados, quais usam um a ou out ra funcionalidade e, ent ão, ent rar em cont at o para ent revist as presenciais ou por t elefone. Tam bém é prát ica usual criar quest ionários online, que podem ser colocados na interface de adm inist ração ou enviados por e-m ail para a base de client es.
Figura 7 - Sugest ões e opiniões de client es da plat aform a de help desk de um a int erface criada pela Locaw eb
Font e: dados de trabalho dos aut ores na Locaw eb
Apesar de não seguir o prot ocolo de pesquisa formal com os usuários, a equipe de experiência do usuário est á sem pre em cont at o com os client es de suas ferram ent as. Não são levant adas est at íst icas ou m ét ricas reais de uso, m as o m at erial ext raído de pesquisas qualit at ivas é m uit o im port ant e para projet ar m elhores int erfaces. Est ar sem pre abert o a ouvir o que os usuários t êm a dizer faz com que os designers de experiência do usuário saibam quem é o público com o qual est ão falando.
8 COM O ENCONTRAR UM A SOLUÇÃO QUANDO SEU PÚBLICO É TODO M UNDO
Para conseguir desenvolver um bom produt o, é necessário conhecer bem o público-alvo. Exist em várias t écnicas com o segm ent ação de usuário, definição de papéis ou criação de personas para conseguir det erminar quem é o público e, ent ão, criar um a est rat égia para t ornar a experiência desse usuário a m ais satisfat ória possível. Em um projet o direcionado a um público específico, o núm ero de personas ou papéis é pequeno. M as, em sist em as com plexos, esse núm ero pode ser m uit o grande. M as, o fat o é que quant o m ais t ipos diferent es de usuários exist irem para um a ferram enta, m ais com plexo é conseguir chegar a um a solução que at enda bem a t odos.
Goodw in (2009, p. 239) afirm a que, m esm o em projetos que necessit am de 25 pessoas ou m ais, o ideal é que não se t rabalhe com t odas ao m esm o t em po. " ... com o o t rabalho de design norm alm ent e foca em um papel por vez, não é necessário se preocupar com m ais do que algum as (personas) de um a vez"4. Já Garret (2003, p. 50) levant a a quest ão de que não é possível at ender a m ais de um t ipo de usuário com um a única solução e apresent a duas m aneiras de lidar com o problem a. " Nossas opções são focar em um segm ent o de usuário e excluir out ro, ou for necer duas form as diferent es para os usuários realizarem a m esm a t arefa"5.
M as, o que fazer quando não é possível focar só em um grupo ou tipo de usuário? Quando se lida com soluções de SaaS ou m esm o com um port al de int ernet ou int erface de e-m ail, é necessário at ender o e-m aior núe-m ero de pessoas possível de ue-m a só vez. Afinal, excluir um t ipo de usuário pode significar a dim inuição do núm ero de client es da ferram ent a e, consequent em ent e, m enor lucro para a em presa.
4
Do original: “ […] because t he design work generally focuses on one role at a time, you wouldn't have to w orry about more than a handful of t hose at once.“
5
A equipe de experiência do usuário da em presa de hospedagem precisa lidar com um a base de 300 m il client es de diferent es t ipos. Alguns são desenvolvedores, out ros profissionais liberais e m uit os leigos que só querem t er um a loja virt ual ou ut ilizar um a solução de t elefonia VOIP. Um layout que at enda a um público t ão diverso nunca é o ideal, m as aqui é apresent ado um caso de um a ferram ent a que foi desenhada para ser flexível e at ender a diversos tipos de negócio.
8.1 Help desk para múltiplos cenários de uso
Em m eados de 2010, a em presa lançou um a solução de help desk online com a int enção de oferecer um a ferram ent a sim ples, m as que pudesse ser ut ilizada por em presas de t odos os t am anhos. A ideia é que ela fosse neut ra, para conseguir se adequar a qualquer t ipo de negócipo. Para a equipe de experiência do usuário a quest ão cent ral era não t er um usuário padrão com o m odelo na hora de criar os w ireframes.
A opção foi criar uma int erface de cores neut ras e funcionalidades que não rem et essem a um negócio específico. Os cam pos para cadast ro de client es e ticket s eram apenas os essenciais (com o nom e, em presa e t elefone), m as com cam pos de descrição e com ent ários int ernos que pudessem ser usados para com plem ent ar essas informações.
At ravés do feedback dos client es e de ent revist as com usuários da ferram ent a, a equipe do produt o (incluindo experiência do usuário), descobriu que o help desk est ava sendo ut ilizado por em presas m uit o diferent es e em casos que nem haviam sido im aginados durant e a concepção do produt o. Algum as em presas ut ilizam a ferram ent a para cont role de dem andas int ernas – com o solicit ação de m anut enção de equipam ent os ou com pra de m at eriais. Tam bém há casos de assist ências t écnicas em que o help desk serve para que os client es acom panhem o andam ent o do consert o do equipam ent o. Ou em presas em que t odos os at endim ent os a client es são cadast rados e acom panhados pela ferram ent a. E ainda exist em agências em que as solicit ações de serviços são feit as pelo help desk.
O t am anho das em presas t am bém varia m uit o. Exist em clientes que cont rat am o plano m ais básico, em que só exist e um at endent e. É o caso de um a em presa de consult oria em que o help desk é ut ilizado para acom panhar cham ados abert os por client es. Apesar de a em presa cont ar com 30 funcionários, com o há apenas um a pessoa que faz o suport e, só ela ut iliza a ferram ent a. Ao mesm o t em po, um dos client es é um sit e de e-commerce de grande port e, que possui m ais de 60 agent es. Ela t am bém ut iliza a ferram ent a com o cont role int erno de solicit ações, m as possui m uit os at endent es e t odos eles precisam int eragir com os t icket s.
Quando a ferram ent a já est ava sendo ut ilizada havia algum t em po, com eçaram a surgir os feedbacks de client es, pedindo para que o produt o t ivesse features que os ajudaria em seus negócios. Com o o produt o ainda est á em desenvolvim ent o, o gerent e de produt o sem pre cat aloga os pedidos e acaba priorizando o desenvolvim ent o de novas funcionalidades de acordo com a recorrência de feedbacks a esse respeit o. Porém , ainda é necessário levar em cont a que algum as funcionalidades que ajudam um t ipo específico de uso, podem não ser út eis ou at é prejudicar out ros cenários. Por exemplo, fazer com que apenas at endent es possam encerrar um t icket .
Nesse cenário, a equipe de experiência do usuário precisa sem pre pensar nos diferent es cenários de uso e nas diferent es em presas que ut ilizam essa solução. Em geral, a m elhor m aneira é t ornar a ferram ent a o m ais flexível e cust om izável possível. Se um usuário quer que client es não possam abrir ou encerrar t icket s, essa funcionalidade pode ser im plem ent ada com o um a opção – o adm inist rador t em de escolher se quer ou não que seus client es est ejam apt os a realizar essas ações.
do usuário t em a liberdade para ent rar em cont at o com os usuários que pediram a feat ure durant e ent revist as ou pelas ferram ent as de feedback. Conversando m elhor sobre as necessidades dessas pessoas, é possível decidir qual a m elhor solução para at ender aos diferent es cenários.
Ainda que o público a quem se dest ina um produto seja m uit o am plo, sem pre é possível est ar em cont at o com suas opiniões e saber do que precisam para conseguir desenvolver um bom design cent rado no usuário. Assim , é im port ant e est ar sem pre at ent o aos feedbacks, pesquisar qual é o cenário de uso de cada um e ent ender com o eles t rabalham , quais são suas necessidades e com o podem os fazer para que a ferram ent a se adapt e para at ender bem ao m aior núm ero de casos possíveis.
9 COM O GARANTIR QUE O PRODUTO SEGUE AS ESPECIFICAÇÕES DE EXPERIÊNCIA DO USUÁRIO
Um a das premissas para ent regar um a boa docum ent ação de experiência do usuário para a im plem ent ação é que ela seja com plet a, cont em plando t odos os possíveis casos de uso e erros, e t am bém clara, para que não haja nenhum a dúvida na hora do desenvolviment o. " Com um a especificação com plet a em m ãos, os engenheiros não devem t er de adivinhar nada sobre a aparência ou com port am ent o do produt o"6 (GOODWIN, 2009, p. 572).
Apesar dos aut ores da área abordarem a quest ão de t er um a boa especificação, é difícil encont rar referências sobre com o realizar um processo de QA (do inglês Qualit y Assurance). Talvez por que, t radicionalm ent e, esse processo não é realizado por arquit et os da inform ação ou designers de int eração, m as pelos próprios desenvolvedores.
Ent ret ant o, a realidade do dia-a-dia no m ercado de t rabalho é que, m uit as vezes, o que foi especificado pela equipe de experiência do usuário acaba não sendo im plem ent ado, seja por dificuldades t écnicas ou falhas de int erpret ação das especificações. E, quando o produt o chega na fase de validação, o QA, que t am bém é desenvolvedor, acaba negligenciando as quest ões de layout e usabilidade. Nessa sit uação, o t rabalho de arquit et ura da inform ação pode ser desperdiçado, já que não adiant a propor a m elhor solução se na hora do desenvolvim ent o ela sim plesm ent e for ignorada.
Um a das soluções para esse problem a é o cont at o const ant e ent re a equipe de experiência do usuário e os desenvolvedores. Dessa m aneira, nada que est á no w ireframe é m odificado sem que um arquit et o de inform ação seja consult ado. Os desenvolvedores precisam t er consciência da im port ância de ent regar um produt o com boa usabilidade e os profissionais de experiência do usuário t êm de saber conversar e negociar m udanças com as out ras equipes.
Tam bém é im port ant e que os responsáveis pelo QA est ejam int erados da docum ent ação de experiência do usuário. Um bom QA se preocupa não só com a qualidade do código, m as com o produt o com o um t odo e deve sem pre verificar se a im plem ent ação est á de acordo com as especificações de experiência do usuário.
M esm o com t udo isso, em alguns casos é im port ant e que a equipe de experiência do usuário faça part e do processo de QA. Designers de experiência do usuário podem fazer t est es explorat órios para assegurar que t odos os casos de uso foram cont em plados e t am bém para garant ir que o layout est á de acordo com o especificado.
O exem plo a seguir cont a com o o envolvim ent o de experiência do usuário com o processo de QA ajudou a m elhorar a qualidade do produt o e a dim inuir o núm ero de bugs.
6
9.1 Experiência do usuário participando do QA da loja virtual
At é o com eço de 2011, a loja virt ual possuía um desenvolvedor responsável pelo QA do produt o. Além de passar pela avaliação desse profissional, t odas as hist órias t inham um a aprovação final do PO ant es de serem colocadas no ar. Ainda assim , houve períodos em que m uit os bugs eram encont rados pelos client es, o que significava que a equipe não est ava fazendo um bom t rabalho de cont r ole de qualidade.
Para t ent ar dim inuir o núm ero de problemas com o produt o, desenvolvedores, PO e experiência do usuário t om aram diversas ações. Para a equipe de experiência do usuário foi necessário alt erar o fluxo de t rabalho, envolvendo m ais os desenvolvedores. A part ir de ent ão, ant es de t erm inar de especificar um a hist ória, os arquit et os da inform ação se reúnem com desenvolvedores e PO para discut ir as ideias. Nesse m om ent o, é feit a a validação do que é possível ou viável para ser im plement ado e os out ros envolvidos t am bém ajudam experiência do usuário a encont rar problem as, inconsist ências ou com port am ent o que não est ão m uit o int uit ivos.
Já durant e o processo de especificação, é im port ant e descrever os com port am ent os em det alhes para que não haja dúvidas. É m uit o com plicado conseguir fazer um a descrição perfeit a, sem m argem para esqueciment o e dúvidas, o que pode t razer problem as. M as, com o nest e caso experiência do usuário e desenvolvedores est ão próxim os fisicam ent e, dúvidas podem ser esclarecidas a qualquer m om ent o.
Tam bém ent rou para a rot ina de experiência do usuário fazer part e do processo de QA, não só para garant ir que o que foi especificado de fat o foi im plem ent ado, m as t am bém para t ent ar prever o m aior núm ero possível de sit uações e validar o funcionam ent o do sist em a nesses casos. O processo de hom ologação acont ece em duas et apas. Após a im plem ent ação, os desenvolvedores colocam a nova funcionalidade (ou produt o) em um am bient e que sim ula o de produção, m as fica arm azenado localm ent e. Est e é o prim eiro m om ent o em que a equipe de experiência do usuário faz t est es explorat órios na ferram ent a. Em vez de fazer um a list a de problem as, que só é repassada no fim do processo, as não-conform idades são com unicadas im ediat am ent e aos desenvolvedores, para que sejam corrigidas o m ais rápido possível. Cada correção é colocada no am bient e de hom ologação e a equipe de experiência do usuário t em de t est ar e aprovar.
A seguir, a funcionalidade (ou produt o) vai para um segundo am bient e de hom ologação, dest a vez um a cópia m uit o próxim a do am bient e de produção. Nesse m om ent o é possível t est ar coisas com o int egração com out ros sist em as (com o Correios ou meios de pagam ent o) e m ais um a vez a hist ória é t est ada levando-se em cont a t odos os possíveis cenários que a equipe consegue im aginar. Para facilit ar os t est es e garant ir que nada escape à m em ória, os arquit et os de inform ação elaboram um r ot eiro de t est es. Nele, são det alhados os com port am ent os esperados e qual deve ser o procedim ent o para chegar at é eles. Quando a hist ória est á nesse am bient e, ela t am bém é t est ada por um Jovem Aprendiz (cont rat ado para ajudar nos t est es explorat órios), pelo PO e t am bém pela equipe de suport e da em presa. O rot eiro é repassado para t odas essas pessoas, que acabam encont rando out ros problem as que nem foram im aginados por experiência do usuário.
Só depois de ser explorada por t odas essas pessoas e por t er recebido a aprovação da equipe de experiência do usuário é que um a hist ória é colocada em produção, ou seja, chega at é os client es. Com isso, o processo de aprovação da loja virt ual se t ornou m ais ext enso, porém , o núm ero de bugs dim inuiu e o produt o ganhou em qualidade.
diferent es problem as. Quando m ais se invest e em um a boa hom ologação, o produt o chega com m ais qualidade at é o client e final.
HOW TO DO A GOOD USER EXPERIENCE JOB BESIDES ALL LIM ITATIONS
Abstract
In the everyday routine of t he labour market it is not alw ays possible t o follow best pract ices and met hodologies. In t his art icle, user experience designers discuss about how t o escape limit ations (of time, t echnology and people) and be able to design good int erfaces. As t he authors of t he paper w ork in an Int ernet infrast ruct ure company, using real cases t o t heir daily work t o illust rate problems and solut ions. Thus, int erfaces are examples of hiring and domain hosting plat form shop, tool and w ebsit e help desk, w hile real cases to illust rat e the met hodologies adopt ed by the t eam.
Keyw ords: Usabilit y. User Experience. M ethodologies. Labour M arket.
Art igo recebido em 20/ 08/ 2011 e aceit o para publicação em 30/ 09/ 2011
REFERÊNCIAS
BROWN, Tim . Design thinking. Rio de Janeiro: Edit ora Cam pus, 2010.
COOPER, Alan; REIM ANN, Robert ; CRONIN, David. About Face 3. Indiana: Wiley, 2007.
GARRET, Jesse Jam es. The elements of user experience. [S.l]: AIGA, 2003.
GOODWIN, Kim . Designing for the digital age. Indiana: Wiley, 2009.
KUNIAVSKY, M ike. Observing the user experience. EUA: M organ Kaum ann, 2003.
