Como mockups de interface de usuário ajudam no desenvolvimento de sistemas

HiMaker Blog 0 Comments

Por: Gabriel Dias

 

Todos nós em maior ou menor grau dependemos de softwares para executar diversas tarefas de nosso cotidiano pessoal e profissional. O foco deste artigo é mostrar a importância de que tanto quem desenvolve o programa quanto quem o está solicitando tenham uma única visão sobre o que será entregue e qual seria uma forma de que ambos possam ter essa mesma visão durante o processo de desenvolvimento de um software.

O centro do processo de desenvolvimento

Quando um software vai ser criado temos logo de saída dois tipos de pessoas envolvidas nesse processo: uma que vai dizer o que precisa e outra que vai criar a solução para a necessidade da primeira. Você já deve estar imaginando o que acontece se um lado não entender o que o outro quer: um resultado final completamente inaceitável. A imagem a seguir ilustra de uma forma bem humorada exatamente isto.

E temos que lembrar que, muitas vezes, os que solicitam não sabem exatamente o que querem e acabam passando de forma errônea o que desejam que o programa faça. Quem desenvolve um programa sempre estará sujeito ao risco de ter que modificar e remodelar grande parte do programa que está desenvolvendo porque o cliente trouxe novas idéias que resultaram em modificações durante o processo de desenvolvimento. E vamos supor que isto não tenha acontecido e o desenvolvimento tenha sido “tranquilo”. O que impede este mesmo usuário questionar e até mesmo rejeitar o software entregue dizendo que o mesmo tem um operacional “complexo”?

Ao longo dos anos, diversos artigos, livros e metodologias foram elaborados tentando minimizar as consequências do que foi apontado acima. Em 2001, um grupo de especialistas em desenvolvimento de software se reuniu no resort Snowbird em Utah e publicou o que ficou conhecido desde então como Manifesto Ágil. Não iremos aqui entrar em detalhes do mesmo mas apenas relembrar em seus pilares básicos:
• Indivíduos e interações ao invés de processos e ferramentas ;
• Software que funciona ao invés de documentação extensiva ;
• Colaboração direta com o cliente ao invés de negociação de um ou mais contratos ;
• Respostas às mudanças ao invés de seguimento de um plano

Estes pilares nos dizem que no desenvolvimento de sistemas, programas e aplicativos, tão importante quanto saber desenvolver é saber aonde se quer chegar e compreender o que o usuário deseja para transformar esta expectativa em realidade.
Para que isto seja algo plausível é necessário que tanto o cliente quanto o desenvolvedor estejam com a mesma visão sobre o que vai ser desenvolvido e entregue. Uma das formas para estabelecer esta sintonia entre ambos é com o uso de mockups.

A utilização de Mockups

O mockup nada mais é do que um protótipo que permite o teste de um projeto. São usados principalmente por designers para receberem um feedback dos usuários.

O uso mais comum de mockups no desenvolvimento de software é a criação de esboços de telas de sistema que mostram ao usuário final como o desenvolvedor está pensando em montar as telas que o software terá sem ter que construir o programa em si. Mockups de Interface de Usuário de software podem variar de layouts de tela muito simples desenhados a mão até desenhos mais realistas, para interfaces de usuário desenvolvidas em uma ferramenta de desenvolvimento de software. Para isso, eu uso inicialmente o velho lápis e papel e depois o programa chamado Balsamiq Mockups.

Basicamente procura-se desenvolver o aplicativo de forma incremental, isto é, ao invés de tentar especificar tudo antes de começar procuramos criar as primeiras funcionalidades a partir das especificações iniciais testando idéias, desenhando esboços de telas e colhendo feedback dos usuários. Este estilo de codificação nem sempre é facilmente aplicável pois requer uma cooperação muito próxima com os usuários do aplicativo. Mas mesmo que o acesso aos usuários não seja tão simples o que não podemos é perder de vista que quanto mais cedo descobrirmos um equívoco menos dispendioso será corrigí-lo.

O ponto de partida é conseguir definir as entidades que usarão o sistema e principalmente como pretendem usá-lo e que resultados esperam obter. Isto é chamado de caso de uso. Definindo quem vai usar e o que vai fazer passamos para o como que seriam os primeiros mockups. Eu, particularmente, gosto de ter uma idéia das páginas e telas principais dos aplicativos que desenho e de como os usuários navegarão entre as mesmas. Claro que no inicio de um projeto tal fluxo de navegação entre as páginas estará incompleto, mas de qualquer forma os mesmos ajudarão a focar a equipe no que precisa ser feito e também entender como as ações são sequenciadas.