🧥 😛 😨 Design de produto sem designer 🐤 🙏🏼 🤙

Trabalho na KORUS Consulting CIS há 3 anos e, durante esse período, participei do projeto de dezenove serviços B2B. O design de interação geralmente é associado ao Axure, InVision, Moqups, Framer (insira sua opção favorita), mas minhas ferramentas são HTML, SCSS e AngularJs. Vou lhe contar como a prática usual de salvar modelos HTML cresceu nos almanaques de layouts completos e como um grupo de tipógrafos liderados por um diretor de arte projetou a interação com as interfaces de todos os produtos KORUS Consulting CIS por seis anos.

E por que funcionou?

Em “Um hospital psiquiátrico nas mãos dos pacientes” no capítulo “De onde vêm os designers de interação”, Alan Cooper escreve que as habilidades necessárias são fáceis de encontrar em qualquer participante do desenvolvimento. O design pode ser realizado por um gerente de projeto, analista, redator técnico, profissional de marketing, desenvolvedor. É bom quando essa função é assumida por um especialista separado, de preferência um designer. O KORUS atribuiu esse papel aos codificadores. Mas não de uma vez.

Photoshop rejeitado

Até 2019, não havia designers na KORUS. E até 2011, não havia ninguém para ouvir sobre uma experiência do usuário. Como desenvolvedora de software que se preze, a empresa procurou trazer rapidamente o produto ao mercado, e analistas e desenvolvedores foram responsáveis pela aparência e comportamento da interface. Principalmente desenvolvedores.

Portanto, quando em 2011 um codificador com as habilidades de um designer apareceu na empresa, antes do desenvolvimento, ele era permitido apenas nos estágios finais.

Um novo (lido - incomum) para o especialista do KORUS encontrou um esquema de desenvolvimento típico, onde ele tinha permissão para mover pixels e pintar, quando os principais recursos já estavam implementados. Soa como design após o desenvolvimento. E isso é descrito em detalhes no Hospital Psiquiátrico, Sr. Cooper. KORUS poderia ser considerado um herói de livros didáticos de suas histórias.

O Photoshop ou outro editor gráfico entrou nesse processo de desenvolvimento com dificuldade. Desde o início, contamos mais com o layout, porque é mais fácil de editar, especialmente diante das exigências em constante mudança. E você pode dar o layout para o desenvolvedor. Projetar, escrever e inspirar uma beleza ao mesmo tempo é muito mais eficiente. Com essa abordagem, desenhar em qualquer editor é um link intermediário desnecessário, e provavelmente muitos teriam concordado com isso em 2011.

A rejeição das ferramentas de design ajudou a estabelecer uma nova trilha no topo do esquema bem estabelecido e a começar um longo caminho para o design correto das interfaces. Quando o tempo de desenvolvimento é limitado, o layout do PSD se torna apenas uma recomendação, o layout é mais como um conjunto de regras, é mais difícil dar meia-volta e esquecer o caso invisível. Ou considere, com base em suas próprias idéias sobre conveniência.

O layout também permite salvar componentes individuais para não perder tempo da próxima vez, e a primeira página HTML com esses componentes é mostrada abaixo:

Tornou-se o primeiro bloco para o repositório do futuro kit no AngularJs. Inicialmente, foram impressos formulários impressos e páginas individuais de nosso serviço de gerenciamento de documentos eletrônicos (doravante denominado Courier).

Quando o repositório cresceu, e havia muito mais layouts, ele foi chamado de UIKIT e um ninja-gatinho no logotipo:

em 2015, nossa empresa se esforçou para interagir com o Sberbank, e surgiu a questão de repintar o serviço. A KORUS repetidamente usou o fato de que já existem conquistas em componentes e estilos: basta alterar as cores para combinar com o estilo corporativo da Beeline, Alfa Bank, etc. Graças a essa experiência, o Courier foi repintado em apenas uma hora.

E imagine se, a princípio, o designer repintou os layouts gráficos e o designer de layout mudou os estilos? Duas tarefas - uma solução: já o layout no UIKIT.

Como impedi-los de fazer "mau"?

Surpreendentemente, nos primeiros 4 anos, apenas um especialista lidou com todas as tarefas de design. Os desenvolvimentos no UIKIT foram salvos, o que economiza bastante tempo: o designer conseguiu se conectar ao desenvolvimento o mais cedo possível e evitar terríveis soluções de interface.

