Smashing Podcast Episódio 9 Com Stephanie Walter: Como posso trabalhar com estruturas de interface do usuário?

Como desenvolvedor, uma das coisas que gosto nos frameworks de interface do usuário é que eles geralmente vêm com estilo padrão, mas isso é algo em que devemos confiar em projetos? Simplesmente usando o estilo padrão e confiando que quem produziu a estrutura fez um trabalho muito bom ao projetar esses componentes? Junte-se a mim no episódio de podcast de hoje, onde falo com a UX Designer Stephanie Walter sobre coisas que devemos considerar ao construir uma estrutura de interface do usuário.

Mostrar notas

• Site da Stephanie
• Stephanie no Twitter

Atualização semanal

• “Como criar um jogo de correspondência de cartas usando Angular e RxJS” por Anna Prenzel
• “Como criar um site WordPress sem cabeça no JAMstack” por Sarah Drasner
• “Magic Flip Cards: Resolvendo um problema comum de dimensionamento” por Dan Halliday
• “Django Highlights: User Models and Authentication (Parte 1)” por Philip Kiely
• “Como criar mapas com React e Leaflet” por Shajia Abidi

Transcrição

Drew McLellan: Ela é uma designer centrada no usuário e especialista em experiência móvel, que cruzou produtos e interfaces deliciosos com foco especial em desempenho. Ela trabalhou em projetos para clientes como a Universidade de Luxemburgo, Banco Europeu de Investimento, BMW e Microsoft, para citar apenas alguns, e ela ajuda esses clientes a entregar projetos de sucesso ao seu público, desde a estratégia até o produto final. Ela é uma especialista do Google Developer em design de produtos e uma professora apaixonada que compartilha seu conhecimento em várias postagens de blog, artigos, workshops e apresentações em conferências. Então, sabemos que ela é uma designer especialista em experiência do usuário, mas você sabia que ela já teve um trabalho de montagem de tapetes com Sir Elton John? Meus amigos do Smashing, por favor, dêem as boas-vindas a Stephanie Walter. Olá Stephanie, tudo bem?

Stephanie Walter: Oi, estou arrasando e adorei a introdução.

Drew: Então, eu queria falar com você hoje sobre um problema específico e esse é o assunto do uso de estruturas de interface de usuário prontas para uso. Agora você é um designer de experiência do usuário e trabalha com muitos clientes diferentes e seu trabalho é ajudar esses clientes a criar as melhores experiências de usuário possíveis por meio da criação de interfaces de usuário altamente utilizáveis. Portanto, a ideia de poder fazer isso com um conjunto de ferramentas prontas para uso parece um pouco exagerada para mim. O uso do framework de interface do usuário é algo que você vê muito em todo o seu trabalho?

Stephanie: Sim, é algo que tenho visto muito, especialmente nos últimos anos porque comecei a trabalhar com uma agência e agora trabalho dentro da empresa. Então, nessas equipes super grandes de tecnologia de TI e sim, no momento há muitas interfaces de usuário de estrutura, como a que eu mais vi é a Material-UI, basicamente o Material design é um tipo de diretrizes e coisas do Google design, e Material -UI é a equipe do Angular, mas também a equipe do React. Eles criaram sua própria estrutura usando a aparência do Material design do Google. Mas não tem mais nada a ver com o Google. É como eles, eu não sei, acho que eles gostaram da aparência. Então, no momento, essas são as duas principais estruturas de interface do usuário com as quais trabalho. E também há algo chamado Ant Design, que se tornou bastante popular.

Stephanie: É um framework React. Eu não sei se eles têm Angular também. Acho que foi feito por uma equipe na China. E é interessante porque não apenas fornece os componentes, tudo em React, mas se você for ao site deles também obterá os arquivos de rascunho, o que é bastante interessante porque meio que motiva ou ajuda o designer a construir ou moldar a interface nos componentes de interface do usuário usados ​​por essa estrutura. Então, sim, é algo que tenho visto muito, especialmente em grandes equipes de TI, porque na maioria das vezes elas não têm um designer. No momento eu sou basicamente uma equipe de UX de um em uma pequena equipe em um banco de investimento europeu. Então sou eu como designer de UX. Eu trabalho com uma equipe de desenvolvedores, analistas de negócios, todas as pessoas boas, mas ainda sou um designer para todo o projeto.

Stephanie: Até eu chegar não havia designer. Então é uma solução implementada em muitas empresas, especialmente em produtos internos, por exemplo. Onde eles costumam dizer, ok, nós realmente não precisamos de um designer para isso. Nós só precisamos de algo que funcione para nossos usuários internos e vamos usar um framework porque é conveniente para os desenvolvedores. A maioria dos componentes já está lá e, como eles não têm designers na equipe, está substituindo, por assim dizer, o papel de um designer de interface do usuário. Sim, o problema é que, ok, então você tem os componentes, mas o papel do designer de interface do usuário não é apenas decidir se o botão deve ser vermelho, verde, laranja, azul, o que for. Normalmente, o papel do designer de interface do usuário é a arquitetura da informação, entendendo as necessidades do usuário. Então, tudo o que vai além da interface. Então, mesmo que você tenha esse tipo de estrutura que cuida de toda a interface do usuário, visualmente o que você vê na tela.

