Encaixando na realidade… Ou, nem tanto!

Share on facebook
Share on twitter
Share on linkedin
Share on whatsapp
Share on telegram
Share on pocket

Ultimamente tenho acompanhado com certa atenção o movimento em alguns grupos do Facebook que falam sobre AI, Usabilidade e Design de Interação. Estava literalmente “à espera de um milagre” até que me cansei e puxei o assunto, pois raramente tenho visto profissionais colocando em pauta as dificuldades em “encaixar na realidade”, em outras palavras, no cotidiano profissional, as diversas técnicas e conceitos que permeiam o campo da interação homem-máquina.

São milhares de páginas, blogs e fóruns na rede centrados na difusão de conteúdo inteligente, mas pouquíssimos nos ensinam como fazer a mágica acontecer.

Por esta razão, venho através da minha própria experiência e dificuldades falar sobre este assunto.

Sou Arquiteta de Informação e atualmente, boa parte do meu trabalho está voltado para o planejamento das funcionalidades aliado ao papel de PO (Product Owner), que no meu ponto de vista, tem ganhado força dia após dia, intensificando e aprofundando as atividades de arquitetura, design e usabilidade por meio do contato frequente com o cliente para as definições do Product Backlog.

Esta comunicação, sem interlocutores, me conferiu a oportunidade de abstrair o negócio, identificar os cenários e, principalmente, vislumbrar em primeira mão as problemáticas que em outro momento eram narradas pelos analistas através de estórias muitas vezes confusas e cheias de ruídos.

Nada contra os analistas de sistema, sou a favor de trabalharmos juntos, inclusive na elaboração das estórias. Desta forma, é muito mais fácil externar os objetivos e necessidades do cliente para todos os membros da equipe através de uma abordagem menos técnica e simplificada para descrever os requisitos funcionais e não funcionais de um sistema.

Ok, até aí tudo bem, mas ainda hoje percebo que muitos Arquitetos e profissionais da UX passam boa parte do tempo prototipando quando poderiam estar engajados em outras atividades que pudessem agregar valor às ferramentas desenvolvidas. É neste aspecto que os questionamentos não cessam.

Em tempos de SCRUM, desenvolvimento ágil e passinho do volante (Ah Lelek Lek Lek Lek), arquitetos e demais profissionais, “giram para um lado e giram para o outro” buscando meios de oferecer a melhor experiência para seus usuários em tempo hábil.

Quando eu penso em sprints, penso em Gestalt e logo me dou conta do tamanho do problema, afinal de contas “não se pode ter conhecimento do todo por meio de suas partes”, não é mesmo? Então como manter a qualidade dos sistemas se nós trabalhamos com parcelas e se os prazos vão na direção oposta das famosas e longas documentações?

É certo que a ausência de documentação nos pede acompanhamento full time de todas as fases do projeto, exigindo muito daqueles que dominam o negócio e definiram os requisitos.

Logo, como vocês podem perceber eu ainda não encontrei uma receita para a “arquitetura ágil” e/ou “usabilidade ágil” que funcione dentro de uma fábrica de software e acredito que muitos de vocês estão na mesma situação: procurando formas de gerar os principais entregáveis da arquitetura informacional em curtos períodos.

Outra questão que tenho observado é que muitos destes artefatos parecem perder a utilidade perante a metodologia ágil e o ciclo de vida do software.

Por fim, como não transviar as boas práticas e impedir que o planejamento da interface seja feito de modo puramente instintivo e leviano? [Webinsider]

…………………………

Leia também:

…………………………

Acompanhe o Webinsider no Twitter e no Facebook.

Danielle Moscatelli (@danimoscatelli) é UX Planner, consultora em Ergonomia de Softwares e Sistemas Web e mantém o site www.danimoscatelli.wordpress.com.

Share on facebook
Share on twitter
Share on linkedin
Share on whatsapp
Share on telegram
Share on pocket

Mais lidas

Uma resposta

  1. Também sou arquiteta e trabalho no mesmo setor. Achei que só eu tinha estes mesmos questionamentos.

    Quem trabalha com AI dentro de uma metodologia ágil sente na pele estas dificuldades em gerar documentações.

    Eu acho que na maior parte das vezes elas são desnecessárias para o projeto, o problema é que estas é que “justificam” o modo como pensamos, ou seja, expõe a maneira como atingimos os resultados.

    Os artefatos nos permitem a chance de provar aquilo que falamos, mas sem problemas, usuários satisfeitos também provam!

    Ótimo artigo, espero que dê frutos!

Deixe um comentário

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *