Como usar o Postman para documentar uma API

Texto: Daivid Silverio
Imagem: Vinicius Rocha

Desenvolver um aplicativo muitas vezes exige algum tipo de integração com outro sistema já existente. Por exemplo, se você quiser que as pessoas comprem o seu serviço por meio do seu app, é preferível que você faça uma integração com uma plataforma de pagamento que está atuando no mercado (IUGU, Mercado Pago, etc). Essas integrações são muito úteis para que o desenvolvedor não precise criar determinada funcionalidade do zero (pagamentos, mapas, login com redes sociais, etc.), e sim, apenas integrar o aplicativo com um serviço já existente. Ou até mesmo se você quiser utilizar no seu app uma plataforma já usada pela sua empresa ou algum banco de dados que você possua. Essa integração é feita por meio do consumo de uma API. E isso também te ajuda a economizar seus recursos na hora da produção.

Nós já entendemos que essa API é necessária quando se trata das funcionalidades que precisam de uma integração com outro sistema. Mas, é necessário que você entenda também como funciona este trabalho na maioria das empresas de desenvolvimento, inclusive aqui na Jera.

Tem dois caminhos para desenvolver este material: você pode alocar a equipe da empresa para desenvolver isso ou fazer por conta própria. Porém, atente-se bem se você escolher a segunda opção, pois cada empresa de desenvolvimento possui algumas regras que devem ser seguidas quando se trata de produzir em conjunto. E o máximo de atenção a isso é essencial para você não perder tempo e dinheiro com algo que depois não poderá ser utilizado.

Na Jera, quando o cliente prefere desenvolver a parte da API, nós fazemos a seguinte exigência: entregar a API documentada e fornecer uma Collection do Postman. Mas para você fazer isso, primeiro você precisa aprender a usar o Postman, certo?

Postman é uma ferramenta que dá suporte a documentação das requisições feitas pela API. Ele possui ambiente para a documentação, execução e testes de APIs e requisições em geral. O objetivo deste texto é fornecer um guia introdutório para a criação de documentações vivas para a sua API por meio da plataforma Postman.

Saiba o que iremos aprender agora:

  • Criar Coleções
  • Criar Pastas
  • Criar Requests
  • Adicionar Parâmetros
  • Adicionar Headers
  • Criar e popular variáveis de ambiente/globais

Criar Coleções

Clique no ícone da pastinha para abrir um formulário para criar a coleção.

imagem-1

Preencha com o nome desejado para a sua coleção e clique em “Create”. Pronto! Coleção criada! Agora vamos adicionar algumas requests e pastas na sua coleção.

imagem-2

Criar Pastas

Clique no ícone de reticências para abrir o submenu da Coleção. Clique em “Add Folder” para Adicionar uma nova pasta.

imagem-3

Escreva o nome da pasta que você acabou de criar e clique em “Create” para salvar. Você pode usar essa funcionalidade para organizar melhor suas requests, de acordo com os recursos ou funcionalidade que sua API provê.

imagem-4

Criar Requests

Para criar uma request, basta você digitar o endereço da API que você está documentando na barra de endereço e selecionar o método HTTP que será usado na request.

imagem-5

Para salvar essa request na Coleção, clique em “Save”.

imagem-6

Um formulário irá aparecer, onde você poderá preencher o nome da request e informar em qual Coleção e Pasta você deseja salvá-la. Finalmente, clique no botão “Save” laranja pra salvar a request.

 

imagem-7

Adicionar Parâmetros

Por exemplo, vamos utilizar o POST para localhost:3000/users, que criamos na seção anterior.

Para informar os parâmetros da request, selecione o formato desejado: form-data, x-www-form-urlencoded, raw (Text, JSON, XML etc), binary.

Por exemplo, supondo os parâmetros de criação de um usuário:
name: Test
email: test@test.com
password: 123456

Para testar, basta clicar no botão azul “Send”. O resultado da Request vem na parte de baixo onde está escrito “Response”

