Giselle Rossi Figueiredo César de Araújo
giselle.rossi@openbossa.org giselle.rossi@gmail.com
Publicitária e jornalista
Centro Universitário de Belo Horizonte
Designer de Interação do INdT – Instituto Nokia de Tecnologia – www.indt.org

Tâmara Baia
tamara.baia@openbossa.org tâmara.baia@gmail.com
Designer UFPE (Universidade Federal de Pernambuco)
Designer de Interação do INdT – Instituto Nokia de Tecnologia- www.indt.org

Sumário

O objetivo desde artigo é a troca de experiência entre profissionais da área de UX, bem como o compartilhamento de ideias e vivências recentes adquiridas por nós em um instituto de pesquisa em tecnologia de softwares para devices móveis. Para isso vamos apresentar dois estudos de caso e algumas boas práticas do processo criativo da nossa equipe de designers do INdT.

Palavras-chave

User experience, devices móveis, estudo de caso, SCRUM, boas práticas

1. Introdução

Dada a crescente demanda por projetos orientados a interação com usuários, em que as formas de interação são cada vez mais diversas, inovadoras e concomitantes, perfis multidisciplinares tornam-se indispensáveis na criação de novos conceitos e interfaces. Assim, em uma equipe de Experiência do Usuário é essencial ter pessoas com conhecimento nas diversas disciplinas que compõe a ciência de interação humano-computador, como Ergonomia, Arquitetura da Informação, Usabilidade e Design Gráfico. E cada vez mais valoriza-se e necessita-se da composição de times com profissionais de formação variada, vindos das mais diversas áreas acadêmicas e profissionais.

O INdT é uma empresa não governamental, baseada na lei de informática brasileira, focada no desenvolvimento de soluções tecnológicas inovadoras na área de mobile. Atuando em um mercado altamente competitivo onde novos produtos e serviços tecnológicos são lançados a todo instante, está se destacando através de seu time de pesquisadores multidisciplinares e seu processo de desenvolvimento de novos conceitos.

O time de pesquisadores, que antes era restrito a desenvolvedores com formação em áreas da tecnologia, se ampliou agregando profissionais multidisciplinares, conhecidos por designers de interação. Trata-se da nossa equipe de UX (Experiência do Usuário), com conhecimento em interação humano-computador, design gráfico, interface do usuário, ergonomia, arquitetura de informação, entre outros. Esses novos profissionais com formação em áreas como design, comunicação social e arquitetura, que em sua maior parte começaram sua carreira em projetos web e agências on-line, foram requisitados por possuírem conhecimento e habilidades essenciais para o desenvolvimento de conceito de projetos de UX, independente do tipo de interação que o produto proporcionará ao usuário. E assim surgiu nosso primeiro desafio: abandonar os padrões e conceitos utilizados no dia-a-dia dos projetos exclusivos para internet e abrir a cabeça para formas de interação que até então experimentávamos apenas como usuários e não como desenvolvedores.

Dessa forma, podemos considerar que outro objetivo deste artigo é chamar atenção dos profissionais da área para a eminente necessidade de se tornar mais flexível, sendo capaz de derrubar as barreiras e limitações impostas por padrões aprendidos. É preciso ir em busca do conhecimento necessário para atender a crescente demanda por mobile sites, softwares e aplicativos para devices móveis, lembrando que da categoria de devices móveis fazem parte não apenas celulares e smartphones, mas também netbooks, internet tablets, e-books, mídia players dentre outros tantos.

Por exemplo, ao criar um Mobile Site ou um aplicativo para celular, não se pode deixar de considerar as diversidades das possíveis interfaces. Os teclados podem ser numéricos ou QWERTY, físicos ou touchscreen. Pode haver softkeys back e options ou não, e quando houver são diferentes os posicionamentos. O que antes era feito para resolução de 1024X768 pixels não caberá na tela que, por sua vez, também oferece diferentes resoluções. Enfim, existe uma série de fatores envolvidos e pode-se dizer inclusive que a falta de padronização de celulares e smartphones é um dos fatores que compromete a boa usabilidade destes, experiência considerada pelo pesquisador em usabilidade Jakob Nielsen “miserable”.