Stephanie: Você ainda precisa de alguém em algum momento para fazer o trabalho de entender o que colocamos na tela, como vai se comportar? O que acontece quando clicamos aqui? Como o usuário atinge seu objetivo? Como vamos do ponto A ao ponto B? Porque podemos usar um modelo, podemos usar guias, podemos usar todos os componentes. Então é por isso que é sempre um pouco complexo e complicado.

Drew: É possível, você acha que pode criar uma interface de usuário utilizável usando uma estrutura de interface do usuário pronta para uso, ou sempre será um pouco complicado?

Stephanie: Eu meio que espero que sim. Eu meio que espero que sim porque, caso contrário, estou construindo interfaces não utilizáveis. Portanto, esta resposta é totalmente tendenciosa, mas sim, acho que é, mas também depende do nível de compromisso que você está disposto a fazer e há compromissos de ambos os lados. No momento estou comprometendo muitos botões, por exemplo, porque você tem alguns botões realmente específicos no Material-UI, e eu realmente não gosto do efeito cascata no botão. Acho que funciona muito bem no celular porque no celular você precisa de um grande feedback quando o usuário clica ou toca no botão. Mas então os passos são uma espécie de efeito cascata que vai até o botão. É um pouco exagerado, especialmente quando há muitos botões. Mas ainda vamos manter esse efeito cascata porque seria super complexo removê-lo porque isso foi embutido no framework React. E para ter outro efeito de hover nesse botão, algo mais sutil que não seja esse tipo de coisa fofa aqui. Seria supercomplexo.

Stephanie: Então esse é o tipo de compromisso que você faz. Mas enquanto isso, não comprometo com coisas específicas que são componentes personalizados. Onde eu trabalhava antes, o atual cliente de uma empresa de viagens e companhias aéreas. E a companhia aérea tem algumas necessidades muito, muito específicas. O calendário da companhia aérea por exemplo, você quer colocar preços, você quer colocar... o calendário básico da maioria dessas estruturas de interface do usuário não fornece esse tipo de coisa. Então, em algum momento, você pode dizer, ok, usaremos apenas o calendário que eles têm. E é isso. Você precisa ir além disso. Então, a maioria dos compromissos são basicamente construídos, usamos o componente básico? Criamos um personalizado que atenda às necessidades do usuário? Ou fazemos uma mistura dos dois? No caso do calendário, por exemplo, usamos a grade do calendário, então usamos o componente básico e depois aprimoramos com personalização em cima disso. Então foi muito desenvolvimento React para esse.

Stephanie: E sim, então geralmente você faz muitos compromissos.

Drew: Então parece que usar uma estrutura de interface de usuário pode levar você a um certo caminho, mas para realmente ter uma boa interface de usuário como resultado disso, você precisa fazer um pouco de personalização no topo?

Stephanie: Normalmente. Sim.

Drew: Essa customização vai além do tema?

Stephanie: Sim, meu desenvolvedor desejou que não fosse além do tema. Eugene Se você me ouvir. Acho que ele ficaria super feliz se apenas mudássemos algumas cores em tudo. Mas sim, em algum momento você precisa ir além da personalização porque primeiro, como as estruturas de interface do usuário são como as ferramentas Lego, é uma espécie de caixa de ferramentas. Portanto, você tem muitos componentes diferentes na caixa, mas isso não cria uma página. Você ainda precisa de um cabeçalho, ainda precisa de um rodapé. Você ainda precisa de conteúdo extra que não estava na estrutura. Então, às vezes você pode ajustar um componente para o que você precisava. Pelo que entendi, estamos usando o componente card para construir uma janela modal, mas o problema com as janelas modal é que ela não se comporta como um cartão.

Stephanie: Você está indo um pouco além disso. Você precisa de um plano de fundo com obscurecimento. Você precisa acioná-lo ao clicar, enquanto geralmente seu cartão já está na interface. Então, estamos usando este componente de cartão porque ele tem muitas coisas que precisamos, como o plano de fundo, um cabeçalho e um título na parte superior, alguns botões na parte inferior. Então temos a estrutura e depois ajustamos um pouco. Mas às vezes acabamos com algum conflito sobre semântica, HTML também. Porque, por exemplo, eu queria ter botões que não tivessem formas de botão, assim como o botão de link e o desenvolvedor disse: "Ok, então usamos um link como seu link href". Eu disse: “Não, isso não é um link. É um botão. Quando eles clicam nele, ele não abre uma nova página. Ele limpa tudo o que está no formulário.”

Stephanie: Então deveria ser tecnicamente do ponto de vista semântico, deveria ser um botão. "Sim. Mas não existe na estrutura.” Eu digo "Então, tudo bem, eu sei, então o que vamos fazer?" Então normalmente você começa a discutir essas pequenas coisas e já que estou realmente irritando meus desenvolvedores com acessibilidade também, essa é outra camada extra de tentar ter certeza de que temos os componentes básicos com os quais eles funcionam bem. Mas também que eles são semanticamente como eu não quero ter botões com gifs dentro de gifs dentro de gifs. Caso contrário, teremos problemas no final.