Em form-data:

imagem-8

Em JSON:

imagem-9

Você pode observar a resposta na aba “Body”, seguida pelos “Cookies” e “Headers” da mesma.

No exemplo, eu criei um header chamado “TOKEN”, para a demonstração.

imagem-10

Adicionar Headers

Adicionar headers é ainda mais simples do quê adicionar parâmetros. Basta selecionar a aba “Headers”, ao lado de “Body”, logo abaixo a barra de endereço:
imagem-11Criei uma request adicional que exige um token de autenticação para fazer requests a recursos protegidos, como as informações do usuário, neste caso.
imagem-12

Caso a autenticação funcione, os dados do usuário são retornados. Podemos ver isto na imagem abaixo. 

imagem-13

Se acontecer o contrário, um erro é recebido, 401 (Unauthorized), que significa que não foi autenticado.

imagem-14

Criar e popular variáveis de ambiente/globais

Ficar escrevendo todos esses valores para parâmetros e headers pode acabar ficando um pouco tedioso dependendo da sua API. Principalmente, se ela possuir autenticação via tokens que podem mudar.

Para facilitar nossa vida um pouco, podemos fazer uso das variáveis de ambiente e da aba extra “Tests”, encontrada logo abaixo da barra de endereços.

Primeiramente, vamos criar um ambiente. Clique no ícone com uma engrenagem no canto superior direito e logo em seguida, Manage Environments.

imagem-15

Na janela que aparecer, clique no botão “Add”. Um campo para preencher o nome do novo ambiente irá aparecer. Preencha com o nome desejado e clique em “Add”.

imagem-16

A partir desse momento você também já pode adicionar as variáveis que eu havia comentado.

Vamos adicionar uma variável chamada “Last User Token”. Clique em “Add” ou “Update” (caso você voltar nessa tela e estiver adicionando novas variáveis).

imagem-17

Agora vamos voltar na request que havíamos criado na seção “Criar Requests”. Tendo a request selecionada, clique onde está escrito “No Environment” e selecione o nome do ambiente que você acabou de criar.

imagem-18

Em seguida, selecione a aba “Tests” para começar a facilitar a vida de quem for utilizar sua API.

Nessa aba você pode executar scripts javascript que serão executados após as requests. Assim, você poderá capturar os resultados contidos nos corpos e headers das suas respostas.

Como um exemplo bem simples, vamos capturar o e-mail do usuário contido no corpo da resposta e header TOKEN da mesma.

postman.setEnvironmentVariable(“Last User Email”, JSON.parse(responseBody).email); 
postman.setEnvironmentVariable(“Last User Token”, postman.getResponseHeader(“TOKEN”));

imagem-19

Agora podemos modificar o método que obtém informações do usuário para usar o header de autenticação. Para isso, utilize o Token salvo na variável de ambiente “Last User Token”

Selecione a request que precisa usar a variável de ambiente. Então, vá até o campo do Header, Parâmetros ou Corpo da Request e utilize a variável usando a notação {{Nome da Variável}} para recuperar o valor salvo.

No exemplo da autenticação, ficamos com: Authorization:Bearer {{Last User Token}}

imagem-20

Podemos usar esse mecanismo não apenas nos parâmetros, mas também nos parâmetros/corpos das requests.

Ex:

imagem-21

O postman também te possibilita salvar suas requests e coleções na nuvem. Ele também tem a capacidade de importar/exportar Coleções via um link único ou um arquivo .json. Basta clicar no ícone de reticências na coleção e escolher a opção “Export”.

imagem-22O Postman é uma ferramenta muito poderosa e fácil de ser utilizada. Pode ser usada como um meio de comunicação entre equipes de times/empresas diferentes quando houver necessidade de integração de APIs e com certeza tem o potencial de facilitar a vida de muita gente!

Mais exemplos e documentação oficial: https://www.getpostman.com/docs/ 