The Mobile User Experience Is Miserable
The phrase “mobile usability” is pretty much an oxymoron. It’s neither easy nor pleasant to use the Web on mobile devices. Observing user suffering during our sessions reminded us of the very first usability studies we did with traditional websites in 1994. It was that bad.

Vale a pena contar a experiência de uma de nós no primeiro projeto no INdT. Tratava-se de um produto que integrava celular e televisão. O usuário usava o celular como controle remoto e o feedback das ações era todo na televisão. Ou seja, tudo que havia sido estudado e aprendido na primeira semana de trabalho sobre padrões de navegação dos celulares da série 60 da Nokia já não seriam aplicados no primeiro projeto. E para a necessidade imediata do novo produto não existia, qualquer informação em livro, manual ou pesquisa. E assim surgiram várias dúvidas: O que aconteceria se nesse meio tempo alguém ligasse pra ele? E se o irmão dele também tentasse controlar o mesmo software com o seu Nokia? E se a bateria do celular acabasse? As soluções encontradas para este projeto especificamente ainda não podemos apresentar, mas vamos falar de outros cases interessantes.

2. Case SmartHome

Smart Home é um software de controle da casa à distância em que pode-se apagar e acender luzes, trancar e destrancar portas, visualizar e gravar imagens de webcams previamente instaladas, bem como verificar e alterar a temperatura de cada cômodo, dentre outras funcionalidades. Para ser realmente funcional este aplicativo deveria ser acessível não só através dos celulares Nokia mas também de qualquer outro celular, bem como através de uma página da internet convencional, o que supriria o hábito de muitos de resolver tudo pelo computador do trabalho. O que seria um grande desafio, desenvolver um software que permitisse diferentes meios de interação, foi resolvido ao se decidir fazer 4 diferentes versões, abrangendo assim os principais meios do público a que se destinava aquele produto.

A versão considerada mais importante, onde concentramos mais esforços e foi ponto de partida para as demais foi a desenvolvida para os celulares Nokia da Série 60. Veja abaixo o layout de algumas telas da aplicação de controle de luzes/interruptores da casa.

Figura 1 – SmartHome versão S60 – layout da aplicação de controle de interruptores/luzes

A primeira tela apresenta uma lista de interruptores instalados em um dado cômodo da casa, e o usuário usa as setas verticais do celular, as direcionais up/down, para percorrer a lista e então selecionar um item. Para os interruptores que não permitem alteração de intensidade da luz, basta pressionar a tecla select/enter para ligar ou desligar a respectiva luz, a exemplo da primeira opção da lista. Já para os interruptores que permitem variação de intensidade, a seleção abre uma segunda tela que permite aumento e diminuição usando-se os direcionais up/down. Na figura abaixo pode-se ver o taskflow dessa aplicação, com destaque para a necessidade de descrever, para cada tela, todas as possíveis interações permitidas pelas teclas/controles do celular, o que reforça a necessidade de atenção exigida por um software desenvolvido para devices móveis. Ou seja, deve-se sempre saber em qual device o usuário vai usar um dado software.

Figura 2 – Taskflow para versão S60 do SmartHome – Controle de luzes/interruptores

Além da série 60 foi criada uma versão especial para o internet tablet N800 da Nokia, pensando em um público específico viciado em tecnologia. Este possui interface touch screen e visualização em landscape. Como pode ser visto nas figuras 3 e 4, a forma de interação e a arquitetura sofreram mudanças consideráveis.

1. Home (applications grid)	1.1 Switch control (list of switches)

Figura 3 – versão internet tablet N800 para o SmartHome – layout da aplicação de controle de luzes/interruptores

Figura 4 – Taskflow da versão internet tablet N800 para o SmartHome – aplicação de controle de luzes/interruptores