Drew: Acho que para começar um novo projeto que usará uma estrutura de interface do usuário, você provavelmente precisará começar com algum tipo de pesquisa de usuário.

Stephanie: Sim.

Drew: Isso é justo?

Stephanie: Você deveria. Você precisa. Então, sim, geralmente você pode ter todos os componentes que deseja. Você ainda precisa saber o que seus usuários precisam nas páginas, como eles vão navegar? Você precisa construir um fluxo. Então, geralmente antes mesmo de decidir sobre um framework, o que fazemos é ir até nossos usuários, conversar com eles, tentar entender suas necessidades. Então, no momento eu tenho muita sorte porque os usuários estão internamente dentro do banco. Então nós fazemos muitos workshops com eles e você tem que imaginar que é uma interface super complexa. Estamos migrando de algo que foi construído, não sei, acho que 10 ou 15 anos atrás para algo totalmente novo e brilhante usando o Material-UI React. Então é uma grande mudança e você tem que entender que durante esses 15 anos, todo mundo que queria algo poderia ir ao suporte e então pedir à equipe de TI para implementá-lo. Então no momento minha interface é tipo 400 páginas com tabelas, dentro de tabelas, dentro de tabelas, com outras tabelas, e coisas que nem deveriam estar em tabelas.

Stephanie: Como se tivéssemos muitas coisas que são apenas valor-chave, valor-chave, valor-chave. Então eles constroem a tabela com duas colunas. Eu fico tipo, “Não, talvez possamos fazer algo melhor com isso.” Então, no momento, o que estamos fazendo é fazer algumas pesquisas com usuários para entender os diferentes objetivos dos usuários. Então o que identificamos é que o que eles fazem com a interface, eles têm alguns objetivos de planejamento. Eles precisam planejar seu trabalho. Então eu quero saber que essa operação vai para essa reunião, então eu preciso disso nessa agenda, coisas assim. Eles querem monitorar uma coisa, eles querem relatar os dados. Portanto, monitorar é como olhar para os dados e garantir que tudo esteja bem. Reportar é poder explorar os dados, fazer algo com eles que eles querem compartilhar e meio que colaborar com os colegas e tudo isso descobrimos discutindo diretamente com os usuários.

Stephanie: E o que descobrimos é que, na verdade, algumas das coisas que planejamos migrar no final são algumas das coisas mais importantes diariamente para o usuário. Portanto, o objetivo do usuário de planificação é um dos maiores no momento. Então, estamos realmente trabalhando nisso. Então, sim, usamos a entrevista e agora estamos na fase em que no momento estamos em um nível super alto dizendo que precisamos construir o shell, precisamos entender a navegação. Mas no momento não analisamos todos os dados e agora é isso que vamos fazer. E é interessante porque temos muitas tabelas e dissemos que podemos seguir o caminho não inteligente e apenas colocar as tabelas na nova interface e pronto, ou podemos dizer, ok, vamos tentar entender o que essas tabelas são, para que nossos usuários usam essa tabela?

Stephanie: E então talvez algumas das tabelas possam ser exibidas como visualização de dados e, para fazer isso, você precisa entender todo o negócio para que os dados façam sentido. Então, se você tem um bom framework e diz, ok, vamos usar este gráfico... Acho que se chama chart JS framework. Você tem muitas coisas, você pode ter histogramas, gráficos de pizza e tudo mais, mas em algum momento você ainda precisa de um designer para te ajudar a decidir. Ok, esses dados, faz sentido se mostrarmos em um gráfico ou faz mais sentido mostrar como uma torta porque queremos mostrar parte do todo, ou queremos comparar a evolução de um país nos últimos 10 anos, então um histograma é mais interessante. Portanto, com base no que o usuário deseja fazer com os dados, você os exibirá de uma maneira totalmente diferente.

Stephanie: E geralmente não é um trabalho de desenvolvedor fazer isso. Nosso desenvolvedor, eles são um cara super inteligente. Me desculpe, mas eu honestamente trabalho com desenvolvedores caras, eu gostaria de ter algumas mulheres, mas não. Nenhuma delas é mulher. Então, caras super inteligentes, mas eles não são super qualificados para dizer, ok, esses dados devem ser exibidos assim, isso, isso e aquilo. Então, no final, você ainda precisa que alguns designers conversem com os usuários, entendam o que você pode fazer com os dados e isso vai muito além de apenas dizer, ok, isso deve ser uma barra de guias ou deve ser uma navegação à esquerda.

Drew: E depois de tomar esse tipo de decisão com base em conversas com os usuários. Você normalmente levaria os protótipos ou designs resultantes de volta aos usuários para testá-los novamente para ver se eles entendem seu tipo de escolha de gráfico, por exemplo?

Stephanie: Sim, na verdade fizemos muito isso, o que é muito bom porque você não desenvolve algo até saber que será útil e utilizável. Então depende. Se é mais rápido desenvolver a coisa porque eles já têm a maioria dos componentes, o que eu costumo fazer é fazer uma prototipagem muito rápida em papel e então desenvolvemos a coisa porque é rápido, mesmo sem os dados. Se for algo complexo, algo muito, muito novo que levará muito tempo para ser desenvolvido, então dizemos, ok, projetamos algumas telas e fazemos alguns testes diretamente na tela. Então nós temos uma ferramenta que se chama InVision, onde basicamente você coloca todo o seu design, você pode criar links entre as diferentes partes. A coisa é que também depende do que você quer testar. Se você quiser testar telefones, por exemplo, é um pesadelo testá-los no InVision porque as pessoas não podem realmente senti-los e especialmente no celular, por exemplo.

