A história de um redesenho que mudou a abordagem de desenvolvimento no ISPsystem.
Entrei para o ISPsystem em abril de 2016. Naquela época, a situação com o design do produto era a seguinte: as decisões do produto eram tomadas pela gerência e pelos programadores, não havia designers ou designers. Como a situação do mercado exigia produtos com “outras interfaces”, a gerência decidiu redesenhar a parte do cliente do
BILLmanager . Era para ser um balão de teste, a primeira tentativa de fazer algo com um novo design.
Eu era o único designer de UX da empresa: estudei um produto existente, participei de pesquisas com usuários, familiarizei-me com o feedback dos parceiros e de seus profissionais de marketing. Essas são as práticas usuais de design de produto, levando em consideração as especificidades de um produto complexo. Uma grande ajuda foi-me dada pelo gerente de produto, pois ele conhecia o melhor de todos.
Toda semana eu mostrava o resultado na forma de protótipos, circuitos etc. para a gerência da empresa. É semelhante à maneira como os designers de clientes trabalham com os clientes, com todos os prós e contras: você pode se eximir da responsabilidade pelas decisões, o principal é "vendê-las" para a gerência. Mas como eu já tinha experiência em uma empresa de produtos e a gerência confiava em mim nesses assuntos, rapidamente começamos a trabalhar juntos em soluções que eu desenvolvi e transformei em protótipo.
Desenvolvedores encontram protótipo
Em agosto de 2016, os protótipos do cliente BILLmanager estavam prontos em sua forma conceitual. A funcionalidade da versão antiga do produto foi completamente transferida para a nova interface, com algumas melhorias. Os protótipos foram bem desenvolvidos do ponto de vista visual, mas eu queria mais, então pedi um design visual a uma empresa terceirizada. No entanto, rapidamente percebemos que essa tentativa não teve êxito; era necessário um trabalho iterativo constante no componente visual e precisávamos de um designer visual na equipe. Em alguns meses, desenvolvemos nossa própria linguagem visual. De fato, naquele momento tínhamos várias partes do futuro sistema de design: uma linguagem visual, elementos e modelos.
Paralelamente, a partir de agosto de 2016, os desenvolvedores começaram a implementar uma nova interface. Os caras consideraram o protótipo como uma alternativa à tarefa técnica. Como acontece nesses momentos, as perguntas começaram a aparecer em grandes números, que se resumem a uma coisa: fazemos o que os programadores implementam rápida e simplesmente ou o que foi inventado e projetado por um designer? Para resolver rapidamente esses problemas e simplificar a comunicação, criamos uma equipe de designers e front-end.
Departamento de UX como uma equipe de designers e front-renders
Em meados do outono de 2016, um departamento de UX foi formado na empresa sob minha liderança, que consistia em designers de UX, designer visual, propostas de front-end e testadores. Nossa tarefa imediata foi iniciar a conta pessoal do ISPsystem com uma nova interface (usamos o BILLmanager em casa) até o final de março de 2017 e tivemos dois grupos de problemas. Os desenvolvedores previram mal o momento de seu trabalho, e não entendemos muito bem como criar interação entre desenvolvedores e designers.
O que damos aos desenvolvedores
Quando você usa o Sketch e o Zeplin, a interação entre designers e desenvolvedores é muito simples. Mas tínhamos mais de 150 páginas em um protótipo interativo, que aprendemos a usar como alternativa ao TK para programadores e uma especificação para testadores. Não queríamos renderizar mais de 150 páginas com vários estados no Sketch e chegamos à conclusão de que faríamos isso apenas para páginas únicas. Além disso, todos os elementos deveriam ter aparecido no Zeplin: botões, campos de formulário etc. Depois de algum tempo, aprendemos o nome dessa abordagem - este é um
sistema de design baseado em design atômico . Ainda está em desenvolvimento, mas designers e desenvolvedores já o estão usando. O último da empresa para o sistema de design é o designer visual.
Como resultado, fornecemos aos desenvolvedores dois tipos de artefatos:
- layouts do que algum dia se tornará um sistema de design em Zeplin (ou melhor, já em Figma),
- protótipos de produtos, alternativa ao TK na forma de HTML gerado pelo Axure.
Ao mesmo tempo, o designer de UX está sempre pronto para informar aos desenvolvedores e testadores o que e como deve funcionar e ter a aparência.
Scrum com designers
Em fevereiro de 2017, decidimos melhorar a precisão dos prazos de previsão e tentamos implementar o Scrum. A complexidade do nosso Scrum é que os membros da equipe são muito diferentes em termos de competências e cultura. Designers não são como programadores: planejamos nossas tarefas de maneira diferente, temos atitudes diferentes em relação ao que é considerado um bom resultado.
Veja como construímos o processo:
- designers correm para a frente;
- Existe um backlog de protótipo, elaborado em termos gerais, no qual é possível ver como deve ser o produto inteiro;
- no momento do planejamento do sprint, os designers fornecem protótipos e modelos da parte do produto que está planejado para ser feito no sprint. Esses protótipos são detalhados e descritos pelo designer do UX até o ponto em que os desenvolvedores podem definir e decompor suas tarefas;
- no momento do planejamento, o designer do UX aconselha ativamente os desenvolvedores e testadores sobre o que e como deve funcionar;
- no momento do planejamento, o gerente de produto deve informar ao designer de UX qual parte do produto está planejada para ser executada no próximo sprint, para que o designer de UX possa planejar seu trabalho.
Os desenvolvedores perceberam rapidamente o valor de um designer de UX, que pode ser abordado rapidamente quando não está claro o que e como deve funcionar. Os conflitos ainda acontecem, mas as práticas do Scrum, o trabalho em equipe e os objetivos comuns ajudam a superá-los.
O que o testador tem a ver com isso?
O papel do testador nos processos foi muito importante. Essa é a pessoa que conhece melhor a funcionalidade do produto. O testador foi a primeira pessoa a examinar os protótipos de um designer de UX e rapidamente fornecer feedback em termos de conformidade e funcionalidade do protótipo. Os protótipos aprovados se tornam uma fonte de conhecimento para o testador sobre como o produto deve funcionar. Ambos os lados estavam interessados em uma cooperação estreita.
Como resultado, a equipe liberou pontualmente a nova interface da conta pessoal do ISPsystem. Aprendemos a trabalhar no Scrum, a prever o trabalho do departamento de UX como uma equipe de front-end e designers. E no verão de 2017, eles enfrentaram um novo problema.
O BILLmanager é um produto flexível. E isso é um problema para o designer
Quando um designer desenha um cartaz, escreve um livro ou faz uma capa para uma revista, ele trabalha com informações estáticas. Possui texto específico, determinadas imagens e outro conteúdo.
Quando um designer cria uma interface de aplicativo ou site, as informações não são estáticas. Há informações sobre quais podem ser os dados, mas os dados em si não são. Digamos que exista um blog, cada entrada de blog possui um título, anotação, data de lançamento do post, imagem etc. Não existe um título específico, mas há um entendimento de que sempre haverá um título e a data sempre terá um formato de data. A tarefa se tornou mais complicada, temos tipos de dados, mas não há dados: precisamos pensar sobre o conteúdo, quais restrições podem e devem ser impostas a ele. Provavelmente, haverá menos valor artístico do que o pôster, mas o designer deseja obter um resultado que seja bonito, conveniente e compreensível.
No caso do BILLmanager, o administrador do provedor de hospedagem pode alterar as configurações para que, por exemplo, no formulário de pedido de um servidor dedicado, o conjunto de campos possa ser diferente. Em um caso, definitivamente teremos um processador, disco e memória e, no outro, ele não (ou será, mas, por exemplo, será um campo), e isso não pode ser previsto. Nesse caso, o designer nem sequer possui um conjunto de dados fixo, não conhecemos apenas dados específicos, não sabemos os tipos desses dados ... e isso complica o trabalho.
Quando começamos a fazer a versão em caixa, os testadores começaram a verificar todas as configurações possíveis no BILLmanager. Então ficou claro que, por um lado, os protótipos não são completos o suficiente para cobrir as possibilidades de configurações flexíveis do BILLmanager. Por outro lado, a arquitetura do produto antigo não era flexível o suficiente para implementar um grande número de idéias de design. Do outono de 2017 à primavera de 2018, redesenhamos os protótipos e procuramos compromissos para resolver esse problema. E com algumas restrições nas configurações, eles lançaram uma
versão em caixa da parte do cliente do BILLmanager 6 Beta em maio de 2018.
UX departamento de designers
Enquanto o departamento de UX resolvia problemas com a flexibilidade do BILLmanager, a gerência decidiu processar as interfaces de outros produtos da empresa e implementar Scrum e processos de design em outras equipes. Começamos com o VMmanager 6, reunimos uma equipe de produtos completa de participantes de diferentes competências, auto-suficientes para criar um produto: back-end, front-end, testadores, UX-designer, gerentes de produto e projeto. Ficou claro que todos os outros produtos serão gradualmente desenvolvidos pelas mesmas equipes e iniciamos uma transição gradual para uma estrutura matricial para gerenciar o desenvolvimento do produto.
Nesse contexto, o departamento de UX deveria ter deixado de ser uma das equipes de produto. Após o lançamento da parte do cliente do BILLmanager 6 Beta, a maior parte do departamento de UX passou a fazer parte da equipe do BILLmanager e agora está envolvida na solução de problemas de arquitetura e na versão móvel da parte do cliente. Ao mesmo tempo, começamos a trabalhar na formação de um departamento de UX que pudesse trabalhar com todos os produtos simultaneamente.
Designer de UX para todas as equipes de produtos. Design Competency Center
O ISPsystem possui quatro produtos complexos. Garantimos que cada equipe tenha seu próprio designer de UX. Essa é a pessoa responsável pelo design do seu produto. Suas responsabilidades incluem preparar protótipos para o planejamento de sprint e controlar que tudo o que é necessário para os desenvolvedores está na versão pixelperfect. Ele é o condutor da política de design da empresa para sua equipe. Uma de suas tarefas é garantir que o resultado do desenvolvimento seja um produto que corresponda ao design.
Também temos várias pessoas que formam o centro das competências de design da empresa. Inclui um designer visual. Este centro forma a política de design dos produtos da empresa, trabalha no sistema de design. Ela também ensina designers de UX em equipes, resolve os problemas mais complexos de design, ensina desenvolvedores, gerentes de produto e projeto a trabalhar com designers de UX e implementa processos de design em equipes Scrum.