Como lançar o seu primeiro aplicativo no mercado?

A era digital chegou e com ela a busca em facilitar os serviços que nós utilizamos no nosso dia a dia. Hoje os aplicativos tomam a frente quando se trata de otimizar e inovar nas ações diárias das pessoas. Por exemplo, não precisar mais ir ao banco e ter a facilidade de realizar as atividades que levariam horas em minutos na tela do seu Smartphone. Ou até mesmo, você se lembra qual foi a última vez que você ligou para pedir um táxi? 

Um estudo feito pela Kantar Worldpanel Comtech mostrou que 56% da população brasileira usava Smartphone no primeiro semestre de 2016, em comparação com 6% no ano de 2012,  e esse número só cresce. Os preços dos aparelhos estão cada vez mais acessíveis e com o crescimento pela busca de um celular mais moderno, vem também a busca por funções e facilidades melhores. Dê uma olhada nesses dados sobre de que forma e para que uma pessoa utiliza seu celular atualmente:

utilidades

Os tempos mudaram e agora se uma empresa não inova, não investe na tecnologia, ela fica para trás.  Afinal, isso é essencial para conquistar novos clientes, melhorar seus processos, lançar novos produtos, agilizar o atendimento, entre outros. Então, se você já pensou em investir na área de apps, aqui estão alguns pontos que precisa saber.

Como tirar a minha ideia do papel?

Assim como em todo segmento do mercado, a concorrência na área dos aplicativos é grande. Muitos projetos acabam não indo para a frente porque não correspondem à realidade do que as pessoas realmente necessitam.

A primeira coisa a se fazer antes de começar a produzir o seu app, é saber se a sua ideia resolve algum problema e descobrir se as pessoas necessitam da mesma. A melhor forma de fazer isso é através de uma pesquisa com o público. E também verificar se o que você quer produzir seria algo que eles usariam.

Antes de lançar algo, é essencial que o empreendedor primeiro valide-o através de um Mínimo Produto Viável (MVP). Isso quer dizer, desenvolver um produto apenas com as funcionalidades essenciais para lançar de imediato no mercado. Gastando assim menos tempo, investimento e esforço. É preciso também verificar se ele será utilizado pelas pessoas ou se realmente é uma necessidade. Se não for, é necessário adaptá-lo para a realidade dos consumidores.

mvp1

Mas por que começar pelo MVP?

É extremamente importante para os negócios que ainda não estão estabelecidos no mercado começar com um MVP! Imagine assim, você tem uma ideia e acredita que fará muito sucesso (e deve acreditar mesmo), e devido a isso, investiu muito para fazer o produto perfeito, com todas as funcionalidades que você quer fazer. Mas na hora de lançá-lo, não era uma necessidade do seu público. Ou então, as pessoas acharam ele muito complexo ou confuso e por isso acabou não sendo vendido ou utilizado.

Todos devem confiar na capacidade dos seus projetos, mas não basta só o empreendedor ver esta necessidade, é preciso que o mercado enxergue isso também.

Vamos imaginar um segundo cenário, onde o empreendedor antes de começar com a produção, fez uma pesquisa e verificou se há necessidade. Após isso, ele criou um MVP com o menor investimento possível baseado nas informações que recolheu. Porém, mesmo assim, acabou lançando algo que não era exatamente o que aquele público precisava ou que é muito complexo e confuso.  Devido a isso, as pessoas não souberam exatamente como usar e assim o projeto não obteve o sucesso pretendido no primeiro momento.

Triste, mas acontece não é? Por isso o MVP é importante, enquanto no primeiro cenário gastou-se mais tempo e dinheiro, no segundo cenário, o empreendedor errou antes e gastou pouco. Com isso, ele pôde utilizar o restante do investimento para refazer o que foi produzido ou aprimorar de acordo com o feedback dos clientes.