Stephanie: Então é sempre meio inteligente. Qual é a maneira mais rápida e barata? É mais rápido e barato testar apenas projetos. Isso é suficiente? Para formulários geralmente, não realmente porque você completa automaticamente todo o trabalho pesado que você coloca no front-end que realmente faz o usuário preencher um formulário, então para formulários, talvez seja mais eficiente criar um formulário e testá-lo. Mas para coisas novas, sim, fazemos muitos designs. Vamos aos usuários. Então, no momento, fazemos um a um, mas meus usuários são pessoas muito ocupadas. É um banco de investimento europeu, então eles não têm muito tempo. Então, o que geralmente fazemos é que, se formos pessoalmente com os usuários, fazemos algumas pequenas reuniões, mais como grupos focais. E também é interessante porque às vezes você tem um tipo de confronto. Algumas pessoas dizem: “Sim, eu acho que funciona para mim porque eu trabalho assim e aquilo”, e então haverá outras pessoas que ficam tipo, “Ah, você trabalha assim? Na verdade não, eu faço assim e aquilo.”

Stephanie: Então, também é interessante ter algumas pessoas na sala e ouvir apenas a conversa, tomar notas e dizer: “Ah, talvez possamos fazer isso” e “Esse componente seria melhor baseado no que acabei de ouvi." E coisas assim.

Drew: Se você estiver trabalhando com um público mais geral para o seu produto. Então, talvez não usuários internos como você, mas mais o público em geral, existem maneiras baratas de os designers usarem a pesquisa? Existem maneiras mais fáceis se você não souber diretamente quem serão seus usuários?

Stephanie: Você deve saber quem eles serão, caso contrário, ele faz o trabalho do pessoal de marketing antes de construir o produto. Mas sim, fizemos alguns testes de usuário de guerrilha, por exemplo, você ainda pode usar o InVision, por exemplo. Assim, você pode construir alguns protótipos no InVision e recrutar os usuários por meio de mídias sociais, por exemplo. Eu estava trabalhando para um produto que ajudava, qual é o nome, mecânicos de concessionárias de carros que consertam coisas e depois informam também o cliente sobre reparos extras, coisas assim. Então, já tínhamos uma comunidade crescente no LinkedIn e no Facebook. Então o que você pode fazer é recrutar essas pessoas. Você pode fazer testes remotos, como se estivéssemos conversando em uma ferramenta como uma ferramenta online. Você pode fazer algum compartilhamento de tela. Então fizemos isso para algum projeto também.

Stephanie: Eu só te daria um conselho é testar a ferramenta antes, porque eu estava usando, chamava-se aparecer.in. Mas eu acho que eles mudaram o nome para Whereby ou algo assim, mas é realmente no navegador que eu disse, ok, é legal porque aí os usuários não precisam instalar nada, mas os usuários não estavam em um computador real. Eles estavam em VM, em um Citrix e não tinham microfones, então o que acabamos fazendo é como se eles usassem minha ferramenta para compartilhar a tela. Eles estavam clicando no protótipo e ao mesmo tempo eu os tinha no telefone, como um telefone fixo, para falar diretamente com eles. Então sempre, isso foi bem barato porque foi um dia maravilhoso de recrutamento, acho que tínhamos 10 usuários ou algo assim. Sim, você pode fazer muitas coisas mesmo se não puder ficar cara a cara, eu fiz muitos testes de usabilidade diretamente no Skype ou coisas assim. Portanto, há sempre algumas maneiras baratas de fazer isso.

Drew: Quando se trata de escolher uma estrutura de interface do usuário para trabalhar, se esse é o caminho que você está seguindo, é algo que você deixaria apenas para os desenvolvedores ou é algo em que os designers deveriam se envolver também?

Stephanie: Para mim, você deve envolver toda a equipe. Como os designers, os desenvolvedores, talvez também os arquitetos, se você tiver alguns, porque a forma como a estrutura é construída também pode influenciar esse tipo de coisa. Infelizmente, na maioria das vezes quando eles chegam no projeto, o framework já está decidido. Não, na verdade é engraçado, ou já está decidido ou me pedem para validar a escolha do framework, mas não fiz nenhuma revisão ou pesquisa. Eu não tenho ideia do que está no projeto porque eles nem me mostraram suas telas. Eles são como, “Sim, faça sua coisa. Podemos usar essa estrutura.” Não sei. Bem, nós temos uma tela? Então eles acabaram mostrando algumas telas, que era um aplicativo nativo do Windows que eles queriam migrar na nuvem. Eles disseram: “Sim, só precisamos dos botões e principalmente formulários e coisas assim”.