Enquanto que na versão S60, para celular Nokia com teclado, havia a necessidade de documentar o comportamento do uso de cada tecla, na versão do device N800 tudo parece mais simples e direto através do toque. A interface também não requer foco para demonstrar a seleção de um item e todos os interruptores podem ser renomeados de uma só vez através do acionamento do botão “Edit” no canto inferior direito, o que na versão anterior só pode ser feito de um em um através da abertura das opções do menu contextual.

Já a versão web mobile (figura 5) pode ser considerada a que permite uma experiência menos interessante, principalmente por exigir mais toques para se navegar até um determinado ponto da tela.

1. Home (applications grid)		1.1 Switch control (list of switches)

Figura 5 – Layout da versão Web Mobile para o SmartHome – aplicação de controle de luzes/interruptores

Figura 6 – Taskflow da versão Web Mobile para o SmartHome – aplicação de controle de luzes/interruptores

Ainda sobre a navegação padrão item a item da página de web mobile, é importante considerar este um fator de alta relevância quando no desenvolvimento de um Mobile Site. No exemplo abaixo (figura 7) está o comparativo entre dois estudos de tela. A primeira opção pensada, padrão web desktop com botão “go” após seleção de um item do drop-list, requer muito mais toques até que se alcance o botão “go” e então de conclua a ação de selecionar um item, em comparação a segunda opção que não requer o pressionamento do botão “go”. O que na web representaria apenas mais um clique, que pode ser escolhido como garantia e certeza da seleção, aqui representa muitos toques no direcional para direita.

Figura 7 – Comparativo de telas com e sem o botão “GO” para confirmação de seleção de um item do drop-list.

Já a versão web para Desktop foi considerada pela equipe a que exigiu menos preocupações em temos de arquitetura de informação, tanto pelo fato da pouca limitação de espaço quanto pela maior familiaridade do usuário com essa forma de interação. Ainda assim escolhemos abrir mão da liberdade de recriar a arquitetura da nova versão, acreditando que essa decisão contribuiria ainda mais com a boa experiência e usabilidade, uma vez que aproveita o aprendizado do usuário já acostumado com a versão S60 do software.

1. Home (applications grid)

1.3 Temperature application

Figura 8 – Layout da versão Web Desktop para o SmartHome

Um exemplo mal sucedido de adaptação de uma interface de desktop para mobile é o Windows Mobile usado no aparelho da marca HTC. Nas primeira versão do software um erro grave foi o posicionamento do botão fechar no canto superior direito. Apesar de ser o posicionamento padrão dos browsers, na versão mobile não funcionou muito bem. Em teste informal dentro do nosso instituto de pesquisa, 100% da amostra de 10 usuários não foi capaz de sair da aplicação por não encontrar o botão fechar.

Figura 9 – Tela do aparelho HTC com Windows mobile – o botão fechar, única forma de air da aplicação, está “escondido” no canto superior direito.

3. Case Carman

Outro projeto que foi feito para diferentes aparelhos e portanto precisou de diferentes abordagens foi o Carman. O software é um simples computador de bordo que oferece algumas funções de monitoração do carro e também GPS (apenas na versão touchscreen). A versão touchscreen permite que o usuário tenha acesso a sensores instalados dentro de seu próprio carro, como por exemplo a temperatura do motor, e monitore suas respostas, aplique testes, guarde o histórico e escolha temas para sua interface, alem de compartilhar todas essas informações com algum amigo pela internet.

Figura 10 – Gauges do Carman touchscreen

Figura 12 – GPS do Carman touchscreen

A versão para celular é bem mais simples, pela natureza do aparelho e também pelo tamanho da tela para exibir tamanha quantidade de informações. Nessa versão é possível monitorar os mesmos sensores, executar teste de velocidade e guardar estas informações para posterior visualização. A exibição das informações é completamente diferente: textos ou gráficos simples.

Figura 13 – Taskflow do Carman para celulares série 40 e 60

Este projeto começou num momento em que o INdT tinha um foco bem maior em desenvolvimento de software. A primeira versão do Carman na verdade eram duas versões com formas completamente diferentes de visualização: uma com foco em mostrar números e gráficos, pensada para atender a necessidade de um profissional da área de mecânica; e outra com maior apelo visual que simulava um painel de carro, demonstrando vários sensores, pensada para o usuário comum.

Figura 14 – interface Hildon GTK

A primeira é construída dentro do sistema do Tablet, sendo que algumas widgets foram criadas para o Carman. A barra do lado esquerdo e no topo da tela são parte do sistema operacional do aparelho, o Maemo, e podem ser suprimidas através do comando de fullscreen. Vê-se que a interação acontece através de áreas clicáveis pequenas, fazendo uso da caneta.

Figura 15 – Interface Python SDL, chamada de Carman RichView

Já a segunda era uma aplicação fullscreen e teve todos os elementos gráficos criados pela equipe de design, o que permitiu maior liberdade na definição das áreas de clicáveis, além de não exibir as barras do sistema operacional, para ganhar espaço na tela.

Ambas eram feitas para os Internet Tablets da Nokia possuem uma tela um pouco maior que um cartão de crédito. Com tamanha restrição de espaço, precisávamos de estudos sobre o tamanho dos elementos e da hit area (que pode ser maior que o elemento).

A versão que perdurou foi a que tinha maior apelo visual e maior preocupação com a experiência do usuário. Ela foi sendo aprimorada. Na segunda versão do software, adaptamos o modelo de navegação do Canola, um Media Center, também para tablets, como vemos abaixo.

Figura 16 – Tela da aplicação Canola

O Canola começou a ser planejado no final de 2005, ou seja, antes do lançamento do iPhone, que foi o grande marco das interfaces touchscreen. Até então, as interfaces touchscreen eram bastante voltadas ao uso com stylus. O próprio Internet Tablet era feito para uso com a caneta. Por isso, desde o início estávamos empenhados em explorar a criação de interfaces que fossem intuitivas e naturais de usar, sem caneta, mas com as mãos. Porém, sem muitas fontes, que não fossem os outros aparelhos touchscreen até então lançados e o nosso próprio bom senso.

Foi então que elaboramos o modelo de navegação da segunda versão do Carman, adaptado ao modelo do Canola, como vemos abaixo, para iterar o modelo que havíamos proposto.

Figura 17 – Telas do Carman, adaptadas do modelo de navegação do software Canola

A UI parecia atender aos requisitos, visto que aproveitamos bastante a área da tela para exibir os displays de carro. A navegação ficou localizada nas grandes áreas destacadas em branco, mas sem indicadores visuais de onde estavam os controles. Apenas uma barra foi acrescentada na parte inferior da tela para indicar o ponto em que o usuário se encontra na navegação. Este elemento não foi feito para responder como um botão, era apenas um indicador.

Nesta etapa do desenvolvimento, supomos que esta navegação seria facilmente descoberta pelos usuários e decidimos explorar esta possibilidade. Mas como testar o modelo de navegação proposto? Não tínhamos usuários reais do aparelho no Brasil, pessoas com alguma experiência no uso das tablets que pudéssemos recrutar para validar algum conceito, pois os aparelhos ainda não haviam sido comercializados aqui. A falta de familiaridade com o device talvez apontasse outros problemas, mas não exatamente os que um usuário habituado teria. Por outro lado, a dúvida sobre a clareza da navegação era preocupante. Optamos por fazer um estudo informal com 5 pessoas apenas para guiar os passos seguintes quanto ao modelo de navegação.

Foi uma feliz escolha, pois este breve estudo mostrou que a barra inferior que usamos parecia para todos os usuários uma scrollbar. Todos tentaram arrastá-la, ainda que com dificuldade, pois ela não era suficientemente confortável para o uso touchscreen. Foi preciso demonstrar o uso para que eles pudessem entender. A partir daí sim, não houve mais erros nem dúvidas. Isso nos fez pensar sobre a curva de aprendizado dos novos modelos de interação e nos fez perseguir um modelo que fosse intuitivo e fácil de lembrar.