Independente do tipo de público que você esteja planejando ter como alvo, sempre antes de investir tudo em algo novo é preciso validá-lo primeiro.  No desenvolvimento de aplicativos isso não é diferente.

Tenho a minha ideia para um app, já posso começar a desenvolver?

Como em qualquer negócio, a primeira coisa que você deve ter para desenvolver o produto é o investimento. No mercado de software esse valor pode variar de 30 a 90 mil reais por plataforma (Web, iOS, Android, etc). Esta variação também acontece de acordo com as funcionalidades que você deseja ter no seu aplicativo.

Quando se trata de desenvolvimento de software, assim como de um edifício, mais importante do que “o que desenvolver” é “como desenvolver”. Por isso, antes de partir para o desenvolvimento de qualquer funcionalidade, é necessário que você comece pelo design dele. Este design irá definir como funcionará o aplicativo, e traçará o fluxo de cada uma das telas do mesmo. Apenas com o design é possível para a maioria das empresas de desenvolvimento de software, inclusive a Jera, passar um orçamento mais preciso.

Na Jera, o período médio para realizar o design é de duas semanas.

semana-1

Pense no design como a planta de um edifício, antes de passar para a construção, é preciso você ter este planejamento de como ele irá ficar, para saber qual será a melhor forma ou técnica que o construtor deverá utilizar para fazê-lo. O mesmo é com o desenvolvimento de software! Portanto, o design é a primeira etapa para tirar a sua ideia do papel.

E se você está procurando por investidores, o design das telas será um grande aliado seu. Pois com esses desenhos você pode apresentar algo mais palpável para o seu futuro investidor, algo mais real e visual. E com isso aumentar as suas chances de obter um maior investimento para realizar o desenvolvimento.

Quero começar o desenvolvimento, mas não tenho muito dinheiro. Existe alguma opção mais em conta?

Existem duas formas de desenvolver um aplicativo: híbrido ou nativo. O híbrido é o mais recomendável para quem tem um orçamento limitado ou ainda está validando o produto. Ele é desenvolvido em uma plataforma só (a web) e depois encapsulado para Android ou iOS.  Para utilizá-lo, o usuário deve ter acesso à internet, porque quando ele entra no app, na verdade ele está entrando em uma página da web que foi adaptada para a tela do celular. Mas não precisa se preocupar se isso irá atrapalhar a experiência do usuário na hora de navegar pelo celular. Ele fica parecendo que foi desenvolvido nativamente, mal dá para notar a diferença.

O nativo é aquele que é desenvolvido nas linguagens nativas do Android e do iOS. Normalmente o orçamento para desenvolver este tipo é mais caro que o normal. Isto porque ele é feito em duas plataformas e leva o dobro do tempo, diferente do híbrido.

Mas tenho uma notícia boa, se você quiser lançar rápido a sua ideia, você pode, na maioria das vezes, alocar dois times para desenvolver paralelamente nas duas plataformas e assim otimizar o tempo. Mas saiba que desenvolver um app não é algo que pode ser feito da noite para o dia. Aqui na Jera, por exemplo, leva-se normalmente de 2 a 3 meses por plataforma.

nativoxhibrido

Se o seu aplicativo precisar utilizar funcionalidades nativas do celular, como câmera, GPS, etc, o mais indicado é desenvolver  nativamente. Pois assim, as ferramentas próprias do celular funcionarão melhor e tornarão a experiência do seu usuário mais satisfatória.

É só ter um app para o meu negócio que o sucesso está garantido?

Calma lá, não é bem assim! De fato, este tipo de serviço te ajuda a expandir sua empresa. Só que para isso acontecer, não basta apenas ter a mercadoria, deve também possuir um diferencial. É um erro pensar que só é preciso desenvolver um aplicativo e ele fará dinheiro sozinho. Não se esqueça que a tecnologia é feita para as pessoas. Investir em tecnologia, mas não proporcionar um atendimento qualificado para seus clientes e não aprimorar a forma como eles experimentam o seu produto, de nada adianta.