Stephanie: Mas é muito difícil dizer: “Sim, vá para esta estrutura, temos todos os componentes de que precisamos”. Ou como: “Não vá se você não tiver uma ideia aproximada de qual será o seu conteúdo, qual é a navegação”. Portanto, acho que você ainda deve ter uma visão geral global antes de escolher seus frameworks, a menos que tenha 100% de certeza de que possui todos os componentes. Mas tenho a sensação de que na maioria das vezes a escolha do framework é basicamente baseada em quais tecnologias o desenvolvedor gosta no momento, eles têm experiência com um framework antes disso? Usamos Ant em alguns projetos apenas porque alguns desenvolvedores tinham experiência com isso e eles realmente gostaram e foram meio eficientes usando Ant. E para o Material React UI é o mesmo. É tipo porque o desenvolvedor já usou em projetos anteriores, então eles são eficientes com isso.

Drew: Então, realmente tem que haver um equilíbrio entre o que os desenvolvedores estão confortáveis, o que eles sabem, o que vai funcionar com sua pilha de tecnologia e quais são os requisitos do produto em termos de criação de uma boa interface de usuário. E você de alguma forma precisa equilibrar os dois para encontrar a estrutura ideal para isso.

Stephanie: Sim. Eu tenho um tipo de requisito específico para algum projeto, que é… estou em Luxemburgo, temos muitas instituições europeias e coisas assim, então temos um requisito extra de acessibilidade para alguns deles. E geralmente quando a estrutura foi decidida, eles realmente não verificaram a acessibilidade de sua estrutura e então voltaram alguns meses após o início do projeto dizendo: “Ah, acabou de nos dizer que existe essa nova lei e devemos ser acessível, mas não sabemos como fazer isso.” Como sim, é um pouco tarde demais. Então, para mim, para escolher um framework você precisa realmente conhecer todas as restrições no início do projeto e se acessibilidade é uma delas você precisa testar seus componentes e ter certeza de que eles serão acessíveis. Mas eu não sou um desenvolvedor React ou Angular, mas tenho certeza que é super complexo transformar um framework de UI não acessível em algo acessível. Acho que pode ser um pouco complexo reconstruir todos os componentes, então coisas assim.

Drew: Se você estiver trabalhando em um projeto em que esse processo não ocorreu e uma estrutura de interface do usuário já foi escolhida, existe o perigo de que a interface do usuário comece a ser influenciada pelos componentes que já existem nessa estrutura, em vez de sendo impulsionado pelas necessidades do usuário?

Stephanie: Realmente, honestamente, a maioria dos projetos em que trabalhei, eventualmente, você acaba tendo muitas desvantagens, mesmo se você realmente tentar forçar. Portanto, trata-se principalmente de equilíbrio e discussão com os desenvolvedores. Então, geralmente o que eu faço é fazer alguns wireframes, até mesmo wireframes de papel rápidos, digamos ok, nesta página vamos precisar disso e daquilo e daquele componente, a primeira coisa que faço é perguntar ao desenvolvedor se temos isso em nosso quadro no momento? Com o que se parece? E então decidimos juntos, ok, esse é um componente que faria o trabalho ou tudo bem, isso não funcionaria. Ajustamos? Nós ainda mantemos o componente, mas o alteramos um pouco para que ele faça o trabalho, ou construímos algo do zero?

Stephanie: E no final das contas vai depender do orçamento, claro. Então você acabou fazendo trocas. Como eu ficaria bem para pequenos componentes que quase nunca são usados ​​se não forem perfeitos e houver alguns problemas. Mas para navegação principal, estrutura principal, coisas que você vê o tempo todo na tela, por exemplo, isso realmente precisa funcionar. O usuário precisa entender como ele funciona de forma eficiente e sim, é, como você disse, encontrar um equilíbrio entre a experiência ideal que você gostaria de ter se não tivesse nenhum framework e o que você tem em mãos e o orçamento e também o tempo. Se dissermos, ok, para esses sprints, o recurso precisa ser concluído no final deste sprint, e então eles dizem, ok, mas se você quiser seus componentes, nunca terminaremos o recurso no final deste sprint, então você comece a discutir, ok, terminamos esse recurso na próxima tela, levamos mais tempo para fazê-lo corretamente? E geralmente depende muito.

Stephanie: As coisas que mais me frustram é quando eu sei que usamos um componente de correção de corte e eles me dizem tipo, Ah não, não se preocupe. Vamos corrigir isso mais tarde. E eu sabia que o mais tarde, infelizmente, talvez nunca acontecesse. Então depende da equipe. Mas depois de um tempo você tem a experiência e sabe, isso vai chegar mais tarde e ou não? Sim, é sobre compromissos. Quando você está trabalhando com esse tipo de ferramentas.

Drew: Como desenvolvedor, uma das coisas que gosto nos frameworks de interface do usuário é que eles geralmente vêm com estilo padrão. Então isso significa que eu não preciso necessariamente ter um designer talvez para me ajudar com a aparência de todos os componentes. Isso é algo que devemos confiar em projetos? Apenas o estilo padrão e a confiança de que quem produziu a estrutura fez um trabalho muito bom ao projetar esses componentes? Ou você mesmo estaria estilizando esses componentes?

