Consegui meu primeiro emprego em UX design, e agora?
5 conselhos que eu queria ter recebido quando comecei
O início
Embora tenha uma grande bagagem no design gráfico, nunca tive muito contato com o digital (não que UX seja só digital, mas esse é meu caso agora). Fiz alguns cursos na área, mas não tinha nenhuma experiência para além dos cases de estudo. Um dia, eis que surgiu uma vaga dos sonhos, como designer UI/UX júnior num ambiente de startup em pleno crescimento e. mesmo sem experiência, eles apostaram em mim. Uau!
Só que como fui a primeira designer da empresa, era também a única! Como eu não tinha parâmetro nenhum para começar a desenvolver um processo de trabalho, eu tentei puxar aquela caixa de ferramentas de que tanto falam nos cursos, só que a verdade é que, embora eu entendesse as etapas e alguns processos, a prática é outra história.
O início foi bastante difícil com momentos de “isso não é pra mim” e “estou fazendo tudo errado”. O fato é que a gente nunca vai saber saber tudo mas, na época, eu achava isso um problema (spoiler: não é!) Para essa minha eu do começo, eu diria hoje: calma! E também me daria essas dicas, que você, se for iniciante como eu, pode achar úteis.
1. Entenda onde está
Quando você começa numa empresa você provavelmente não vai chegar no dia 0 do projeto/produto/ideia/etapa e pode, inclusive, não fazer ideia de que dia seja nesse processo para saber por onde começar. Se a empresa tiver um P.O. ou um P.M. (eu sei, jargões da área, google neles!) é muito provável que eles já saibam que momento é esse e consigam te localizar em termos do que está acontecendo e o que esperam que você faça. Se não for o caso, esse tipo de informação pode estar dispersa entre os stakeholders, e pode ser até mesmo que nem eles concordem sobre qual é esse momento.
A necessidade sempre vai ser, simplificando: melhorar o produto e (ou para) ter mais clientes.
O que já são alguns pontos de partida! Antes de tudo, você precisa entender o que a empresa espera com aquele produto ou serviço, quem são os [potenciais] consumidores e o que já foi feito até ali. Você não vai conseguir extrair todas essas informações de uma vez só, mas o importante é sempre buscar por elas e tê-las em perspectiva.
Quanto mais informação você tiver, melhor a sua compreensão do que está desenvolvendo.
Mas não se iluda, sempre haverão informações novas e algumas podem fazer você precisar rever o que já estava dado como certo. Nunca dá tempo de ficar muito confortável. É normal!
2. Mapeie os fluxos
Meu primeiro trabalho nesse novo emprego foi analisar a usabilidade de um sistema que já estava desenvolvido e levantar os problemas e pontos de melhoria. Fiz um relatório imenso no Word (!) que não deu nem tempo de ser todo verificado (que dúvida!). Foi aí que apareceu o primeiro conflito: eu precisava aplicar as tais melhorias propondo mudanças na interface. E eu não sabia nem como começar.
Como passar do: a organização está confusa para uma organização não confusa? Que tipo de ferramenta ou método eu aplico nesse momento?
Na ansiedade de entregar algo, eu pulei direto para o fim: o que eu fiz foi sair desenhando interface achando que podia resolver alguns problemas meramente pela arquitetura visual (alguns de fato, só precisavam disso mesmo).
Com ela “pronta”, os desenvolvedores começaram a me questionar o que acontecia quando clicava no botão X, para onde ia depois da ação Y, o que significa esse filtro aqui? E eu percebi que eu criei uma tela e não um produto. Fluxos!
Toda ação gera uma reação e você, enquanto UX designer, é responsável por pensar isso.
Antes de sair desenhando tela, ou mesmo wireframe, entenda o que é preciso fazer na plataforma, mapeie as ações e quais resultados serão atingidos com elas.
Reflita sobre como você pode tornar essa ação simples ou como quebrar em etapas se for uma ação complexa. Você pode aplicar ferramentas como Journey Map, Jobs-to-be-done, Fluxo de Tarefas, enfim, é esse o momento.
Aprenda também a documentar isso de uma forma que os desenvolvedores entendam. (Eu confesso que ainda estou aprendendo a fazer isso!) O que nos leva para a dica 3.
3. Desenvolvedores são seus amigos
Já tinha lido isso por aí e pensei: mas é claro que sim, por que não seriam? A questão é como desenvolver esse diálogo com os desenvolvedores de modo a alinhar planejamento e execução, combinando escalabilidade, prazos e princípios de design e usabilidade que não podemos abrir mão.
Eu passei por dois grandes momentos: a primeira vez que vi uma interface implementada (e fiquei maravilhada) e depois quando eu comecei a analisar em profundidade essa mesma interface e percebi que “o MEU botão não tá certo”, “o espaçamento não era esse” etc. etc.
Bom, em primeiro lugar, a arte não é sua, ela serve a um propósito: garantir a melhor solução para o usuário e essa solução não se constrói sozinha, ela é o resultado de um trabalho em equipe .
Também não se apegue ao “seu” layout, pois ele vai mudar (e muito) ao longo da vida do produto. Mas ok. Por que na implementação a interface não é igual?
O tal botão ou os espaçamentos (que viram no código paddings e margins) não são só um elemento de layout, eles fazem parte de um sistema, ou seja, é um componente que precisa ser pensado em termos de usabilidade — e é sua função garantir isso! — e também de otimização em desenvolvimento.
A consistência não é só visual, ela acontece também no código.
A aparência final da interface é uma combinação entre o seu projeto e a personalização de componentes vindos de bibliotecas/frameworks já empregados. Por isso, o diálogo é importante. Às vezes, por exemplo, um elemento ou alinhamento especial (que não é essencial para a usabilidade) acaba “sujando” o código por criar uma exceção não prevista no componente. E isso pode ter inúmeras consequências: além de mais trabalho para os desenvolvedores, várias exceções no código tornam ele mais pesado, impactando no tempo de carregamento de uma página que, por sua vez, impacta na usabilidade. Ou seja, o problema voltou para o design!
Claro, também é preciso defender suas decisões de design, pois alguns pontos podem realmente gerar atrito durante a experiência de uso. Afinal, você não deixou aquelas coisas lá porque é bonito, mas sim, porque levou em consideração modelos mentais do seu usuário e possivelmente testes que você executou.
O caminho é encontrar um equilíbrio entre o que você pode adaptar para privilegiar velocidade e escalabilidade, e o que é essencial em termos de experiência do usuário. Converse sempre com os desenvolvedores.
4. O processo não é linear
Nada como uns bons exemplos práticos para entender como isso pode acontecer de diversas formas.
Exemplo 1: Você fez uma entrega, ela está em desenvolvimento e alguém do back-end vem dizer que a lógica ficou muito complexa e isso vai deixar o sistema lento, precisa rever a solução proposta. As causas podem ter sido 1. um problema de planejamento anterior ou 2. uma coisa que foi verificada na prática mesmo. Talvez você precise abrir mão de algumas coisas, rever outras, quem sabe adiar alguma funcionalidade ou mesmo abandonar totalmente alguma ideia.
Exemplo 2: Alguém do front-end vem te falar que faltou uma tela entre um fluxo e outro ou, que o que você desenhou não dá pra fazer agora, pois falta tempo ou conhecimento disponível. Você vai precisar desenvolver uma solução intermediária, menos complexa, mas que atenda à tarefa principal que o usuário vai realizar. (alô, MVP!)
Exemplo 3: Você finalmente conseguiu fazer alguns testes com usuários e percebeu que um fluxo está gerando problemas. Só que agora você precisa rever não só os fluxos como também a arquitetura de informação.
Exemplo 4: Um projeto já entregue está com problemas e precisa urgente de uma revisão. Você interrompe tudo o que está fazendo e volta para o projeto que parecia finalizado. Uma das maiores lições do desenvolvimento de produtos é bem sobre isso:
Produtos e serviços digitais nunca estão finalizados, sempre haverá o que melhorar, o que revisar, o que expandir e até mesmo o que deixar para trás.
Exemplo 5: Bom, você estudou o problema, fez ajustes, testou e entregou e agora vai finalmente voltar para aquele projeto que deixou em aberto. Aí, quando olha para ele de volta, depois de ter passado por essa interrupção para ajustes do outro projeto, percebe que o caminho que estava seguindo não é adequado. A experiência que teve com o outro processo te permite perceber que tipos de problemas podem surgir. Mas sabe o que é legal?
Agora você é capaz de identificar isso antes de o projeto avançar, o que significa ganho de tempo para todo mundo. É aquela máxima dos processos ágeis: “Falhe cedo, aprenda rápido”.
5. Entenda os porquês
Esse na verdade deveria ser o conselho 2, mas como foi a última coisa que aprendi, vai ficar aqui. Muitas vezes, eu ficava preocupada em melhorar alguma ponta do produto, fazia alguns testes e chegava a uma solução satisfatória. Porém, não me perguntava o porquê essencial da ação. Esse post do instagram da @anfisign foi um divisor de águas para mim.
Ao atacar somente o como, geralmente acabamos gerando soluções mais visualmente atraentes, mas não enxergamos todo o potencial da ideia. Ao entender o porquê, podemos acabar gerando soluções totalmente novas, não necessariamente mais bonitas mas, definitivamente, mais adequadas.
Às vezes chegamos de fato a boas soluções somente atacando problemas, mas se investigarmos a fundo a questão, outras soluções melhores, mais práticas, mais rápidas, menos custosas ou mais interessantes podem surgir.
Uma vez, em uma entrevista com um cliente, ele relatou que precisava de uma funcionalidade X porque Y. O motivo parecia muito claro, mas, como eu já sabia que a funcionalidade X poderia requisitar um grande armazenamento de dados, eu perguntei o porquê de ele precisar de X. Então o cliente contou que tipos de problemas ele poderia ter se não tivesse X. Entendendo isso, eu pude pensar na solução Z, que resolvia igualmente o problema e ainda facilitava o desenvolvimento, até onde eu sabia. No final, após uma conversa com o P.M. e os desenvolvedores, a solução definida acabou sendo H!
Desde esse episódio, tenho tentado entender mais os porquês e menos os comos. Isso pode parecer óbvio, mas para quem está começando, é muito tentador se apaixonar por uma ideia, ainda mais quando parece ser “exatamente o que o usuário quer”, porém nem sempre o que o usuário quer é viável ou faz sentido para o negócio, e isso precisa ser levado em consideração.
Pra finalizar
No mundo mundo ideal conseguimos sempre aplicar todo o processo de design etapa por etapa, fazer todas as pesquisas que queremos e coletar insights geniais falando com os usuários. Mas no mundo real, nem sempre isso é possível. O importante é identificar quando o momento é propício para aplicar algum desses métodos e também, sempre mergulhar no problema antes de sair criando algo que você nem entendeu direito para o que é.
Por fim, é preciso se lembrar que ninguém sabe tudo e todos estão em processo de aprendizagem constante, sejam seus pares até seus chefes.
Lidar com a incerteza dessa área pode ser realmente desafiador e por vezes frustrante, mas entre uma incerteza e outra você vai descobrir muitas possibilidades. Toda aprendizagem é um ganho exponencial.
Conforme você vai praticando mais e mais, mais consciente você se torna da sua evolução. Ter percebido esses pontos que levantei, me ajudaram muito a ganhar confiança no meu trabalho.
E vocês, como está sendo ou como foi o início da sua carreira como UX designer? Falem nos comentários se vocês se identificaram ou se tem algum outro ponto legal de trazer e que eu não citei aqui :)