Junto com a tecnologia, também tem que vir a experiência que as pessoas terão com a sua empresa. E eu tenho certeza que você deseja que ela seja extraordinária!

*Icons created by Guilherme Simoes from the Noun Project

5 Práticas Fundamentais para aumentar a Retenção de Talentos na sua organização

Texto: Diego Ungari

A área de Gestão de Pessoas tem consolidado cada vez mais sua função estratégica junto às organizações. Contudo, para assumir esse papel encontra uma série de desafios. Um dos maiores é a criação e aplicação de práticas que garantam a retenção dos talentos contratados.

Em geral, muitas instituições têm dificuldade em entender as necessidades de seus colaboradores. Por isso, a área responsável pela gestão de pessoas não consegue definir o ponto de partida para melhorar a felicidade da equipe. E assim, consequentemente, muitas pessoas de alto potencial acabam saindo.

Pensando nisso, existe uma série de práticas adaptáveis a realidade de qualquer entidade e que podem garantir o aumento da retenção de talentos. A seguir listamos cinco pontos que consideramos fundamentais para isso:

1.  Atraia pessoas alinhadas à cultura da organização

Em primeiro lugar, toda instituição deve ter clareza sobre sua missão, visão e seus valores. Pois a partir disso poderá entender o que constitui sua cultura e buscar pessoas que se conectem a ela.

Durante o processo de seleção, é importante que seja dada atenção ao alinhamento entre o perfil do candidato, a cultura organizacional e a oportunidade de trabalho em aberto. Uma boa forma de se fazer isso é utilizar o modelo de entrevista por competências.

Com isso, será reduzida a possibilidade da pessoa contratada não se adaptar ao cotidiano do local de trabalho e sair precocemente.

2.  Cálculo do Turnover

O Cálculo do Turnover é uma importante ferramenta para que a equipe de Gestão de Pessoas consiga visualizar de forma concreta o índice de rotatividade na organização. Também ajuda a pensar em estratégias para melhorar a retenção de seus talentos.

A forma de realizar este cálculo, bem como a periodicidade e a porcentagem de turnover esperada, deve ser definida de acordo com a realidade da entidade. Mas pode-se tomar por base a fórmula abaixo:

(# Desligados Passivos ou Ativos)
____________________________________________________
# Total de Funcionários

Se o cálculo do turnover de desligados passivos (pessoas demitidas) for alto, em geral, isso representa problemas no processo de recrutamento e seleção. Se o cálculo de desligados ativos (pessoas que pediram demissão) for alto, isso se relaciona mais às práticas da empresa para manter seus talentos. Entretanto, ambos impactam diretamente na retenção.  

3.  Clima Organizacional

Podemos definir o clima organizacional como um conjunto de fatores internos que influenciam na percepção das pessoas sobre o ambiente de trabalho. Apesar de ser algo subjetivo, isto interfere de várias formas na motivação dos colaboradores. Por isso, a área de Gestão de Pessoas deve buscar constantemente analisá-lo.

A forma mais eficaz de identificar como anda o clima na sua instituição é por meio da Pesquisa de Clima Organizacional. Ela pode ser aplicada trimestralmente, semestralmente ou anualmente, dependendo da sua necessidade e realidade.

4.  Plano de carreira

Diversas entidades, encontram grande dificuldade em clarificar para seus funcionários os caminhos que eles podem seguir internamente. Isso acontece especialmente com as empresas de pequeno porte.

Sem essa clareza a tendência é que os bons profissionais busquem oportunidades externas que proporcionem seu crescimento. É importante que as organizações definam como podem contribuir para que as pessoas se desenvolvam profissionalmente após contratadas. Portanto, deve-se difundir entre os colaboradores um plano de carreira, para que entendam as oportunidades internas e o que precisam desenvolver para atingi-las.

5. Valorização de Pessoas

Por fim, é fundamental que os gestores compreendam que as pessoas não podem ser tratadas como meros recursos. Elas dependem de diferentes estímulos para se sentirem realizadas, motivando-as a continuarem na instituição.

Desse modo, deve-se buscar vários meios para que as pessoas sejam valorizadas e reconhecidas por seus esforços. A ideia de que apenas o salário basta para motivar a equipe torna-se cada vez mais ultrapassada. E quando o gestor não compreende isso, sem dúvidas, terá péssimos resultados e um baixo índice de retenção.

Como entregamos um produto valioso utilizando as metodologias do Design Thinking — Capítulo 3

Nesta série dividida em três capítulos, nós, designers da Jera, relataremos nossa experiência com o projeto New App. Pelo qual utilizamos técnicas do Design Thinking e trabalhamos em conjunto com os desenvolvedores durante todo o processo de design.

No capítulo anterior relatamos como trabalhamos na resolução da falta de engajamento do cliente da Jera com a nossa ferramenta de gerenciamento. E o erro que cometemos que deixou nosso cliente insatisfeito.

Neste capítulo contaremos como trabalhamos para corrigir os nossos erros e qual foi resultado da segunda fase de testes. Relataremos também, nosso esforço para chegarmos a solução da falta de foco das equipes da Jera na Sprint 0 e Sprint Final.

Capítulo 1

Capítulo 2

Começamos tudo de novo

Após a “bronca” que levamos dos nossos clientes, vimos que a tentativa de solucionar vários problemas de uma só vez e em tão pouco tempo foi “um tiro no pé”. Assimilamos os erros cometidos e concluímos que era preciso reduzir funcionalidades, que menos era mais.

Com o foco centralizado no usuário, fizemos um Mapa de Empatia, entendendo melhor quem é o nosso cliente, o meio em que vive, suas expectativas, medos e o que ele realmente precisa. Assim, ficou mais simples entender o que realmente seria importante para ele. Decidimos então que funcionalidades deveríamos focar:

  • Acompanhar o andamento das Sprints do projeto;
  • Visualizar tarefas pendentes;
  • Acesso a documentos e protótipos;
  • Relatar problemas;

Com isso em mente, começamos os rabiscos de novo, pensando em facilitar qualquer atividade que o usuário precisaria fazer. O que antes era um tela cheia de informações que eram ignoradas, tornou-se uma tela com 4 botões simples, que levaria o usuário a um caminho mais claro antes dele concluir a tarefa desejada.

mockup_new_app
Tela principal do nosso segundo protótipo

 

Protótipo pronto, partimos para a segunda fase de testes.

Solução do problema de falta de foco

Antes de revelar como foram os testes. Contaremos como chegamos a solução da falta de foco das equipes da Jera na Sprint 0 e Sprint Final.

A Sprint 0 e Sprint Final é um período importante em que a equipe deve se concentrar. Porém poucos estavam realizando estas etapas efetivamente, por vários motivos, tais como: resolver problemas de outros projetos, distração com mídias sociais e auxílio a outros colegas quando estavam sem tempo (alguns tinham dificuldade em dizer “não”).

A solução encontrada foi identificar as equipes que estavam nestes períodos por meio de uma bandeirinha. Desta forma, quem estivesse com a bandeira teria um sinal que deveria focar no projeto em que está trabalhando e quem estivesse de fora não incomodaria o time com a identificação.

Além da sinalização da Sprint 0 e Final, sentimos a necessidade de incluir outra situação, quando a equipe está atropeladas de tarefas a serem realizadas no projeto e o tempo de entrega está quase no fim. Denominamos este caso de “Projeto Explodindo”.

O processo de produção das bandeiras foi o mais interessante, pois deixamos de criar soluções digitais para criar soluções físicas. Largamos o computador para fazer um trabalho artesanal que nos lembrou a época da escola. Recortamos papel, cortamos madeira, colamos papel e plástico, e nos divertimos muito com isso.

producao-das-bandeirinhas

Após terminar a produção, fizemos quatro bandeiras para sprint 0 e final com a cor amarela e três bandeiras para o caso de o projeto estar atrasado com a cor vermelha.

Hoje, as equipes estão utilizando as bandeiras e já tivemos bons feedbacks, muitos dizendo que as interrupções foram reduzidas e que a concentração para os projetos está sendo bem maior.

Segunda fase de testes

Ansiosos para saber como seria o resultado, colocamos o segundo protótipo para ser testado, desta vez, com pessoas que se encaixavam no perfil dos nossos clientes e com atividades mais focadas nas principais funções. Realizamos o mesmo procedimento do primeiro teste.

O resultado foi surpreendente, a diferença entre os dois testes foi “gritante”. Os usuários realizavam as tarefas rapidamente, um ou outro demoraram mais que um minuto. Um bom exemplo foi a função de visualizar as tarefas pendentes, em que a média caiu de 1min31s para apenas 17s.

Abaixo é possível visualizar a comparação da média de tempo na realização das tarefas entre o primeiro e o segundo teste:

media_testes_de_usuário
Média de tempo na realização das tarefas do primeiro e segundo protótipo

 

Mesmo com a melhora significativa, tivemos que corrigir alguns pequenos detalhes que trouxeram alguma dificuldade para os usuários.

Entrega da última sprint

Chegou a hora tão esperada. Ao mesmo tempo que estávamos confiantes pelos bons feedbacks, estávamos nervosos, porque sempre há alguma tensão quando nosso trabalho é avaliado.

Primeiro apresentamos as bandeirinhas, e tivemos uma boa resposta dos nossos clientes. Eles elogiaram a solução a que chegamos e a forma de como a executamos. Que dessa vez, deu pra ver que trabalhamos em equipe.

Depois apresentamos o aplicativo. Muita calma nessa hora. E…

O Jeff e o Ney gostaram também do resultado que apresentamos e ficaram surpreendidos com a diferença entre os dois testes. E deram sinal verde para que os desenvolvedores começassem o desenvolvimento do aplicativo. Este feedback nos deixou aliviados.

O que aprendemos

Ao utilizar metodologias do design thinking, ir a fundo no projeto, estudar e selecionar os reais problemas, propor soluções com uma base técnica bem definida, realizar testes e pesquisas com os usuários, ajudou-nos a fugir da subjetividade e tomar decisões com argumentos concretos, tendo a certeza de estar no caminho certo e entregar um produto valioso ao nosso cliente e ao usuário final dele.

A experiência de trabalhar em conjunto com os desenvolvedores trouxe-nos uma visão mais lógica na construção de um produto. Com a opinião técnica deles do que é possível ou não fazer, era fácil para nós, designers, desenharmos uma solução.

A redução de documentação também foi algo positivo, já que o desenvolvedor estava ao nosso lado e entendia o projeto todo, participando da criação, compreendendo tudo aquilo que foi feito e não simplesmente executando algo que caía em suas mãos.

O projeto New App foi um grande aprendizado para todos e levaremos este conhecimento para o restante das nossas carreiras.


É isso! Chegou ao fim nossa jornada.

Gostaríamos de receber seu feedback. O que achou do nosso processo? O que podemos melhorar? O que podemos acrescentar? O que podemos fazer de diferente?

Autores: Carol Cabral e Vinicius Rocha

Como entregamos um produto valioso utilizando as metodologias do Design Thinking — Capítulo 2

Nesta série dividida em três capítulos, nós, designers da Jera, relataremos nossa experiência com o projeto New App. Pelo qual utilizamos técnicas do Design Thinking e trabalhamos em conjunto com os desenvolvedores durante todo o processo de design.

No capítulo anterior contamos como surgiu a oportunidade de trabalhar no projeto New App e o árduo processo na escolha do nome da nossa ferramenta de gerenciamento de projetos, Active Collab.

Neste capítulo diremos como trabalhamos na resolução da falta de engajamento do cliente da Jera com a nossa ferramenta de gerenciamento. E o erro que cometemos que deixou nosso cliente desapontado.

Capítulo 1

Capítulo 3

Processo de Ideação — produção do app para nosso cliente

Decidido o nome e alguns problemas internos solucionados, era a hora de focarmos na falta de engajamento do cliente com a ferramenta de gerenciamento.

Desde o início do projeto, batemos na tecla que a solução poderia ser um ajuste comportamental e não necessariamente um app, mas a mão dos devs e designers coçavam para “codar” e “leiautar” e a vontade era desenvolver um aplicativo. Esta ansiedade acabou se tornando um erro, que iremos relatar mais a frente.

Resolvemos desenvolver o app, porque percebemos que ele seria um facilitador para os clientes, que em sua maioria estão ocupados e não conseguem parar, sentar em frente a um computador e acompanhar todo o processo de seu projeto. Com isso, nos concentramos em funções básicas e que gostaríamos que tivessem o engajamento do cliente:

  • Acompanhamento das discussions (conversas);
  • Pendências do próprio cliente;
  • Alternar projetos;
  • Acompanhar projetos;

Após a definição das funcionalidades, começamos a rabiscar, devs e designers desenhando e colocando suas ideias no papel. Colhemos, misturamos e discutimos as soluções, chegando a um resultado que todos julgaram a melhor alternativa.

Processo de Prototipação

Com a sensação de ter feito a escolha perfeita. Largamos o lápis e o papel e botamos a mão na massa.

Talvez por costume, dividimo-nos mais uma vez em designers e desenvolvedores, cada um sentado no seu cantinho, fazendo o que melhor sabe fazer, antes mesmo de validarmos as hipóteses apontadas. Enquanto os devs “codavam”, nós designers terminávamos de montar o protótipo (sem código) no InVision com todas as telas e simulações.

Tela principal do nosso primeiro protótipo
Tela principal do nosso primeiro protótipo

 

Primeira fase de testes

Protótipo pronto era a hora de validá-lo. Buscamos testar com pessoas próximas, pois infelizmente não foi possível entrar em contato com o nosso público alvo (clientes).

Para realizar os testes, chamamos alguns colegas e familiares para serem nossa “cobaias”. A metodologia que empregamos baseava-se em um roteiro no qual descrevíamos um cenário e tarefas que usuário deveria fazer para cada funcionalidade que queríamos por em prova.

Em uma sala privada, uma pessoa da equipe fazia o papel de facilitador, responsável por ler o roteiro e comunicar-se com o usuário e outro era o observador, responsável por analisar as ações e expressões do usuário. Para cada funcionalidade cronometrávamos o tempo.

testes com usuarios

Infelizmente o resultado não foi o esperado. A maioria dos usuários se perdiam e não conseguiam realizar a tarefa da forma que queríamos. Até mesmo para um usuário com grande afinidade com interfaces de aplicativos móveis, demorou cerca de cinco minutos para realizar uma funcionalidade. Não houve nenhuma atividade onde a média tenha sido menor que de 1min30s.

Entrega da sprint


Com o resultado nada bom, fomos apresentar tudo o que foi feito para o Jeff e o Ney que não gostaram do que foi entregue. E ainda levamos uma “bronca”, porque não focamos em soluções que estavam previstas, e por não trabalharmos efetivamente junto aos desenvolvedores, que começaram a “codar” antes de validarmos as hipóteses por meio do protótipo.

Depois de entregarmos um trabalho nada satisfatório, entendemos que deveríamos trabalhar juntos até chegarmos a uma solução ideal.


No último capítulo da nossa jornada, contaremos o que fizemos na terceira sprint para corrigir nossos erros. Como foi o resultado da segunda fase de testes e se os nossos clientes ficaram satisfeitos ou não com a solução que entregamos.

 

Autores: Carol Cabral e Vinicius Rocha