Stephanie: Acho que realmente depende. O problema, por exemplo, com o Material-UI é que a aparência do seu aplicativo da web será basicamente os produtos configurados do Google. Então, se você não mudar a fonte, mudar algumas cores e meio que trazer sua própria identidade de marca e fizer isso, você terá um produto que será parecido com qualquer produto do Google, o que pode ser uma coisa boa, porque se seus usuários estão acostumados com os produtos do Google, isso pode ajudá-los a entender. Então, normalmente, se você não tem um designer na equipe, você tem alguma escolha? Como muitos dos trabalhos diferentes que vi, eles vêm com temas personalizados para que pelo menos você possa alterar as cores. Eu acho que você pode mudar as fontes também com bastante facilidade. Mas, novamente, se você mudar as cores e não for muito bom em design ou mesmo em acessibilidade, talvez as cores que você usará colidirão, elas podem ter problemas de contraste.

Stephanie: Por exemplo, eu adoro laranja, mas é uma das cores mais chatas de se trabalhar porque ter um laranja realmente acessível, por exemplo, como um botão com texto branco, quase parece acastanhado. E se você quiser ter esse laranja realmente brilhante, você precisa de um texto escuro em cima para torná-lo legível, mas isso faz com que sua interface pareça o Halloween no final do dia. Sim, eu vejo você rindo. Mas é verdade. Então, é sempre sobre esse tipo de compromisso e dizer que se você é um desenvolvedor e quer usar o framework como está e não tem um designer, acho que ainda é melhor do que não ter nada e construí-lo do zero e então é super complexo de usar. Mas o fato é que só porque você tem os componentes não significa que você construirá uma ótima interface. É como peças de Lego. Se você tem os tijolos de Lego, tudo bem, mas você pode fazer uma nave espacial muito legal ou você pode fazer algo que não está se encaixando e vai desmoronar porque você não tinha realmente um plano.

Stephanie: Então o design é mais do que isso. Design é realmente entender o que vai estar na tela, como vai funcionar. E eu conheço alguns desenvolvedores que realmente têm a capacidade de fazer isso. Então, eles são muito bons com diretrizes de usabilidade e entendem muitas regras de design, por exemplo. Então, quando se trata de escolher os componentes, eles são muito bons nisso. E conheço desenvolvedores que não têm ideia de quais componentes escolher e escolhem o primeiro que faz o trabalho. Mas depois de um tempo não funciona mais. Como as abas, por exemplo, tínhamos uma interface onde alguns desenvolvedores escolhiam as abas. Acho que faz sentido no início quando você tem apenas três itens. Mas então havia 12 itens na tela e então você tem as abas que são três linhas de abas, e todas essas são abas do mesmo nível um, e há abas dentro de abas. Então eles tinham o componente, parecia legal porque eles usam o framework, mas não era realmente utilizável.

Stephanie: E eu tive o mesmo com janelas modais, por exemplo. Onde eles constroem os projetos sem designer e depois de um tempo acho que o cliente pediu cada vez mais coisas nesse modal. Então eles acabaram com uma tela com uma tabela e quando você clica em adicionar uma linha, você abre um modal, e nesse modal você tem duas abas, e então em uma dessas abas você tem até outra tabela e aí eles queriam adicionar uma coisa extra a isso, eu estava tipo, ok, talvez possamos colocar um modal em cima de um modal. E em algum momento o designer responderia, ok, se você tem tanto conteúdo no modal, não deveria ser uma janela modal. Deve ser uma página. Portanto, mesmo que você tenha o componente, ainda precisa de um arquiteto para fazer o plano e garantir que todos esses componentes funcionem bem juntos.

Drew: Então, se como designer, você está sendo solicitado a mudar o estilo de alguns componentes, você tentaria mudar todo o estilo? Você personalizaria tudo isso ou há certas áreas nas quais você se concentraria?

Stephanie: Cores Eu acho que porque é a primeira coisa que você vê, as cores podem realmente trazer identidade. Se você tem uma identidade de marca forte, pelo menos ter as cores do seu produto nos botões ou nos ícones e coisas assim, já te ajuda a customizar o framework. Fontes porque eu acho que é fácil, se o framework for bem construído, normalmente você muda toda a família de fontes em algum lugar e então deve meio que cascatear no resto do site. Então cores e fontes são duas maneiras fáceis de personalizar rapidamente a estrutura. Ícones é outra boa maneira de trazer personalidade, mas pode ser difícil porque, pelo que vi, a maior parte do framework vem com ícones personalizados ou Font Awesome ou como uma biblioteca já incorporada. Então, para substituí-los, primeiro você precisa de um muitos ícones se você quiser substituir todos eles. Então pode ser um pouco complexo. Também vi frameworks que permitem escolher qual pacote de ícones você deseja usar. como Font Awesome, Glyphicons e alguns dos outros. Portanto, esse é o tipo de coisa que você pode personalizar facilmente.