A expansão do portfólio de produtos naturalmente levou ao surgimento de novos designers de layout. Isso permitiu que o ninja das baleias alocasse mais recursos, e os layouts se tornaram mais interativos. Não basta vincular links HTML, queremos mais. JQuery e AngularJs foram utilizados. Os protótipos ao vivo foram classificados principalmente por analistas. Você pode clicar em todos os estados, tirar capturas de tela e colá-las no TK.

“Fizemos algo semelhante ao BEM, mas não o BEM, e, assim, fomos à unificação do layout em todos os projetos”

No entanto, se tudo estiver claro com o designer de layout, o designer de layout pode apenas ser guiado por diretrizes e sua própria experiência rica na composição de vários layouts para criar algo simples? Os designers de layout são capazes de montar a interface como designer e não esperam que alguém lhe diga onde colocar o botão. Eles já viram esse botão na barra de ferramentas várias vezes. Designers chamam isso de obscuridade. E o KORUS precisava de casos de vida compreensíveis, chamados de "design natural". E se você se lembra de que os produtos de um ecossistema geralmente são semelhantes entre si, e a exclusividade os prejudica, então minha resposta é sim.

O advento do UIKIT acelerou o processo de prototipagem. Demonstração de layout clicável foi usada para pré-venda, coordenação dos detalhes com o cliente antes do início do projeto. E, finalmente, os desenvolvedores receberam as informações necessárias sobre o comportamento da interface, para não elaborá-las diretamente no processo de codificação.

“As frentes tornaram mais fácil para eles. O UIKIT me fez parcialmente fazer o certo. ”

Interatividade com AngularJs

Foi precisamente esse tipo de esquema de trabalho que chegou ao KORUS após o surgimento do UIKIT: a necessidade surgiu, foi formalizada nos requisitos técnicos, os designers de layout o incorporaram imediatamente em um protótipo da web.
Restava obter alguma estrutura das profundezas da Internet, repintá-la com uma etiqueta verde e implementá-la em produtos para tornar não apenas botões e cabeçalhos uniformes para todos os serviços.

Além dos controles da estrutura do UIKIT, ele foi reabastecido com um conjunto de ícones, widgets, desenvolvimentos e estilos próprios.

Se houvesse uma tarefa para um layout de página semelhante a algo de nossos serviços, pegávamos o final, alterávamos o conteúdo para os requisitos e o wrapper e a lógica permaneciam os mesmos. As transições entre páginas podem ser configuradas, todos os botões e campos são clicáveis, podemos mostrar validação, janelas modais, sucesso no upload de arquivos. Podemos mostrar todo o caminho do usuário do início ao fim com cenários positivos e negativos, na representação de todo o modelo.

Interfaces uniformes

Reutilizar partes pré-projetadas da interface não é novidade para 2015. Mesmo há dez anos, designers de layout em estúdios da Web otimizavam seus processos para não redigitar o mesmo elemento todas as vezes. Não descobrimos a galáxia, mas isso foi apenas o começo.

É claro que quanto mais adicionamos layouts ao UIKIT, mais abordamos os casos existentes e poderíamos aplicá-los ainda mais a novos projetos.

Precisa de um novo layout de registro de usuário? Já temos isso: adaptamos as necessidades da empresa, gastamos não mais do que algumas horas nela e agora - o registro está pronto para ser transferido aos desenvolvedores, mas em um serviço diferente.

Precisa de uma tabela com dados da empresa? Essa bondade em nossos serviços a granel: CRTL + C CTRL + V.

O mais atraente para a equipe de layout é o estilo uniforme. As diretrizes são uma coisa que nos determina como devem ser os elementos atômicos de uma interface. Parece razoável corrigir o estilo desses componentes e alterá-lo apenas como último recurso. Não importa quantos layouts de novos produtos apresentamos no UIKIT, os estilos nos componentes estão em um só lugar. Para as necessidades do próprio projeto, existe um css de produto separado no qual você pode personalizar algo.

Sob a influência de diretrizes, otimização e nossa própria experiência, sempre tivemos à mão:

Entradas, botões, menus suspensos;
Mesas, laterais, menus, barras de ferramentas;
Formulários, cronogramas, janelas modais;
Todo o fluxo de processamento de algum tipo de pedido de empréstimo ou criação de um documento de pagamento.

Com tudo isso, já era possível montar interfaces completas e, graças aos AngularJs, nos layouts, foi alcançada a interatividade da produção, que era muito popular entre os clientes.

