Nem preciso mentir: mesmo sendo designer, sempre tive muitos pés atrás com ferramentas no-code. Quando eu ouvia falar nessas ferramentas, meu lado programador falava mais alto, entendia que se algo era muito fácil, não teria como funcionar bem, achava esse negócio de no-code “esmola demais”. E para piorar, tive uma péssima experiência com um negócio chamado Unbounce. Não sei como ele está hoje, mas não estava muito bom em 2020, a ponto de eu preferir fazer com-código mesmo.
Mas, eu estava enganado. Há hoje ferramentas excepcionais como o Webflow, que apesar do custo, me parece ter poder para entregar páginas poderosas. Framer parece está evoluindo bem e até o Wix tá deixando de ser sinônimo de site ruim, embora ele continue tendo foco em “pessoas normais que querem fazer um site sozinhas”, diferente das duas primeiras onde o foco são nos designers. O que há em comum em todas elas? Mensalidade.
Por isso mesmo, o meu fascínio do momento é o bom e velho WordPress, que também tem seu construtor de sites sem código. Amado por alguns e não tão amado assim por muitos, o Gutenberg está evoluindo e começando a mostrar a que veio, ainda que possua uma curva de aprendizado desafiadora se comprado ao padrão das interfaces de arrastar e soltar, que definitivamente ele não se encaixa. Enxergo nele maturidade suficiente para grande parte das necessidades que precisamos resolver com esse tipo de ferramenta.
E mesmo com as restrições atuais e a dificuldade de aprendizado, o Gutenberg é uma excelente alternativa por ser WordPress, aquela ferramenta de código aberto cuja comunidade é enorme, há soluções em plugins para praticamente tudo e que pode ser hospedado em qualquer hospedagem barata. Soluções acessíveis para nós e para nossos clientes são necessárias em um mundo onde há ferramentas maravilhosas, mas que tem o cartão de crédito como pré-requisito.
Esse blog ganhará uma seção de tutoriais e certamente falaremos novamente do nosso querido criador da imprensa. Aguardem!
Embora ferramentas de IA estejam presentes no nosso dia a dia desde muito antes do surgimento do chatGPT, é inegável que este trouxe uma nova dinâmica para o desenvolvimento dos nossos projetos, já que agora sim nós temos assistentes virtuais que realmente são assistentes.
Para os desenvolvedores, o uso da IA é algo muito óbvio, pois sabemos que escrever algoritmos é basicamente escrever receitas que a serem executadas pelas máquinas, e penso que os prompts nada mais são do que linguagens de programação de altíssimo nível, totalmente verbalizadas, que tornam a escrita das receitas muito mais próximas da nossa linguagem. Isso, é claro, para não falar dos auto-complete que ficaram ainda melhores.
Prompts nada mais são do que linguagens de programação de altíssimo nivel
Mas, e para nós designers, cuja atividade geralmente demanda muito mais pensamento do que operacional de fato? Ainda que muitas vezes tenhamos uma entrega final muito visual, seja por meio de protótipos interativos, seja por meio de peças gráficas e apresentações, nós não chegamos esse resultado sem interagir com nossos clientes e nosso time, muito menos sem a aura que gira em torno do processo criativo que pertence a cada designer.
Gemini (ou qualquer outro chatbot)
Não poderia começar diferente, pois os chatbots são as ferramentas base nesse processo. No meu caso, a escolha que faço é pelo Gemini pelo fato de que eu já utilizo o pacote Google Workspace e isso torna o produto mais barato e com uma experiência mais integrada com ferramentas como o Drive e Meet. Na minha experiência, o Gemini parece trazer respostas mais conservadoras e “enlouquece” menos, mas acredito qualquer alternativa, mesmo em planos gratuitos, sirva aos propósitos que vou trazer aqui.
Gerar textos e informações: Começando pelo básico, gerar informações textuais para popular interfaces e peças gráficas em estágios iniciais foi o primeiro uso que dei aos chats. Já pensou naquela interface que você precisa preencher uma tabela com vários produtos de uma categoria? Esse é o poder “mais fraco” dos chatbots.
Avaliação de arquivos de texto: O principal uso do Gemini hoje em dia é para tirar insights de transcrições de reuniões. A partir de transcrições que faço utilizando o Buzz (que citarei mais a frente), faço com que o chatbot entenda quais são os próximos passos, comece a construir histórias de usuário, personas, arquitetura da informação e até fluxos para desenvolvimento de protótipos. Os resultados tem sido excelentes, mas depende muito da sua criatividade com os prompts.
E é possível fazer o inverso, adicionando arquivos já prontos frutos de outros processos, como boards do Miro em PDF, manuais de uso e outros arquivos para obter insights, iniciar a ideação para construir fluxos de telas … novamente, tudo depende da sua criatividade! Se souberes dizer o que precisa, vai obter bons resultados.
Avaliação de imagens: Outra utilização interessante, aqui pensando mais como designer de produtos, é a avaliação de imagens presente nesses chatbots. No Gemini, como complemento para as transcrições, posso trazer também telas de sistemas existentes e pedir que ele “combine essas informações” para os fins que precisamos, como por exemplo, um redesign de interfaces.
Também dá para pedir pra ele avaliar as telas que você está criando com base em heurísticas como a de Nielsen, por exemplo, e os resultados são muito interessantes. Enquanto escrevia esse texto, pedi para avaliar a tela do editor aqui do WordPress.
Buzz é uma ferramenta super simples cujo propósito é transcrever arquivos de áudio e vídeos para formatos de texto, tudo offline, o que nos ajuda a levar todas aquelas informações para um prompt e trabalhar em cima delas. Ela é uma alternativa barata (grátis se você usar a versão clássica) caso você não queira ter que “andar” com um bot que entra com você em toda reunião, como acontece em soluções como MeetGeek, que apesar de ter uma transcrição de altíssima qualidade, é uma ferramenta paga e o custo não é baixo. Resumindo, o Buzz dá pro gasto e dá pra começar com ele. Você pode utilizar tanto as gravações das ferramentas de videochamada como também gravar offline com o OBS, sempre pedindo permissão dos convidados, é claro!
Visual Eletric
Embora todos esses chatbots gerem imagens, uma ferramenta que vem me surpreendendo e ajudando nas minhas entregas mais visuais é o Visual Eletric. Basicamente, ele gera imagens a partir de prompts e permite que você defina o preset, que pode ser fotografia, cinema, estilo, ilustração … e as cores que você deseja que estejam presentes. Após o processamento, você pode ainda “dirigir” a criação a partir do resultado do prompt. Embora existam várias ferramentas que gerem imagens, mesmo entre as focadas nesse fim, o Visual Eletric surpreende pela qualidade altíssima dos resultados e é realmente uma baita opção aos bancos de imagens, e muito mais barato, e é muito mais fácil chegar a um resultado que combine com a proposta da demanda do seu cliente e sua marca, e novamente, sua criatividade é o limite. Segue um prompt e um resultado:
A person is in a cozy house, drinking coffee. This house has natural architecture, with plants that decorate the environment. There is also a bookshelf in the background
Essas são algumas das ferramentas e processos que tenho adotado no meu dia a dia como designer que acredito que me ajudam a organizar as ideias e focar em soluções, tornando minhas entregas mais assertivas e dinâmicas. Essas ferramentas evoluem rapidamente, então é preciso estar sempre de olho nas novidades.
Não são poucas as vezes em que me demandam a criação de protótipos rapidamente. Mas até que ponto isso faz sentido?
Entendo que protótipos são uma poderosa ferramenta na hora do processo de ideação e validação de uma ideia, que pode se referir a um produto ou parte de um. E em muitos casos, validar uma ideia rapidamente pode ser crucial para o negócio.
Como eu não acredito em metodologias by the book como solução para todos os problemas, vejo pontos positivos no uso de protótipos mesmo em etapas iniciais do processo de design, como primeiro entregável a ser avaliado pela equipe, pelo cliente e até mesmo validado com os usuários.
Para que isso aconteça de forma consciente, é preciso que fique claro para todos que aquela entrega não é final e sim uma iteração dentre as várias etapas de confecção de um produto. E claro, é fundamental utilizar bibliotecas e sistemas de design já prontos para acelerar o processo.
Um dos grandes desafios das equipes de design é lidar com a cultura de seus clientes e organizações. Não atoa, muitos profissionais empregam o termo evangelizar para dar nome ao conjunto de ações que visam aculturar o cliente e fazê-lo entender que a realização de processos centrados no usuário são importantes para construção de produtos melhores e capazes de entregar mais valor para os usuários. Tudo isso, é claro, sem deixar de atender as necessidades do negócio. Esse é um cenário muito comum a organizações com pouca ou nenhuma maturidade em Design ou mesmo com culturas onde a entrega do software é o passo mais importante.
Atualmente, é comum que uma das ações de evangelização de organizações seja feita por meio de metodologias como Design Thinking, que visa trazer a visão do processo de Design com uma linguagem mais palpável para o mundo corporativo. Buscando evocar o sentimento de empatia entre os responsáveis pela concepção dos produtos, funciona quase como uma conscientização do envolvimento das pessoas usuárias nos processos. Junto ao Design Thinking, geralmente somos apresentados ao Double Diamond, que é (indiscutivelmente) um processo fácil de entender e palpável o suficiente para grande parte das pessoas. No entanto, mesmo com essa simplicidade, nem sempre conseguimos levar a frente esse tipo de processo como gostaríamos, e as barreiras são inúmeras.
Mesmo com uma “evangelização” em andamento, nem sempre fica clara a importância da condução desses processos para o valor do produto. Há uma resistência a agendas baseadas em workshops, realização de pesquisas e todos os ritos que nós designers julgamos importantes para uma entrega de valor. Na visão dos stakeholders, esses ritos viram obstáculos para o avanço do projeto, afinal de contas, eles querem mesmo é ver o produto na rua. Isso se torna ainda mais latente quando há um entendimento por parte do cliente de que ele já sabe o que quer, especialmente quando há um conjunto de requisitos pré-definidos, com todas as estórias esperando para ganhar vida em protótipos de alta fidelidade, que serão desenvolvidos e entregues o mais brevemente possível.
É preciso enxergar esses obstáculos com muita naturalidade, pois não se transforma cultura de um dia para o outro. No entanto, precisamos de estratégias que levem em conta esses inúmeros obstáculos e que, ainda assim, nos permitam realizar entregas consistentes para os todas as partes interessadas. Por isso, vou recorrer a um velho conhecido: o ciclo de vida em estrela.
Brilha uma estrela O Ciclo de Vida em Estrela é um dos processos de design presentes na literatura de Interação Humano-Computador, e aqui utilizarei como base o livro clássico da Simone Barbosa para esta disciplina. Proposto por Deborah Hix e Rix Hartson na década de 1990, esse processo é composto por 6 atividades, onde a avaliação é o elemento central e por onde todas as outras atividades devem passar a cada interação. O pulo do gato está justamente na flexibilidade na hora de iniciar o ciclo do produto, pois fica a cargo do designer (que aqui prefiro substituir pela figura do time) decidir por onde faz sentido iniciar, com base no contexto que está a nossa frente.
Digamos que uma determinada ideia tem grande dependência tecnológica para funcionar, e sem esse ingrediente, o produto não será capaz de existir. Faz sentido que o projeto inicie por meio de uma implementação inicial e experimental com o objetivo de validar se a tecnologia atende ao requisito, para só depois ser avaliada e virar um projeto conceitual, por exemplo.
Projetos com grande apelo dentro da organização, que buscam resoluções rápidas para aproveitar aberturas de mercado podem começar por um protótipo e depois seguirem uma primeira implementação, dando vida a um MVP, sempre passando por etapas de avaliação, que nesse caso podem incluir testes de usabilidade, validação de hipóteses, inclusive se utilizando de dados gerados pelos usuários durante o contato com o produto. Aqueles projetos em que já existe um conjunto de requisitos pré-definidos podem seguir com um caminho mais convencional, mas esbarrar em uma etapa de avaliação na próxima iteração. O Ciclo de Vida em Estrela permite infinitas interações, sendo possível trabalhar em ajustes e incrementos no produto mesmo após a sua etapa de implementação, bem como retoma-la para entrega de novas versões do produto. Essas características tornam essa abordagem uma alternativa muito interessante para contextos onde é preciso entregar logo, validar depois.
Avaliando a cada iteração
Com grandes flexibilidades, vem grandes responsabilidades. Mesmo permitindo que os projetos iniciem por diversas frentes, inclusive indo direto para a construção de protótipos ou implementação, a ideia é que nenhuma iteração passe a frente sem uma etapa de avaliação, e aqui que a mágica acontece. Nessa etapa, nós sempre validamos o que foi realizado no passo anterior, com as ferramentas que julgarmos mais interessantes naquele momento. Podemos realizar um teste de usabilidade com base no protótipo construído, avaliar se a tecnologia testada por meio da implementação faz sentido para o que se quer resolver, ou até mesmo entender se os requisitos propostos atendem as necessidades dos usuários e do negócio.
Quando um ciclo é concluído e termina com o produto nas mãos dos usuários, voltamos a avaliação para acompanharmos os resultados, ouvir os feedbacks dos usuários e dar início ao ciclo de melhorias. A cada etapa de avaliação, é possível decidir que rumo o projeto deve tomar na próxima iteração. Esse tipo de abordagem é mais comum do que pensamos. Um clássico exemplo é quando utilizamos protótipos para materializar ideias e ajudar os stakeholders a entenderem o que queremos propor, e também podemos entender esse processo como uma etapa de avaliação. Se trata de estruturar como processo algo que já acontece no nosso dia a dia, e tirar proveito dessa flexibilidade para realizar a melhor entrega possível.
Simplificar para conquistar Flexibilizar o processo de construção de produtos pode nos ajudar a romper uma barreira interessante para inserção de processos de design mais abrangentes em outras etapas do projeto. Além disso, entendo que essa abordagem consegue ser mais realista, já que leva em conta as peculiaridades de cada projeto, entendendo que cada time e cada produto são um mundo diferente.
E claro, é possível combinar esta abordagem com outras metodologias que já conhecemos, como Design Thinking e Design Sprint, por exemplo. Não há uma abordagem correta ou definitiva, é preciso entender e sentir o momento do time e escolher a ferramenta que melhor atenderá as expectativas de todas as partes.
Referências
BARBOSA, Simone Diniz Junqueira; SILVA, Bruno Santana da. Interação Humano-Computador. Rio de Janeiro: Elsevier Brasil, 2010. 408 p. ISBN 978-8535234183
Design é projeto. Acredito que todos nós que estamos no campo do design, seja no âmbito acadêmico ou na prática da profissão, já ouvimos falar neste significado para a palavra design, e eu particularmente gosto dessa relação. O profissional Designer tem como objetivo final o projetar de algo, a concepção de alguma coisa, buscando a resolução de algum problema ou obstáculo, e gosto de pensar que não importa muito a natureza desses. E o fruto dessa concepção é também um algo, que passa a ocupar o lugar do problema ou do obstáculo, mas deixarei para aprofundar nisso em outro momento. O que quero falar aqui é sobre o meio do caminho entre o Designer e seu artefato final, que está contido no projetar: o processo de design.
Não precisamos nos esforçar muito para enxergar os processos em nossa vida, algo bem semelhante ao que entendemos por algoritmos, ou seja, uma sequência de ações que determinam um resultado, mas aqui conseguimos traçar uma distinção interessante: processos não são rigorosos e por isso conseguem gerar resultados diferentes a depender de quem o realiza. Processos são maleáveis. Design é, por tabela, processo, e processos resultam em artefatos frutos do processo. Nem só o designer vive de processos. Arquitetos, artistas, artesãos … todas essas áreas possuem um processo para chamar de seu, mas aqui abordarei mais especificamente processos no campo do design.
O processo do design
O fazer do design passa pelo processo. Há uma variedade de frameworks de processos de design, que em geral passam por entender, idear, construir e entregar esse algo, com mais ou menos passos dentro de cada uma dessas etapas. Mesmo que aparentem ter escopos fechados, esses frameworks não são imutáveis e é muito natural que cada um de nós os adapte conforme nossas necessidades, seja enquanto profissional solitário, seja em equipes.
Muitas vezes, é preciso combinar mais de paradigma um para solucionar a necessidade de uma equipe ou empresa, muitas vezes até mesclando modelos e/ou trazendo abordagens mais adequadas para determinados fins. Design Thinking, por exemplo, visa ter uma linguagem mais atraente para pessoas não designers, geralmente do mundo corporativo, que desejam colocar pessoas no centro de seus processos de concepção de produtos, ou abordagens como Lean Inception, que sequer possui foco em design, mas que nos ajudam a apontar para um caminho de mínimo viável para um produto inicial, podendo ser parte de um processo de design, e aqui deixo como exemplo o processo da Objective, uma amálgama de vários frameworks. Processos, portanto, servem como um guia de viagens. Podemos nos guiar por eles, mas os caminhos sempre dependem de nós.
Cada etapa de um processo de design, independente do objetivo, gera informações, e podemos entender isso como um artefato para além do próprio projeto alvo. No print acima está o resultado de meses de trabalho em um processo de pesquisa de experiência com foco em um determinado produto, mas que pode e deve gerar insights para decisões em outros campos da organização, fugindo assim ao próprio objetivo inicial do processo. Aqui, entendemos os resultados gerados em cada etapa do processo de design como informação gerada, tratada e interpretada, ou seja, um conhecimento consolidado.
Artefatos provenientes do processo de design, quando tratados como entregáveis, podem ser cruciais para uma organização e seus times. Além do conhecimento gerado, servem como maneira de integrar novos membros ao time, já que permite a qualquer um retroagir no que foi trabalhado anteriormente em determinado produto. É preciso, no entanto, torna-las entendíveis e acessíveis. Ferramentas como o Miro ajudam nessas horas, mas é preciso achar maneiras de reverberar esse conhecimento para outros setores da organização para que eles saibam que esses artefatos existem e, assim, tomar partido dessas informações.
O design para além do produto final
Entendemos que Design é projeto e projetos visam resolver problemas, mas que há um meio do caminho que chamamos de processo, que liga o que queremos resolver até a sua resolução propriamente dita, o objeto final. Mas podemos e devemos pensar o processo, também, como gerador de pequenas resoluções, ou seja, objetos, a cada iteração.
Entender bem as etapas do processo e realiza-las como partes de um todo, mas com fins em si mesma, pode ser uma excelente maneira de gerar frutos para além do objeto final, indo além de simplesmente documentar, dando vida própria a cada parte. É sobre construir um conjunto de cartinhas independentes e colecionáveis ao invés de quebra-cabeças.