Stephanie: E então é sobre aparência, por exemplo, o cabeçalho, geralmente você tem diferentes tipos de cabeçalhos, rodapés. Como você navega em coisas assim. Portanto, já há muitas pequenas personalizações que você pode trazer para que não pareça Material-UI-ish, parece mais com sua marca e, em seguida, você pode brincar com o raio da borda, por exemplo. Se você quer botões completamente arredondados, ou quer botões quadrados ou quer algo no meio, como sombras também. Então, algumas coisas pequenas que geralmente são fáceis de personalizar porque a maioria desses frameworks as tem em variáveis ​​CSS. Este é o tipo de pequenas coisas que você pode personalizar sem muito esforço, exceto por esses efeitos de ondulação. Eu odeio isso. Eu vou lutar contra isso. Eu meio que espero que eles mudem isso eventualmente.

Drew: I guess things like that, that might seem obvious might seem just like a surface level effect, Do you think that would be easy to change and in this case it turns out it wasn't easy to change? Is that just a case of speaking to your developers to find out what's going to be easy to customize and what's not going to be easy?

Stephanie: Yeah, usually, especially if they're used to work with the framework, they know what's easy to change on it. It depends on the developer, I had discussion with one developer and I asked him if we can not have like uppercase buttons, because they are kind of a little bit hard to read, especially in the font we were using, he went into the documentation and say, I don't know if we can customize it because I can't see it in the API. I was like, what API? It's like CSS class, CSS definition. You remove the uppercase from the CSS and it's done. So he was like looking for an API to change just the font, how does the font look like. And I was like, yeah, but if there's no API for that, I think you can change it in CSS.

Stephanie: But then it's complex because if you have to change this in like all of the CSS line. So it's usually kind of a big discussion. It was the same… was like drop downs. So Material-UI, the React version we use, has some customized drop downs. So when you have a select box like form element, the select it opens these custom components and I don't know why but we have a big problem with that on Internet Explorer. We are going to migrate to windows 10 and Edge. I'm looking forward to it, but we are still Internet Explorer 11 at the moment. And what's happened is whenever you use or you open one of those components, it freezes the screen behind it and you have a scroll bar, so it kind of jumps around whenever you want to use one of those.

Stephanie: And at some point we discuss with the developer, is the customizing of that worth the screen jumping around whenever users click on that. And it's like, honestly for me, no, I prefer it not to jump and we use the select in the browser, then it will not look the same if our users have Edge and, no not Edge, IE. Or if some users are using Firefox, okay? So it will not look the same but it will be the native one and it will not make the page jump around every time someone clicks. So it's this kind of discussion also, do we want to customize it but then it's kind of clumsy or do we say, okay we are not going to customize it. We had the same debate with a scroll bar because we had another project we had drop-downs and they were 100 elements at some point in the drop downs. So there's an auto complete but you can still scroll inside the drop down. And the developer said, yeah but this is looking really ugly on IE, the default scroll bar.

Stephanie: And they investigated, they found JavaScript library that would let us have this really small little a scroll down you have on Mac and have it everywhere. Then we said, okay, is it worth investigating? We need to investigate, test it, put it everywhere, test all of the browsers. So we said we are going to do it, but only if it doesn't damage the performance and if he doesn't damage the rest of your experience, otherwise it's perfectly normal that the browser element don't look the same on any browsers. So at the end, don't customize everything.

Drew: I guess it's a collaborative team effort, then? Everyone needs to discuss and balance up again all the different performance factors, ease of customization and where that customization happens. So once you've got your UI framework in place, you've got all your components specified and built out and customized and styled to how you want them. I guess you need to document that in some way to maintain consistency?

Stephanie: So at some point as a designer what we usually do, we already document them in our sketch files. So we have the working files with every single screen and everything. And in the sketch files we have really specific art boards where we put all of the different components. So that if another designer works on the project, they know that the components already exist and they can just drag and drop it in a new page and reuse it afterwards. So we have this system where we document the components also we document the use, like when do you use this component? When do you use that one? Where is this one working better? So all of the different states for instance, like inputs, we have I think 10 of those, like a focus with a placeholder, without a place holder, with content like arrows and things like that. So again, we bring consistency and then the development parts, it really depends on the kind of maturity of the communication of the team. So what we are currently building is basically a library of components and we are also building the tool around it.

Stephanie: So my developer is currently building that and the idea is to build the component first in our kind of a sandbox, document it. Also he builds things where you can change the colors and if have a button for instance, you can change the icon, you can change the text to see if it will still work with longer text, smaller text, things like that. So we are building this sandbox and in the sandbox, you have a 'Read me' tab where you have documentation for how should this look, how should this component be used, when, how is it supposed to behave? Like auto complete for instance, seems to be something really, really easy, But if you start actually designing the flow of the auto complete, what happens when you put the focus in the field? Do you start auto completing or offering suggestion after one character after two, after three? If it's after three, what happens in the meantime?

Stephanie: So there's a lot of different questions about that that we also document, which is really going super deep into that so that if this auto complete gets implemented on another project or gets used by another team, they know exactly how it's supposed to work as well. So we kind of do the same. The two of us, so designers are documenting into the design tools and usually in the design tool we document the colors and shadows and gradients so that the developer don't have to look around and try to remember exactly what the hexadecimal code for this button was and things like that. So in the end it's kind of you have this UI framework that was super generic and you customized it, you made sure that the components you use are actually the ones that are going to help your user accomplish their goals.

Stephanie: Everything you've customized is kind of starting to become your own little design system. So at the end you're building a design system, but instead of building it from scratch, you're basically building it using React, Material or, what was the other one? Ant or something like that. So it's the same constraints.

Drew: Would you go back to user testing at this point after things have actually been built? Would you go back and test things with users again?

Stephanie: We have tests, like real people testing, like regression testing and making sure that everything works. Like when you click it works, when you hover it works, stuff like that. But yes in the end, especially if we didn't do a prototype, if we did the user testing in mockups, we want sometimes to test it again with the real users who have a feeling that everything is still working. So yeah, sometimes we go again into user testing at the end. We do that usually at the end of a few sprints where the features were implemented. So usually what happens is like we do the research, we design the feature into design tools, we do quick testing at the beginning, then it's implemented, we do tests to make sure it works. And then again we go back to the users.

Stephanie: And it's also interesting because we are building a community with the users. So they're actually quite eager to see that. The first testing was a little bit kind of a sneak peek, like, Oh, this is what it might look like. And then they are super curious about how it works and how it looks like at the end. So we go back usually in one-on-one testing for that or if we don't have the time, we do just like panels and also we deploy it. So sometimes we do AB testing also sometimes if we don't have time for the user testing one-on-ones, we deployed it and then we say, okay, it was deployed. If you have any feedback, please come back to us. Also if you see bugs, because sometimes we compete, the team missed a bug or something, so if we don't have time for re testing it, we still try to find and manage to find some ways to gather feedback even after it's deployed.

Drew: And over time, one of the things that might be a concern probably from a technical point of view is that you've built on top of a UI framework and then a new version of that framework comes out and things have changed. Is that a situation that you've experienced where a new version has come, your developers want to update but it might have implications on the design?

Stephanie: Yeah. The thing is we have test environments, so they're really quick and easy thing to do is like, okay, let's put in your version in one of those secure environment and see what is broken. So from when designers most of the time when they do a new version they tell developers, is it going to break? Like is this new version something completely new and it's not compatible with the old version? Or is this new version something that is just an announcement and you might not break that many things. So yeah, obviously sometimes when you put a new version it completely breaks, but this is again, then you have like testing stories and like technical investigation stories to decide if we are going to migrate or not. Also like from what I understand in some of the environment I worked on, they kind of encapsulated those in web components.

Stephanie: So they're already has kind of two different version of Angulars on some components, it was using one version on the other ones it was using the other one and from what I understood it works because then you only encapsulate what you need. So this apparently is also a solution is then you can use whatever version you want, but I'm not a developer but I feel at some point you'll be like, okay, this component is using that version of Angular and this one, this and this maybe kind of becomes super hard to maintain. Você sabe?

Drew: Yup.

Stephanie: It does. OK. So yeah, you make sure it still works, but I don't have the feeling that Material-UI are like those frameworks, even bootstrap for instance, they don't have any new version every year or something. It's a long lifecycle and in the case of my tool, I think this tool will be here for the next year, so we have eventually to update. But if you're building kind of a online tool, more like a B to B product. Most of the time you revise every three years or something. And usually there is a new technology. I was talking to a friend and they're currently working on a project where they're rebuilding and riffing on React. The first version was built three years ago with another technology. I really don't remember the technology, but they say, okay, we are three years later, they're already rebuilding it. And I think in like three years, they will re-rebuild it. So at some points if you're in like in B to C products, I even wonder if you update your framework or if you are going to change the design and rebuild it anyway in a few years from scratch.

Drew: Is there anything else that we should be considering when building on a UI framework?

Stephanie: I feel we covered a lot of things. Well, the thing is like, there's always a way to do it quick, user research, talk to users or at least do usability testing. Make sure you don't design or build in a silo and try to have other people at least look at what you've created to make sure that the components as a developer, that you used as a developer I really do wonder are going to do the job. And don't ask the designer to put paint on top of the framework at the end of the project because it's kind of already too late to do big infrastructure on changes. It might not work.

Drew: So at Smashing, we have books, we have conferences, and of course, we have Smashing Magazine, a website with loads of articles. We're all about learning. So what is it that you've been learning lately?

Stephanie: I've been taking online introduction to psychology class.

Drew: Tell us a bit about that.

Stephanie: Last lesson was actually super interesting. We were talking about visual illusions and how they work with your brain. So it's really super complex and there's… Apparently not everyone agrees on the explanation of most of those illusions, but it's interesting because I had a small psychology lesson, like I read books on cognitive sciences and things like that. So I already knew kind of the basics, but it's interesting to see like all the different aspects of psychology. So the interesting part of this course is it's an introduction but it explains to you kind have all the branches from say child development psychology to trauma psychology to intercultural psychology. So and then illusions and I think this week it's actually about cognitive psychology and how to apply psychology to interfaces. So all of those really, really interesting topics. And it's nice because it's an online class, so I'm basically learning stuff on my couch with some tea, and yeah, that's really, really cool.

Drew: Oh, that's super interesting. If you, dear listener, would like to hear more from Stephanie. You can follow her on Twitter where she's @WalterStephanie, or find her on the web at stephaniewalter.design. Thanks for joining us today, Stephanie. Do you have any parting words for us?

Stephanie: Thanks for having me. It was a smashing experience.