Em segredo, direi que realizamos uma demonstração para um cliente algumas vezes no UIKIT, porque tivemos uma bancada de testes logo antes da demonstração.

Circuito de trabalho

O tempo passou, o inspirador ideológico e criador do UIKIT tornou-se diretor de arte, havia mais e mais projetos. Quem continuará esse excelente trabalho - projetando interfaces em HTML usando a funcionalidade já desenvolvida? Designers de layout, é claro.

Dizer que os designers de layout estavam muito felizes com a perspectiva de trabalhar em estreita colaboração com analistas e pensar de forma independente através da usabilidade é um pequeno truque. Ainda assim, todo mundo (eu?) Se acostumou ao fato de que o designer de layout é um especialista que recebe um layout de um designer, o corta e o transforma em uma página da web. O design de interação acrescenta em alguns lugares um trabalho mecânico a uma responsabilidade incomum ainda não estudada. Mas fomos ajudados pela presença de uma pessoa que constantemente revisava nosso trabalho, sugeria como fazê-lo corretamente. E ele não apenas pediu, mas se referiu a fontes autorizadas, para que também as lemos e cometamos menos erros. O diretor de arte constantemente apontava para algumas leis de Fitts, depois para as regras de redação comercial ou para formatar o texto, enfatizando os elementos ... Resistimos, mas absorvemos as informações.

Hoje, podemos colocar dois botões verdes lado a lado - amanhã não fizemos isso porque sabíamos: o botão com a ação de destino deve ser um por página.

Hoje, todas as entradas ficaram presas na mesma largura; amanhã, criaremos o campo para o TIN exatamente para o conteúdo. Assim, o usuário lê melhor quanto tempo os dados são esperados dele.

O processo entrou em operação. Os designers de layout coletam interfaces, dependendo dos requisitos de negócios dos analistas, coordenam suas decisões com o diretor de arte e as desenvolvem.

Crescemos como designers, aprendemos a tomar decisões, nutrimos em nós mesmos a independência para expandir a gama de tarefas nas quais não é necessária uma imersão profunda do diretor de arte.

Em algum lugar desse pipeline apareceu o GitLab, uma revisão do layout, melhorando a visualização usando js.

Se o designer de layout enfrentou uma tarefa difícil e não padrão, o diretor de arte se conectou e ajudou a encontrar uma solução. Naquela época, ele próprio projetou o conceito de novos produtos.
Fornecemos 2 a 3 opções para nossa compreensão do problema, e ele escolheu uma e disse como poderia ser melhorado. Ocasionalmente, ele simplesmente dizia “ok” e ficamos felizes em entender que atingimos a meta. No entanto, às vezes não tivemos feedback suficiente para entender como nossa solução é conveniente e compreensível para os usuários, e mesmo se é claro para o diretor de arte. A dúvida nos fez tentar repetidamente interpretar os requisitos de várias maneiras.

Nosso líder tinha sua própria opinião sobre isso. Ele disse que dessa maneira nos fez pensar. Cada um, à sua maneira, avaliou o processo. Eu pensei que estava economizando tempo para mim e para ele. Tipo, deixe-me mostrar três opções ao mesmo tempo para não andar três vezes. Um tipo de teste A / B / C na artilharia para mim.

Embora, é claro, tenhamos aprendido muito (veja como esse designer de layout cita livros de design).

Como você entende, nesse processo não há lugar para uma reflexão detalhada sobre as análises de UX e UX. Embora com essa ferramenta iria testar e testar. O que o diretor de arte originalmente colocou no layout na fase de prototipagem foi usado. Todos os novos recursos já foram inventados e descritos por partes interessadas, gerentes e analistas. Não codificadores. Isso foi um sinal negativo, porque nem sempre conseguimos explicar de maneira conclusiva por que a solução já inventada pelo negócio não é adequada.

Na saída, o tipógrafo recebeu alguma descrição no Confluence do analista - como esta:

:
:
: « »
« » checkbox .
tooltip .

Um mocap impessoal nas praças da Basílica foi aplicado até à tarefa para mostrar a posição e o objetivo dos elementos na página.

Às vezes recebíamos tarefas de analistas com a seguinte redação:

Embora o UIKIT tenha entrado na pilha de ferramentas da empresa, sem as análises de UX, não havia argumentos de peso contra a tomada de decisões de interface, exceto a última palavra do diretor de arte. Mas nosso caminho para a interação perfeita continuou.

