11 coisas que aprendi no meu primeiro ano de trabalho como UX/UI Designer em uma software house

Na verdade, faz mais de um ano desde que comecei meu primeiro trabalho como UX/UI Designer em uma software house. Embora algumas pessoas pensem que não é o melhor lugar para começar sua experiência de UX/UI por causa da variedade de projetos e da independência necessária, não tive muitos problemas com isso. Eu trabalhava como assistente de arquitetura para um estúdio bastante grande e “freelancer” para uma organização estudantil de relações públicas e design gráfico.

No entanto, nem tudo foi sol e arco-íris . Levei menos de quatro meses entre a decisão de renomear e o início do meu primeiro emprego e, como resultado, não consegui aprender e entender todas as áreas necessárias para o cargo. Em geral, os juniores não aprendem muito sobre a importância da cooperação entre diferentes equipes nas empresas, principalmente a parte de negócios e vendas do projeto.

Aqui estão alguns problemas que encontrei durante meu primeiro ano em UX/UI design:

1.MVP e KPIs

Esses foram conceitos quase completamente estranhos que encontrei enquanto trabalhava em meu primeiro projeto. É certo que era um projeto interno, mas o trabalho era casual e pude perguntar a todos os participantes do projeto sobre várias questões. Foi quando conheci os analistas de negócios e seu papel no projeto. Aprendi sobre o lado comercial dos produtos, que, como descobri, é a parte mais essencial deles nas software houses. Tendo experiência em um setor anterior, MVPs e KPIs podem ter existido escondidos sob outros nomes, mas a determinação prática deles durante workshops com clientes foi o que experimentei aqui.

2. Requisitos de negócios, coleta de requisitos, confirmação deles com o cliente, realização de confirmações

Na minha opinião, esta é a parte mais essencial do trabalho de um designer de produto. Na empresa, eu era parcial ou totalmente responsável por levantar os requisitos e confirmá-los com o cliente — às vezes em parceria com um analista de negócios que penetrava delicadamente na estrutura do cliente e levantava os requisitos do negócio. Nesta fase, é essencial conhecer o setor e os processos do cliente, explicar ao cliente por que estamos fazendo isso (se ele não souber) e, de fato, coletar consistentemente essas informações sobre o produto que está sendo projetado. Fiz isso anotando histórias de usuários, critérios de aceitação e riscos potenciais. Para o cliente, o aspecto visual do produto que nos encomenda já é importante nesta fase, pelo que a forma mais atractiva de recolher tais requisitos é fazer mockups mid-fi, ou seja maquetes com conteúdo parcialmente proposto. É importante lembrar que esta é uma das muitas propostas que podem ser apresentadas, portanto não vale a pena se apegar a tal versão do projeto. Nessa etapa, você também precisa ter em mente a clareza do fluxo de informações — estabelecendo como os requisitos são coletados e confirmados pelo cliente. Sem fechar esta etapa, não é possível avançar no desenvolvimento por causa dos riscos potenciais — alterar decisões tomadas ou adicionar novos requisitos, o que afeta o cronograma do projeto. Acontece também que criamos um produto, coletamos requisitos, talvez já estejamos na fase de aceitação de documentação ou mesmo de desenvolvimento, e de repente o negócio (ou seja, usuários) declara que não entende o processo.

3. Estimativa de tempo — subestimar ou superestimar

O fato é que a maior parte do tempo é gasta na criação de maquetes, na personalização de bibliotecas existentes ou na criação de bibliotecas personalizadas e na redação de documentação. Freqüentemente, é muito difícil para designers iniciantes estimar o tempo que gastarão nisso e, de alguma forma, eles precisam. Várias vezes subestimei o tempo gasto em uma determinada tarefa, e uma vez até superestimei, mas, a meu ver, essa habilidade vem com a experiência. É bom ter um certo intervalo de tempo em tal situação - é sempre melhor entregar algo mais rápido do que atrasado.

4. O leme, a vela e o navio — autossuficiência

Até agora, em minha experiência, só tive que assumir o controle de aspectos menores de projetos, como coordenar instalações nos tetos de quartos e corredores de hotéis ou nas chamadas partes de trás da casa. Como designer de UX/UI depois que fui designado oficialmente para o meu primeiro projeto, eu era muito mais responsável pelo produto, já que era o único designer da equipe do projeto. Por um lado, isso foi enobrecedor para mim, mas, por outro lado, foi muita responsabilidade e confiança geral da empresa. Até agora não sei se me convinha, talvez fosse muito cedo para ser totalmente responsável pelo produto sendo uma pessoa com pouca experiência no ramo. Foi um grande teste para mim, mas pelo que sei, tanto o cliente quanto a equipe ficaram felizes comigo, então acho que consegui executar bem essas tarefas do projeto para aquele momento, afinal

5. Pesquisa na etapa de UX, ou melhor, a falta dela

