UX/UI Design é Upstream
No artigo de hoje convido você a explorar junto comigo uma parte do sistema Kanban, um sistema popularmente utilizado para controlar fluxos de trabalho de times de desenvolvimento ágeis, parte esta que será o upstream.
Falando em times em desenvolvimento ágeis, você sabia que esse termo é utilizado não apenas para referenciar os desenvolvedores em si?! No ágil quando falamos em time de desenvolvimento estamos nos referenciando a um time multidisciplinar, composto por especialistas de diversas áreas afim de promover sua autonomia e fluidez no trabalho. Ou seja, um time deve ser composto por desenvolvedores, designers, testers, analistas e o que mais for necessário. O grande problema é que esse time só consegue trabalhar em fluxo fluído e sustentável se todas as frentes forem tratadas de modo igualitário, e é sobre essa dor que eu te convido a refletir junto comigo ao longo deste artigo.
Vale ressaltar que essa é uma reflexão focada na atuação de design em projetos ágeis.
Pra começar, um pouco de Kanban
Kanban é um sistema ágil e visual para controle e gestão de fluxo criado na década de 40 pela empresa Toyota. Na época buscava-se uma melhor forma de controlar o estoque dos materiais utilizados na produção e o objetivo era que não excedessem e nem faltassem, mas que tivesse um equilíbrio entre o estoque e a demanda gerada pela linha de produção.
No sistema Kanban existem três elementos importantes:
- CARTÕES
Representam uma tarefa que precisa ser executada. - COLUNAS
Representam o status que a tarefa está neste momento. - QUADRO
É onde as colunas e os cartões são organizados.
Um quadro Kanban terá no mínimo três colunas que irão representar os status de “A Fazer”, “Em Execução” e “Feito”. Os cartões irão correr por elas e assim o fluxo de trabalho além de organizado, será exposto e dará maior transparência ao processo.
Até aqui eu aposto que não te trouxe grandes novidades, mas agora vamos aprofundar…
Por trás do quadro, das colunas e dos cartões existem outros conceitos que, ao meu ver, são muito mais importantes (WIP, métricas, políticas explícitas, classe de serviços, etc.), mas para que esse artigo não fique muito longo, vamos focar nos conceitos que nos interessam neste momento, o upstream e o downstream.
O upstream representa as etapas do fluxo de trabalho onde amadurecemos e validamos as ideias antes de aplicá-las, ou melhor, desenvolvê-las. Já o downstream representa todas as etapas seguintes do fluxo de trabalho, é onde o desenvolvimento realmente acontece.
Como funciona o upstream
O trabalho que precisamos desenvolver "nasce" em algum lugar, normalmente a partir de uma hipótese ou de uma dor de negócio identificada. É então que atribuímos o nome de demanda e a partir deste momento, são iniciadas investigações com o objetivo de clarificar o que precisa ser feito.
Normalmente existem dois tipos de demandas:
Tipo (1) aquela a qual já sabemos o que precisa ser feito ou mesmo como fazer por ser uma questão de legislação, uma melhoria já identificada, etc.
Tipo (2) aquela a qual ainda está em um nível de ideia ou é uma hipótese para se atingir um objetivo de negócio, mas não sabemos qual é a melhor forma de desenvolve-la, se é possível desenvolve-la ou mesmo se é relevante desenvolve-la.
Demandas do tipo (1) e (2) necessitam de discovery, a diferença está que no tipo (1) o trabalho será direcionado ao objetivo pré-estalecido e o fluxo de trabalho será "simples". Irão acontecer reuniões de entendimento, o “mergulho” nos objetivos e regras de negócios, a definição dos fluxos e telas, as spikes de desenvolvimento, validações/testes de usabilidade e por fim, a especificação. Já no tipo (2) o trabalho será exploratório o que fará o fluxo de trabalho ser mais complexo e risco de "surpresas" pode ser grande, como um descarte ou uma resolução inesperada.
Ps: guarde bem as características dessas demandas. Vou citá-las várias vezes.
Upstream é o momento no qual as demandas são refinadas e tem por objetivo não somente organizar a fila de tarefas que passarão pelo desenvolvimento, mas, principalmente, evitar desperdícios e garantir a efetividade da entrega.
A partir do momento que uma demanda está especificada com sua user storie, regras de negócio, critérios de aceite, fluxos, telas e o que mais de informação faz sentido para o produto, significa que é seguro investir no seu desenvolvimento e então pode entrar no fluxo de downstream.
O papel do designer (UX/UI) no upstream
De forma bem direta, o designer exerce um papel de muita importância no upstream pois otimiza todo o fluxo de downstream através de sua atuação focada em investigar, definir como as demandas devem ser implementadas e até mesmo, quais demandas devem ser descartadas, mantendo o backlog do produto atualizado e evitando que o time sofra starvation.
Upstream com design
Naturalmente os profissionais que trabalham com design têm facilidade em conversar com as áreas de negócios, técnica e usuária envolvendo-os no momento certo e facilitando a comunicação entre elas. Sua especialidade é “unir as pontas”, fomentar a colaboração, gerar insights e hipóteses, validar e de quebra, entregar mastigadinho para o desenvolvedor o que é esperado da implementação. Esse processo garante tanto a efetividade quanto a qualidade da entrega, além de como já dito, otimiza o trabalho como um todo e garante que o produto esteja alinhado com o propósito da empresa.
Imagine um processo no qual uma demanda do tipo (2) passou pelo processo de design (UX/UI) e foi descartada, com toda certeza a empresa economizou tempo e dinheiro, e agora pode direcionar seus esforços em algo mais relevante.
Upstream sem design
A ausência do design no processo faz com que a área de negócios e técnica tenham mais trabalho na clarificação da demanda por conversarem com linguagem diferentes e terem objetivos diferentes. No meio deste turbilhão de informações e muitas vezes desentendimentos, é comum que a área usuária seja esquecida. A definição de fluxos e telas acaba caindo muitas vezes para o próprio desenvolvedor e, com tudo isso, a efetividade da entrega ficará comprometida tanto pela qualidade da experiência quanto por sua relevância.
Com tantos problemas e pessoas fazendo atividades que não são de sua especialidade, naturalmente o prazo de entrega será maior e o risco de refação também.
Imagine um processo no qual uma demanda do tipo (2) não foi validada com todas as áreas que deveriam, ou não teve um estudo exploratório da sua relevância. Acredito que você concorda comigo que o risco da empresa desperdiçar tempo e dinheiro acaba sendo muito maior pois, talvez seja entregue e não seja utilizado, talvez tenha uma usabilidade ruim e aumente o contact rate, ou ainda, será entregue de um jeito que não era o esperado. O mesmo poderá acontecer com demandas do tipo (1).
Um case para clarificar
Abaixo você confere dois gráficos de simulação Monte Carlo de um projeto qualquer. Esse tipo de gráfico normalmente é utilizado na gestão de projetos para estimar quando um evento futuro irá acontecer. No caso abaixo, estimar quando a entrega irá acontecer se as condições atuais do projeto se mantiverem.
A simulação contempla a situação atual, ou seja, com a atuação da equipe de design e projeta a entrega com 95% de certeza para o dia três de junho.
Vamos imaginar agora que por algum motivo precisamos cortar custos do projeto e uma das possibilidades cogitadas foi tirar a equipe de design do projeto.
A nova simulação sem a equipe de design projeta a entrega com 95% de certeza para o dia oito de junho. Ou seja, três dias a mais que a simulação anterior (desconsiderando sábado e domingo).
Analisando friamente, apenas os números, talvez o pensamento seja "ok, são apenas mais três dias e a economia é X". Mas te convido a lembrar dos tópicos ali de cima, quando citei "upstream com design" e "upstream sem design".
Trazendo como highlight do upstream com design:
(…) garante tanto a efetividade quanto a qualidade da entrega, além de como já dito, otimiza o trabalho como um todo e garante que o produto esteja alinhado com o propósito da empresa.
Trazendo como highlight do upstream sem design:
A ausência do design no processo faz com que a área de negócios e técnica tenham mais trabalho na clarificação da demanda por conversarem com linguagem diferentes e terem objetivos diferentes. No meio deste turbilhão de informações e muitas vezes desentendimentos, é comum que a área usuária seja esquecida. A definição de fluxos e telas acaba caindo muitas vezes para o próprio desenvolvedor e, com tudo isso, a efetividade da entrega ficará comprometida tanto pela qualidade da experiência quanto por sua relevância.
Acho que eu nem precisaria comentar mais nada sobre o quanto não vale a pena arriscar tirar design do processo, mas vou apenas acrescentar que a velocidade como um todo irá mudar.
Imagine que, no caso deste projeto o lead time de design (tempo que um cartão leva para passar por todo o quadro Kanban de design) está cravado em 8 dias. Neste período nosso designer faz o entendimento, experimentação, validação e handoff. Lembrando que no caso deste projeto já aconteceu uma grande discovery anteriormente, então temos uma situação de cadências de demandas do tipo (1) no upstream. Assim quando a demanda chega no downstream o desenvolvedor tem em mãos tudo o que precisa e até mesmo já teve um overview do trabalho pois participou dos momentos de validação.
Imagine agora que todo o upstream será feito pelo próprio desenvolvedor e ele além de ter que fazer o entendimento, terá que definir fluxos e telas, validar e provavelmente o handoff não será feito pois precisa otimizar o seu tempo, então partirá direto para o código pois já teve que perder muito tempo com fases da demanda que não são sua especialidade.
Dito isso, você acha mesmo que a diferença na data de entrega final será de apenas três dias? Você acha mesmo que vale a pena arriscar a qualidade e frustrar o seu cliente? Você acha mesmo que essa "economia" vale a pena?
Desejo final
Normalmente sistemas Kanban e equipes são mais focadas no downstream. Os problemas que ocorrem em tempo de desenvolvimento são considerados os mais críticos e, portanto, os que mais ganham atenção.
Aposto que você já teve clientes ou situações em que o design foi despriorizado ou mesmo retirado do processo para ganhar uns dias na entrega ou economizar. Infelizmente o que as empresas não enxergam é que no final das contas, a conta não fechará. Essa percepção pode ser imediata ou de longo prazo, mas ela irá aparecer. Outra coisa geralmente não percebida é que se existe um problema no upstream, esse problema irá refletir no downstream em algum momento.
Vale lembrar que somente a utilização de um processo end-to-end, que considera upstream e downstream como momentos importantes e de forma igualitária, será capaz de promover benefícios internos e externos ao time que serão infinitamente maiores do que apenas alguns dias de diferença na entrega ou a "economia". No final do dia eu te garanto que sua empresa terá clientes mais satisfeitos, soluções de maior qualidade, propósito atendido e um time mais integrado e feliz por atuar em um projeto que, além de ter um fluxo sustentável de trabalho, tem a certeza de entregar valor ao negócio.
Deixo aqui o meu manifesto por mais projetos com designers, por upstreams mais valorizados e por equipes de produto mais integradas.
Siga o Obj.Exc também no Instagram
Conheça a nossa consultoria em Design Thinking e Inovação