Com o tempo, conseguimos encontrar uma linguagem comum e dividir as áreas de responsabilidade pela qualidade e usabilidade da interface.

No total, todo o processo de criação de um layout de produto ficou assim:

- , UIKIT. , , , ;
, . , -, , . ;
O designer de layout tomou a fronteira do novo projeto e o complementou, colocando-o sob uma tarefa técnica mais detalhada. Se no início o cliente quisesse preencher o aplicativo em uma etapa e depois em duas, o designer do layout implementou isso facilmente. No futuro, o layout poderia mudar além do reconhecimento e, a partir da versão original, havia apenas estilos que, em princípio, não foram alterados. Tudo isso é gradualmente discutido passo a passo com o diretor de arte. No primeiro estágio, o protótipo foi alocado de dois dias a duas semanas, para que o desenvolvimento pudesse continuar por anos. Nesses projetos, nosso gerente ocasionalmente “entrava” em uma reformulação para compensar o aumento da massa crítica de recursos e repensar a interface de uma nova maneira.

A equipe do UIKIT levou dois anos para chegar a esse processo.

Demonstração visual

Em todas as etapas, o layout está disponível para demonstração ao cliente e à equipe. Essa é uma das vantagens mais fortes do UIKIT.

O que poderia ser mais conveniente e compreensível para o cliente do que seguir o link e clicar no layout, analisar o comportamento da interface? Ele pode avaliar e corrigir os textos, que depois vão para a produção. Às vezes, o layout elaborado no cliente alterava a ideia da tarefa, ele podia entender que sua ideia não era viável e concordar com as alterações. Se, por palavras, ele tinha certeza de que seu questionário com 150 campos caberia facilmente na interface, então, no layout, ele viu claramente que isso exigia melhorias. Mais importante ainda, jogar esse perfil no UIKIT é barato.

Um pequeno exemplo:

Primeiro requisito indiscutível e final:

Compromisso visto no processo:

Alguém pode notar que Axure, Figma, Marvel têm todas as vantagens do UIKIT descritas por mim ... Mas algumas não existiam no estágio de seleção de tecnologia, outras foram rejeitadas como um link extra entre design e layout.
O UIKIT é uma oportunidade de montar nem mesmo um protótipo, mas uma interface de produto pronta, que o front-end entrará em operação.

Reconhecimento da empresa

Até 2020, o UIKIT terá 38 modelos de projetos existentes, dos quais 13 estão em desenvolvimento. Essa é uma vasta experiência de quatro anos, na qual você pode encontrar milhares de soluções de diferentes especialistas, do diretor de arte ao testador. Todos eles obedecem às regras gerais de CSS e criação de páginas.

Com o tempo, precisávamos conectar novos plugins, organizar vários stands para o UIKIT (nosso interno para o desenvolvimento atual e externo para a versão fixa, que será desenvolvida), adicionar versões dos estilos, começar a importar o pacote de estilos para artifactory e nexus e facilitar o pacote npm Transferindo arquivos de mídia para CDN. Então nós mudamos para o SASS. Um conjunto aparentemente comum de layouts de sites se transformou em um projeto completo com suas implantações, atualizações da equipe e uma discussão ativa sobre futuras melhorias. Ou seja, nosso projeto, que inicialmente foi apenas uma ajuda para a prototipagem rápida, se transformou em um produto completo com seus processos inerentes.

O UIKIT foi apreciado por clientes, analistas, desenvolvedores e testadores também o apreciaram.

Um belo dia, recebi apenas uma pergunta importante da equipe de desenvolvimento de nosso cliente:

“Quando estão os layouts na baleia? Eles são muito mais convenientes do que os requisitos. ”

Para mim, como designer de layout, essa frase lisonjeava. Mas é melhor não fazê-lo, leia os requisitos.

Até esse momento importante, a equipe do UIKIT foi teimosamente até o reconhecimento do instrumento, mesmo entre colegas. O valor comercial do projeto era zero, o que significa que seu desenvolvimento estava inteiramente com os tipógrafos. Além das tarefas atuais, eles continuaram a otimizar seu trabalho. Eu gosto de ver o quanto nosso kit ninja cresceu ao longo dos anos, não inferior em potência à figura moderna, mas graças ao layout final e superá-lo.

Minha próxima história será sobre os detalhes técnicos do design usando o UIKIT, sobre como uma vez que nosso circuito sobreviveu a si próprio e quais etapas foram tomadas para desenvolver.

Design de produto sem designer