Os clientes geralmente não têm conhecimento do objetivo de conduzir pesquisas de UX no estágio de design (e, se o fizerem, agradeça ao seu departamento de vendas por um cliente tão informado!). Esta é a desvantagem geral das casas de software. Nas empresas de produtos, pelas minhas conversas em encontros e conferências, ficou claro que, infelizmente, esse também não é o padrão quando se trata do processo de design. Porém, sempre vale a pena fazer a apresentação para o cliente sobre a pesquisa de UX e apresentar porque ela é importante e o quanto pode economizar tempo. O primeiro exemplo da costa — eu estava desenvolvendo um produto cujo processo de negócios era bastante complicado de entender, no fim das contas — não só para mim, porque os usuários não entenderam bem. Juntamente com o cliente, tivemos que voltar à etapa de levantamento de requisitos, reúna-os depois de aprender mais sobre o processo, aprimore os mockups e continue o desenvolvimento. Isso poderia ter sido evitado se tivéssemos um momento para prototipar os mockups e fazer testes de usabilidade com os futuros usuários (funcionários de uma das equipes do cliente). Mesmo assim, teríamos identificado os problemas que surgiram muito depois.

6. Criação de documentação

Este é realmente um trabalho necessário para o cliente verificar. Para criar a documentação UX, usei o artigo detalhado da Autentika sobre como preparar a documentação (https://autentika.pl/blog/po-owocach-uxa-poznacie-czyli-moment-przekazania-projektu-do-wdrozenia/em polonês).

Foi muito útil para mim ao criá-lo, mas não foi 100% suficiente. Os diagramas de processo no produto que eu estava criando na época eram MUITO complicados, então procurei os analistas por um motivo e, com a ajuda deles, criei uma especificação de caso de uso e requisitos de processo mais detalhados com critérios de aceitação. Claro, agora eu faria essa documentação de maneira um pouco mais diferente, mas naquele ponto estava bastante satisfeito com ela.

7. Metodologias? Eles existem? (Não)

A maioria das empresas de software tenta trabalhar de forma iterativa, com uma abordagem individual para o cliente. É difícil planejar processos de livros nessas situações, especialmente porque a pesquisa board-to-board raramente é feita porque “não há tempo” ou você trabalha como único designer. Em última análise, a metodologia de design é baseada no Agile, mas as estruturas são bastante semelhantes entre si e podem ser divididas em estágios de descoberta, definição, design, desenvolvimento e entrega/implantação (como um 5D estendido com um estágio de Double Diamond) .

8. Entendendo o cliente

Este é o núcleo da cooperação com o cliente no nível do design do aplicativo. Muitas vezes, os clientes (especialmente de setores não relacionados a TI) não sabem o que é UX, do que se trata, quais problemas ele pode eliminar nas primeiras etapas do projeto. Um bom exemplo da minha experiência seria quando eu estava apresentando maquetes lo-fi para completar os requisitos de negócios. A reunião também incluiu a equipe de marketing do cliente, que estava muito incerta… sobre o design das maquetes lo-fi. Como não estavam todos na mesma página, voltei a falar sobre o fato de que os mockups eram apenas para a oportunidade de falar sobre funcionalidade e como o produto deveria funcionar. Infelizmente, isso não impediu o marketing de comentar sobre as fontes usadas nas maquetes, que não influenciavam o design do aplicativo naquele ponto do projeto . No fim, o tema foi resolvido rapidamente e foi compreendido, mas o próprio fato de não ter sido de imediato indica que o tema UX é completamente desconhecido nas empresas. Vale a pena fazer uma breve apresentação ao cliente logo no início da fase de projeto, com uma discussão sobre como trabalhamos, o que apresentaremos e até que ponto precisamos da opinião do cliente. E, claro, por que vale a pena para ele.

9. Trabalhando com desenvolvedores

Freqüentemente, os desenvolvedores têm informações muito boas quando se trata de soluções e fazem perguntas muito técnicas e lógicas, o que muitas vezes me deu um bom tópico para pensar em uma solução. No entanto, às vezes eles propõem soluções que são mais simples para eles e não necessariamente boas do ponto de vista do usuário, então aqui é necessário equilibrar adequadamente o que vale a pena propor mudanças e onde vale a pena pará-los e explicar as decisões tomadas.

10. API, JSON, LDAP, orquestradores e outras palavras estranhas

Esses são conceitos-chave para o desenvolvimento de aplicativos que, como UX, você deve conhecer, pois os desenvolvedores e toda a comunidade de TI os utilizam. Conheça-os e você poderá conversar melhor com os engenheiros. Não sabe — pergunte, de preferência no começo, embora para mim o entendimento desses conceitos só veio depois de revisar a documentação de implementação que os desenvolvedores estavam criando — os diagramas de comunicação interna do aplicativo permitiram entender muito quando se trata de sua funcionando.

11. Trabalhando em sprints, projeto diário, planejamento de sprint e retro(especificação)

São reuniões valiosas que dão total controle sobre o que está acontecendo no projeto. Os gerentes de projeto são importantes aqui, intervindo quando necessário (por exemplo, quando o cliente tenta mudar os arranjos), bem como os Scrum Masters se estivermos trabalhando de forma ágil (quase todos os projetos).

Como você pode ver, isso foi um monte de coisas que eu fiquei sabendo quando entrei para TI. Espero que você os ache interessantes e talvez esta lista seja útil para aqueles que estão considerando sua carreira em UX/UI ou mesmo para pessoas que trabalham nesta indústria!