Uma forma que conseguimos de captar respostas dos usuários foi pedir a eles, depois do lançamento, que filmassem um uso da aplicação e nos enviassem ou mandassem para o Youtube. Assim contornamos distâncias dos nossos usuários pela a falta de usuários no país.

4. Compartilhamento de boas práticas

4.1. Sessões de criação de conceitos

Empresas como a IDEO, renomada consultoria em design e inovação, utiliza o que chamam de design empático, em que os profissionais de diferentes áreas deixam as mesas de trabalho e se colocam no lugar do usuário para saber quais são suas reais necessidades. A Adaptive Path é outra que também realiza workshops com profissionais multidisciplinares em seu processo, contemplando sessões de geração de ideias, criação de protótipos em papel e definição dos princípios de design, estes norteados pelas necessidades de negócios e do usuário.

As referências citadas possuem suas particularidades, mas nenhuma delas utiliza mais de um time multidisciplinar em um único projeto como é o processo de geração de conceitos do INdT Recife. O diferencial do processo de criação do INdT está principalmente no intercâmbio do projeto entre 2 grupos, pois desta forma é possível desenvolver novos conceitos com maior velocidade, variedade e volume de ideias relevantes. Além de qualificar a criação, outra vantagem é a oportunidade que o profissional tem de fazer parte de diferentes tipos de projetos, ampliando seus conhecimentos em tecnologias, métodos, técnicas e formas de interação. E mesmo as ideias que não são imediatamente aproveitadas, não serão perdidas, uma vez que esses esboços, artefatos e protótipos estão documentados e disponíveis para consultas em novos projetos.

Dias antes de iniciar o workshop os designers recebem as informações do próximo encontro, e esta antecipação permite que cada designer faça um trabalho individual de pesquisa e geração de ideias. O ” workshop” é iniciado a partir da apresentação das ideias individuais já pensadas e na sequência cada grupo evolui e refina essas ideias até o desenvolvimento de protótipos em papéis. Num segundo momento (no mesmo dia) ocorre a troca de grupos, onde um deve trabalhar no que o outro estava trabalhando, sem ter conhecimento do que já foi feito. Um exemplo recente foi a criação de um media player, em que um grupo começava a desenvolver a aplicação para celulares com teclado físico e o outro para celulares touchscreen (com teclado virtual), de tal forma que no segundo momento houve a troca de tipos de interface. Um fato curioso foi a percepção unânime de ambos os grupos de que celulares touchscreen permitem maior liberdade criativa e inovadora em relação a navegação tradicional através do teclado físico.

4.2. Nossa experiência com a metodologia SCRUM

O primeiro ponto a se destacar é o fato de que 100% dos colaboradores do INdT possuírem treinamento e certificação internacional de SCRUM, dos pesquisadores à equipe administrativa, o que permite a total compreensão do processo, inclusive pelas áreas onde este não se aplica. E assim torna-se curioso o fato de que mesmo os profissionais das áreas Financeira, Compras e Recursos Humanos tiram proveito do que está sendo difundido, de tal forma que não é raro encontrar no INdT quadros brancos com post-its de tarefas administrativas (figura 18). Claro que não se trata da aplicação dessa metodologia fora da área de desenvolvimento de softwares propriamente dita, mas é apenas um exemplo da força dessa ferramenta numa instituição onde todos estão voltados para um mesmo conceito/modelo de trabalho, o que certamente contribui para a eliminação de empecilhos, que é um dos principais pontos de partida para o sucesso da aplicação do SCRUM.

Outra peculiaridade é o fato de a equipe de UX (Experiência do Usuário), formada por designers de interação, cumprirem o papel de Product Owner, sendo então os responsáveis pela visão de negócio do projeto e pela definição e priorização da lista de tarefas e requisitos, ou seja, criação e gerenciamento do Product Backlog. Pensar nos designers de interação como PO’s faz todo sentido no INdT uma vez que trata-se de uma equipe multidisciplinar com conhecimento nas diversas áreas que compõe a ciência (Dan Saffer, 2007) de interação humano-computador (figura 19), como ergonomia, arquitetura de informação, usabilidade e design gráfico. Outras características essenciais encontradas nesse profissionais, que vão ao encontro dos requisitos do papel de PO são facilidade na comunicação e tomada de decisão, entendimento da necessidade de negócios e do usuário e esclarecimento de questões técnicas, tudo isso apoiado por um time colaborativo (Patton, 2009).

Figura 19 – Sobreposição das disciplinas de design de interação (Dan Saffer, 2007 – atualizado)

É também no time de designers de interação que encontra-se outra adaptação da prática do SCRUM – é a ideia de os designers estarem sempre um sprint a frente dos desenvolvedores. Como são responsáveis por criar todo o conceito da interação do usuário com o produto, seu trabalho começa numa fase anterior ao desenvolvimento, chamada fase de concepção. Com habilidades específicas em arquitetura de informação, designer gráfico e desenvolvimento de protótipos funcionais, esses profissionais geram storyboards, taskflows, layouts e mockups (figura 20) capazes de demonstrar as principais funcionalidades e comportamentos do produto, o que permite ao cliente e a equipe de desenvolvedores melhor entendimento do projeto a ser desenvolvido. E apesar de a abordagem tradicional do SCRUM ser que toda a equipe deve desenvolver e progredir em conjunto dentro do sprint, concentrando todos os esforços em uma mesma tarefa, percebeu-se que isso não se aplicaria bem em uma equipe multidisciplinar que conta com designers e desenvolvedores, uma vez que o trabalho de um é pré-requisito para o trabalho do outro. Daí surgiu a necessidade de os designers terem um sprint a frente para melhor definir as features do produto e criar todo o material citado acima, que será usado para apresentar [figura 5] e explicar aos desenvolvedores de forma mais precisa e detalhada o que deve ser feito no próximo sprint.

Figura 20 – Fotos de reunião de Scrum – em sentido horário, a primeira trata-se de um designer apresentando um mock-up para a equipe de desenvolvedores, a segunda ilustra uma Sprint Planning, a terceira mostra o quadro de scrum e a última um Sprint Review.

O INdT começou a aplicar Scrum em janeiro de 2008, sendo a transparência na comunicação e treinamentos os grandes responsáveis pela rápida adesão por colaboradores e também pelos clientes. A principal vantagem para o cliente é começar a visualizar o projeto desde o primeiro sprint, tendo feedback contínuo entre ele e os desenvolvedores, entre o que é desejado e realizado, entre investimento e retorno do investimento (ROI). Para os desenvolvedores e designers é o reconhecimento do time que torna o Scrum um método bem sucedido, pois ele encoraja a equipe a participar e colaborar de forma que os membros se sintam responsáveis e no controle do projeto, e consequentemente comprometidos com a entrega (Schwaber, 2004). No entanto, o Instituto entende que o método é muito novo e que está aplicando-o há pouco tempo, por isso busca melhoria continua através de treinamentos, troca de experiência, adaptação do método à realidade da empresa e acompanhando cases de outras empresas.

5. Conclusão

Como designers de interação acreditamos na importância da troca de experiência e informação como forma de conhecimento, assim esperamos que o que apresentamos nesse trabalho sirva como fonte de inspiração para os desafios que estão por vir na área de devices móveis.

6. Referências

Patton, Jeff. Presentation slides & Handouts. In: Home: Presentations.
Disponível em : http://agileproductdesign.com/downloads/patton_product_owner_role.ppt

Acesso em 03 fevereiro 2009

Saffer, Dan. Design for interaction: Creating Smart Applications and Clever Devices. Berkeley: New Riders, 2007.

Schwaber, Ken. Agile Project Management with Scrum. Washington: Microsoft Press, 2004.

SCRUM ALLIANCE, Inc. Benefits of Scrum.
Disponível em: <http://www.scrumalliance.org/pages/benefits_of_scrum>
Acesso em: 1 de abril de 2009.