Se tem uma coisa pela qual sempre briguei onde trabalhei, junto aos “meus” analistas, arquitetos e desenvolvedores, foi por essa questão, ilustrada na foto. Cada vez mais, os sistemas devem assumir o comportamento daquelas que o utilizam, e não engessá-los de maneira a tornar a experiência do usuário uma chatice que logo virará um “desespero” por completo.
A observação é uma técnica antiga que nos dá a amplitude dos problemas. Muito utilizada em diversas áreas da ciência e tão pouco conhecida (em pleno 2017) pelos profissionais de construção de softwares. E, se fosse corretamente aplicada em nossa área, com certeza não teríamos tantos insucessos na usabilidade dos sistemas.
Trazer isso para dentro do desenvolvimento de software é ainda, sem dúvida, uma atividade extremamente árdua para os tecnólogos, que detêm profundos conhecimentos das técnicas, mas não são tão humildes para aceitar que a simples mudança de um label (aquela frase que define o nome do campo onde, por exemplo, se informa um “Endereço”), o deslocamento da caixa de texto (aquela caixinha onde você digita, por exemplo, o nome do cliente), ou o posicionamento de botões não são meras “frescuras” de usuários, como muitos de nós gostamos de denominar.
O comportamento do usuário em relação ao uso do software será a grande diferença entre empresas de sucesso e as fracassadas. Vejamos o exemplo que o Google nos dá. Simples, intuitivo em grande parte dos seus softwares. Apple, há mais tempo, com sua preocupação de trazer sempre a melhor experiência hardware vs software, é outro exemplo, empregando qualidade e “chamando” o preço de forma consequente.
Há ainda apps como WhatsApp e Uber, dentre tantos outros, que usuários tidos como “ineficientes” para operar baixam, instalam e saem usando. É claro que o contexto desses softwares é bem mais simples e mais “fácil” do que um ERP. Mas podemos sim ter e trazer o comportamento dos usuários para dentro dos sistemas considerados grandes. Podemos sim trazer o “olhar” das tarefas, e não o das atividades dos usuários, embarcado em nossos softwares.
Métodos ágeis como o Scrum (boa prática para gerenciar e controlar o desenvolvimento de software) já pregam isto há algum tempo como, por exemplo, o papel fundamental do Product Owner (Dono do Produto – uma “espécie” de usuário avançado que controla as demandas, aquilo que vai ou não ser feito em um sistema).
Então, por que ainda fazemos softwares no padrão 20/80? Por que ainda temos vários fracassos nos projetos? Por que os custos extrapolam? Podemos listar vários os motivos, mas o principal é que ainda fazermos softwares para nós e não para os usuários. Pensamos lindamente no BACK-END (sistema que roda por trás do que os usuários veem) e deixamos o FRONT-END (aquilo que você de fato usa) para “designers” e esquecemos que este último é para os usuários de fato o “sistema”.
Precisamos ter um pouco mais de humildade e deixar este preconceito que criamos desde a época da faculdade (era assim, acreditem), onde fica implícito que usuário é um “inimigo”. Não, ele não é. Ele simplesmente vai fazer com o seu sistema, aquilo que ele faz durante toda a sua trajetória. Irá buscar caminhos melhores, atalhos, jeito de fazer aquilo mais rápido e melhor. Seja na travessia de um jardim ou na utilização do sistema da empresa.
Reflitamos. Deixe de lado o egoísmo de achar que nós sabemos de tudo e que apenas nós podemos oferecer as alternativas corretas. Quem sabe mais é quem precisa e faz uso de algo todos os dias. Vamos trazê-los e escutá-los. Afinal, para que você estuda e “escova o bit” no mercado de TI se não vai produzir algo que de fato melhore o trabalho das pessoas?
Alexandre Perdigão
Gestor de relacionamento e parcerias da Toplink
Compartilhe:
Posts relacionados:
