FCalendar: sistema de agendamento e controle de capacidade de funcionários
Processo de UX e UI design de um sistema de agendamento e controle de capacidade de funcionários para apoiar a reabertura dos escritórios do Grupo FCamara. Este case é parte do Programa de Formação Season 2 do Grupo FCamara, 2021.
O DESAFIO
Com a pandemia da Covid-19 muita coisa mudou. O trabalho remoto não foi uma opção, mas sim necessário e assim se foram quase 2 anos de home office. Porém, hoje com a vacinação em andamento, já podemos enxergar novas possibilidades, e aqui na FCamara não é diferente. Com muito cuidado e segurança estamos planejando a reabertura dos nossos escritórios.
O desafio então era criar uma aplicação web onde os consultores da empresa pudessem realizar um agendamento para poder ir ao escritório. O objetivo era criar uma forma automatizada de organizar essa ida, de modo que os funcionários pudessem retornar com segurança à empresa, caso assim desejassem.
INTRODUÇÃO
Nossa equipe fez parte do Squad#23, composto por mim, UX Designer, e três desenvolvedores. Stefânio Soares Junior ficou responsável pelo front-end e Natã Menezes e Matheus Honorato pelo back-end do projeto.
Os desenvolvedores do squad não estavam muito familiarizados com o processo de UX design, então, em nossa primeira reunião, sugeri que usássemos o processo de design sprint de forma adaptada ao conceito original, expliquei as 5 etapas que percorreríamos nos próximos 15 dias de trabalho. Plano aprovado.
Terminamos a reunião inicial com um bom alinhamento sobre nossos próximos passos e iniciei minhas pesquisas enquanto os desenvolvedores decidiam as linguagens que usariam e distribuíam suas funções.
MAPEAMENTO
Na fase de mapeamento, reuni informações sobre o Grupo FCamara, seus funcionários e suas necessidades, possibilidades técnicas viáveis para a nossa solução e também sobre as nuances e diferenças entre o desenvolvimento de aplicações para uso interno de uma empresa e aplicações para um público geral. Para isso, passamos pelas fases abaixo.
- Pesquisa desk
- Pesquisa de usuário
- Definição dos princípios do design
- Criação do Mapa da empatia
- Criação da persona
- Benchmark
Pesquisa desk
Como precisávamos desenvolver uma solução para os próprios funcionários do Grupo FCâmara, realizei uma pesquisa desk para reunir informações sobre o posicionamento e valores da empresa, assim como sua culture code e perfil de seus funcionários.
Os dados foram coletados do site institucional, do perfil do LinkedIn, de documentos disponíveis no SlideShare e do Brandbook da empresa que nos foi disponibilizado.
Os principais insights da pesquisa desk foram:
- Posicionamento da empresa: valorização de pessoas, trabalho em equipe e soluções simples e eficazes.
- 69% dos funcionários moram em São Paulo e região.
- 57,5% trabalham na área de engenharia e 11% em tecnologia da informação.
- 33% estudou Tecnologia da informação e 14% Análise de sistemas de computação.
- 77% com sexo biológico masculino.
Em relação aos estudos sobre o desenvolvimento de ferramentas internas, para minha surpresa, percebi ser muito comum empresas não valorizarem a experiência dos usuários ao desenvolver ou adquirir uma ferramenta interna, como, por exemplo, um sistema de ponto eletrônico ou um sistema de comunicação interna.
Assim, recolhi alguns insights interessantes que nos ajudaram a construir nossa solução tendo sempre em mente uma boa experiência dos nossos usuários.
- A qualidade das ferramentas internas precisam refletir o posicionamento da empresa.
- Os usuários (no caso, os funcionários) devem sentir genuinamente que o produto está agregando valor.
- É importante surpreender e encantar os usuários, pois tradicionalmente as ferramentas corporativas parecem muito funcionais e secas.
Concomitantemente a essa esta pesquisa, iniciei os estudos sobre os usuários.
PESQUISA DE USUÁRIO
Questionário
Para conhecer melhor os famosos #SangueLaranja, elaborei um questionário para recolher informações demográficas e opiniões sobre o trabalho remoto e sua produtividade.
Antes de iniciar a coleta do dados, pedi feedback do squad em relação às perguntas elaboradas e também ao bom funcionamento da ferramenta de formulário que escolhi.
Recebemos 30 respostas e as principais informações foram:
- 91,3% estão exclusivamente em home office.
- 73,9% gostam de trabalhar em casa.
- 52,2% têm entre 21 e30 anos.
- 65,2% são homens de nascença.
- 47,8% são brancos e 8,7% pretos.
- 100% não possuem deficiência.
- 66,7% são solteiros.
- 94,4% não têm filhos.
- 55,6% têm animal de estimação.
Além disso, os respondentes nos ajudaram a resumir os principais pontos positivos e negativos do trabalho remoto.
Entrevistas
Ao final do formulário de pesquisa, criei um campo para que as pessoas pudessem deixar seus contatos caso quisessem colaborar mais com nosso projeto.
Assim, consegui realizar 6 entrevistas para entender mais profundamente as dores e necessidades dos consultores. Os objetivos das entrevistas eram saber se os usuários:
- Pretendiam aderir ao trabalho híbrido. Se sim, quantos dias seriam ideais para eles.
- Tinham alguma preocupação com o retorno ao trabalho no escritório.
- Gostariam de poder escolher suas estações de trabalho.
Após as entrevistas, reuni as informações que nos ajudariam a construir a persona para nossa solução:
- Todos os entrevistados entraram na empresa durante a pandemia. Não vivenciaram muito a experiência do trabalho presencial.
- Todos têm a preocupação de que seus colegas sigam as regras de segurança (distanciamento e máscara) para prevenção da COVID-19.
- A maioria dos entrevistados pretende ir presencialmente apenas para reuniões importantes, por pedido de clientes etc.
- A maioria deles alegou que preferem ter flexibilidade para escolher sua estação de trabalho.
- Todos os entrevistados dizem ser importante o contato com os colegas para conhecê-los melhor e mudar um pouco a rotina.
- Todos os entrevistados gostam de trabalhar em casa.
- Duas vezes por semana seriam suficientes para ir ao escritório.
A partir das pesquisas, ficou claro para o squad quais seriam os princípios do design que adotaríamos para desenvolver nossa solução.
Princípios do design
Decidimos então que para criarmos uma solução ideal para nosso cliente, o Grupo FCamara, de modo a surpreender e encantar os usuários, precisávamos ter em mente sempre três princípios:
Simplicidade
SER, PENSAR, FAZER = SIMPLES. Acreditamos que o
simples é o mais eficaz. (#CultureCode do Grupo FCamara)
Para refletir os valores da empresa, decidimos que precisávamos criar uma solução que fosse rápida, fácil e acessível, com o mínimo de telas possível.
Colaboração
Criamos TIMES de alta performance e não estrelas. […] Atingir JUNTOS a expectativa. (#CultureCode do Grupo FCamara)
Ficou muito claro para nosso squad que o Grupo FCamara valoriza muito a colaboração entre seus funcionários e por isso queríamos encontrar uma forma de incentivar a colaboração entre a equipe.
Promoção da segurança
Estamos analisando com cautela e formalizando protocolos para reabrir nossos escritórios de forma gradual, tanto para o nosso time quanto para os nossos visitantes. (Plano de retomada gradual do Grupo FCamara)
O Grupo FCamara tem demonstrado muita preocupação e cuidado ao planejar o sistema híbrido de trabalho. Isso fica muito claro no Plano de Retomada Gradual e no fato de a empresa solicitar o desenvolvimento de uma solução para evitar superlotação de seus escritórios.
Assim sabíamos que nossa solução precisava refletir esse cuidado com a saúde dos colaboradores.
Mapa da empatia
Com todos os dados coletados, chegou a hora de empatizar com nossos usuários. Decidimos usar o Mapa da Empatia para entendermos o perfil da persona para nossa solução.
O resultado apontou 3 grandes dores dos nossos usuários:
- Medo dos colegas não seguirem os protocolos de segurança.
- Necessidade de sentir-se seguro no ambiente de trabalho.
- Vontade de interagir presencialmente com os colegas, mas com segurança.
Persona
Assim, chegamos ao momento de criar a persona da nossa solução.
Pedro Rodrigues, desenvolvedor full stack na FCamara, 26 anos, mora em São Paulo com a mãe. Pedro entrou na empresa durante a pandemia, então não conhece seu time pessoalmente.
É um cara reservado, gente boa e que gosta muito de ter autonomia para organizar o próprio cronograma de trabalho, pois quer ter tempo para brincar com seu cachorro e resolver questões pessoais. Ele está sempre atento a e-mails e comunicados do trabalho e quer encontrar os colegas, mas só esporadicamente e com segurança.
Benchmark
Antes de iniciarmos os rascunhos da nossa solução, fizemos um benchmark para conhecer soluções similares a que iríamos construir. Na pesquisa, comparamos funcionalidades, acessibilidade e design visual de 3 ferramentas de agendamento e gestão de capacidade de funcionários.
Por se tratar de sistemas internos, as informações foram baseadas apenas em vídeos demonstrativos e informações do sites institucionais, não sendo possível analisar acessibilidade e usabilidade dessas soluções sem que marcássemos uma demonstração ao vivo com consultores.
Mas o benchmark foi muito útil para nos dar ideias de possíveis funcionalidades da nossa aplicação.
DESENHOS E ESBOÇOS
Chegamos então na fase de desenhar e esboçar nossa solução. Antes de começarmos, trabalhamos para definir nossa declaração de problema e nossa proposta de valor.
Declaração do problema
Ter uma declaração de problema bem escrita e clara permite alinhar a equipe ao longo de uma meta concisa de modo que nossos esforços sejam direcionados a um objetivo comum. Por isso, nosso squad se reuniu e juntos chegamos à seguinte declaração:
Pedro é um desenvolvedor full stack que precisa sentir segurança para se encontrar presencialmente com seus colegas de trabalho no dia e horário que desejar, porque valoriza muito a troca direta com seu time e sua segurança.
Com essa declaração, entendemos que precisávamos desenvolver uma solução que passasse segurança ao Pedro ao mesmo tempo que valorizasse a colaboração entre ele e o time e, ainda, permitisse a ele ter um cronograma de trabalho flexível.
Proposta de valor
Fizemos, então, duas dinâmicas de toró de ideias (brainstorming) no Miro para definirmos a nossa proposta de valor. Num primeiro momento, cada uma de nós tinha que responder à pergunta:
O que o nosso produto faz? Escreva características e benefícios.
Foi o primeiro momento em que a equipe começou a pensar e registrar as características e benefícios do que queríamos construir. Foi uma dinâmica de aquecimento para ativar a criatividade e fazer com que todos focassem na solução. Depois, respondemos às perguntas:
Por que nossos usuários precisam ligar para nosso produto? Como surpreenderemos nossos usuários?
A partir do que todos escreveram, votamos nas declarações que julgamos que fariam nossos usuários se encantarem pela nossa solução. E chegamos a quatro itens:
- Nossa solução é rápida, fácil e acessível.
- Permite convidar colegas.
- Aproxima o usuário do seu grupo de trabalho.
- Promove a colaboração com segurança.
Assim, chegamos a nossa proposta de valor:
Para funcionários da FCamara que querem adotar o regime híbrido de trabalho, ter flexibilidade para encontrar seu time e ainda sentir-se seguros com esse retorno ao presencial, oferecemos um sistema de agendamento e controle de capacidade de funcionários rápido, fácil e acessível.
Golden path
Com a declaração do problema e nossa proposta de valor prontas, partimos para mais um toró de ideias. Dessa vez, nosso foco era nas funcionalidades que precisávamos para refletir nossa proposta de valor.
A partir das informações registradas, decidimos criar o golden path dos nossos usuários, ou seja, as principais etapas que um usuário executa para encontrar o valor real de um produto. Nesse momento, não nos concentramos em em exceções ou erros.
Inicialmente, nosso golden path não tinha as telas de onboarding. Elas foram incluídas após um estudo de UX Writing que detalharei mais adiante.
DECISÃO
Chegamos na fase em que os desenvolvedores ficaram mais felizes hehe. A fase de decidir o que e como realmente íamos construir nossa solução. Com base no nosso golden path, criei wireframes e juntos conversamos e decidimos o conteúdo e funcionalidades de cada tela.
Passei, então, a concentrar minhas pesquisas e trabalho nas microcópias, ou seja, nos textos que usaríamos na interface. O brandbook do Grupo FCamara ajudou muito ao oferecer de forma clara o tom e a voz da marca.
Somos adaptáveis, logo sempre pensamos pra quem e onde estamos falando. Usamos uma linguagem do dia a dia, ou seja, falamos e escrevemos de um jeito fácil. Assim, mostramos que estamos sempre abertos a novas ideias, que valorizamos a troca de conhecimentos e que impulsionamos a criação de novas conexões. (Brandbook do Grupo FCamara)
Assim, trabalhei para que nossa comunicação com os usuários fosse como um diálogo simples, direto e pessoal. Com uma linguagem do dia a dia, mas sem exagerar na informalidade. Nosso sistema cumprimentaria os usuários e faria perguntas simples para que eles pudessem executar as tarefas.
Ao finalizar os textos, passei a refletir sobre SE nossa solução estava realmente transparecendo aos nossos usuários os nossos três princípios:
- Simplicidade
- Colaboração
- Promoção da segurança
A simplicidade está estampada no nosso wireframe: poucas telas, pouco texto, poucas funcionalidades. Entretanto, naquele momento, percebi que apenas inserir uma funcionalidade para convidar colegas NÃO passaria a mensagem que valorizávamos a colaboração e que só uma mensagem de confirmação final pedindo aos funcionários manterem a distância NÃO estaríamos promovendo a segurança.
Foi então que o squad se reuniu e decidimos criar 3 telas de onboarding que só apareceriam na primeira vez em que um usuário acessasse o sistema. Com essas telas, queríamos:
- Apresentar todas as funcionalidades do sistema.
- Mostrar que os usuários poderiam convidar seus colegas para trabalhar com eles, como uma forma de promover a colaboração.
- Informar que os usuários teriam flexibilidade de escolher sua estação de trabalho, já que pela nossa pesquisa os funcionários não achavam interessante que tivessem que reservar uma mesa específica.
- E criar um termo de compromisso simples em que os usuários deveriam se comprometer a seguir os protocolos de segurança.
Assim, chegamos ao nosso wireframe com 3 telas adicionais.
PROTOTIPAÇÃO
Com nosso wireframe aprovado, precisávamos decidir o nome do nosso sistema e iniciar a criação do nosso protótipo no Figma. Fizemos um toró de ideias de nomes e chegamos ao FCalendar.
A partir daí, criei nosso guia de estilos seguindo as cores da marca FCamara e ilustrações como sugeridas no brandbook da empresa. Iniciei, então, a construção do protótipo e segui o método Mobile First e assim chegamos ao nosso protótipo. Acesse o link do protótipo interativo.
Fizemos uma reunião para decidirmos os últimos ajustes do protótipo e iniciei os testes de usabilidade.
VALIDAÇÃO
Para a validação da nossa solução, decidimos criar 3 tarefas para que usuários reais testassem as funcionalidades e nos dessem feedback sobre a experiência.
Para os testes, optei por usar a ferramenta de teste de usabilidade remoto Maze, pois ela gera um relatório bem completo e otimiza nosso tempo ao automatizar as tarefas.
Tarefa 1: Apresentação do aplicativo
Essa foi a tarefa que mais me dediquei a encontrar usuários para realizá-la, pois apostamos nossas fichas nas telas de onboarding para passar a mensagem de simplicidade, colaboração e segurança. 23 pessoas participaram desta tarefa.
— —
Como funcionário(a) da FCamara, você passará a usar o FCalendar para agendar suas idas presenciais ao escritório. Esta é a primeira vez que você usa o aplicativo.
Sua tarefa:
- Faça o login.
- Passe e leia as páginas iniciais até chegar à tela para ver agendamentos e agendar idas ao escritório.
— —
Ao final, os usuários tinham que responder a duas perguntas obrigatórias:
Quase 90% das pessoas receberam nossa mensagem como gostaríamos. Os usuários também podiam deixar comentários com sugestões de melhorias. E acatamos à sugestão de mudar o título da segunda tela de onboarding que era Colaboração para Convide colegas.
Tarefa 2: Agendar e convidar um colega
11 pessoas realizaram a seguinte tarefa:
— —
Você precisa agendar sua ida ao escritório de São Paulo, no dia 10 de setembro, no turno da tarde. E quer convidar seu colega Bruno Alcântara Silva para ir com você.
— —
Os resultados mostraram que todos os usuários consideraram a tarefa simples e rápida.
Tarefa 3: Agendar e não convidar um colega
9 pessoas realizaram a seguinte tarefa:
— —
Você precisa agendar sua ida ao escritório de São Paulo, no dia 10 de setembro, no turno da tarde. E não quer nenhum para ir com você.
— —
Novamente, os resultados mostraram que os usuários estavam satisfeitos com simplicidade e rapidez da tarefa. As partir de sugestões de alguns, fizemos as seguintes algumas alterações em nosso protótipo.
Tela de agendamento
Nós queríamos permitir que os usuários selecionassem os períodos Manhã, Tarde ou Manhã e Tarde (ambos). Inicialmente, optamos por usar checkbox, mas algumas pessoas nos reportaram que deveríamos dar a opção de selecionar os dois períodos.
E assim percebemos que não estava claro para eles que o checkbox permitia escolher apenas 1 turno ou os 2 turnos. Assim, trocamos para radiobuttons e adicionamos a opção Ambos.
Tela de confirmação
Para a tela de confirmação (tela final), nos sugeriram adicionar um link para que fosse possível que as pessoas lessem os protocolos de segurança mais detalhadamente. Acatamos, pois consideramos que essa mudança traria ainda mais segurança aos #SangueLaranja.
ACESSIBILIDADE
Um dos meus objetivos da vida profissional é promover acessibilidade e inclusão, por isso desde o início do meu processo de design eu tentei levar em consideração diversas formas de acessibilidade.
Ressalto que o trabalho de acessibilidade deve ir muito além do que o que realizamos para nosso MVP.
Daltonismo
Ao escolher as ilustrações, fiz vários testes de cores com o plugin Color Blind do Figma para ver se todos os usuários com algum tipo de daltonismo conseguiriam ver a ilustração perfeitamente sem perda de informação. Não foi um processo fácil, mas considero muito necessário.
Destaco que existem outras funcionalidade possíveis de serem adotadas para promover uma melhor experiência aos daltônicos. Abaixo um exemplo de um frame que simula diferentes tipos de daltonismo.
Audiodescrição de imagens
Eu sou da área de educação, mais especificamente do ensino de línguas, e eu acredito que a linguagem tem o poder de aproximar, acolher e transformar a sociedade.
E tenho me dedicado muito à promoção de linguagens inclusivas e um dos passos que tomei foi fazer um curso de audiodescrição de imagens estáticas, com uma grande amiga e profissional da área, professora Doutora Deise Medina, do Instituto Federal da Bahia.
A professora Deise desenvolveu uma metodologia para audiodescrição de imagens que permite que descrevamos imagens de forma a oferecer às pessoas com deficiência visual o mesmo direito de compreensão de imagens que as pessoas que enxergam.
Eu fiz a audiodescrição de todas as imagens da nossa aplicação e enviei para a Deise Medina para que ela pudesse sugerir melhoras. Abaixo, trago dois exemplos finais. Ressalto que essas descrições devem ser inseridas no código HTML para que leitores de telas possam interpretá-las.
CONSIDERAÇÕES FINAIS
Este foi meu primeiro hackathon e o processo de UX/UI design foi muito interessante e me trouxe muitos aprendizados. Nosso squad se esforçou muito para entregar uma solução simples, útil e que trouxesse valor aos usuários.
Esperamos que a utilização do FCalendar seja tão prazerosa quanto a construção dele, e acima de tudo, que ele ajude a promover na FCamara a colaboração com segurança.
Gratidão.
