Olá, sou Yan Vancelis

Sou um designer generalista. Por aqui, falo sobre assuntos que envolvam tecnologia, design, produtos e muito mais.

agile aliexpress arquitetura da informação blogs design design thinking double diamond elon musk estelionatários do xeon estruturas de dados figma Framer Gutenberg heuristicas ia ihc inclusão digital intel xeon metareciclagem no-code oo orientação a objetos processo product design produtos programação prototipação redes sociais tad tipo abstrato de dados transcrição de áudio twittter typescript ui ux uxui Webflow Wix wordpress x xeon

  • Ciclo de vida em estrela: Um processo de design alternativo para cenários diversos

    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

  • O processo como objeto final no design

    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.