Muitas vezes, em uma empresa, o design depende inteiramente do designer. Ele pode até mudar de repente completamente, apesar dos gritos de protesto das "frentes" e "mobilshchiki". Temos uma opinião diferente: a visão de mundo interna do designer ou a visão do desenvolvedor não deve afetar muito o produto. O design do produto é a parte visível do negócio com o qual o cliente interage. O designer não pode apresentar sua "Lista de desejos", ele deve se concentrar nas necessidades dos clientes. Bons produtos se desenvolvem organicamente, de olho no cliente. Isso se aplica tanto à saturação funcional quanto ao design.
Um designer não deve ser um portador de requisitos para um aplicativo; uma empresa deve ditar o que será. Não importa quem trabalhe no design dos ePayments, o site e o aplicativo serão bonitos e convenientes, e o estilo não será alterado drasticamente em 180 °. Esse princípio funciona em benefício dos desenvolvedores de front-end e móveis.
Hoje, eu, o designer do projeto Timur, vou lhe contar como redesenhamos o aplicativo móvel e como nosso sistema de design apareceu.
Como tudo começou
Quando cheguei ao projeto, o aplicativo tinha a seguinte aparência:
E antes disso, era geralmente assim:
O que não combina comigo:
1. O aplicativo não foi dimensionado. Inicialmente, tínhamos 2 moedas (EUR e USD) e 2 cartões (para as mesmas moedas). Eles estavam rigidamente interconectados visual e logicamente. A seção do dólar é um cartão de dólar e assim por diante. Em seguida, o RUB foi adicionado e todo o layout começou a "ir". Para adicionar novos elementos teve que usar muletas. A EPayments planeja expandir a lista de moedas e precisávamos descobrir como adicioná-las sem problemas para o cliente. O comportamento em todas as telas deve permanecer previsível. Se em uma tela a lista de moedas foi processada por um padrão de comportamento específico, na outra tela o padrão de trabalho com moedas deve ser repetido.
2. Design desatualizado. O aplicativo parecia muito "lixo" e difícil, eu queria mais ar e menos elementos desnecessários. Por que precisamos de gradientes e "beleza" se após 5 minutos os olhos começam a se cansar na aplicação?
3. A diferença no design. Para iOS e Android, havia 2 aplicativos fundamentalmente diferentes. Se uma pessoa mudasse de um sistema operacional para outro, ele perderia toda a experiência acumulada do usuário. O proprietário da Samsung não pôde informar ao proprietário do iPhone como conduzir a operação.
4. Fluxo de trabalho não ideal. Quando tivemos uma nova maneira de transferir fundos da carteira, essa tarefa chegou ao analista que fez o mocap. Então ela veio até mim e uma tela foi desenhada para tradução. Em seguida, o desenvolvedor móvel transformou tudo em código e o inseriu no aplicativo. Este é um processo doentio, do qual foi possível gerar 80% dos custos de mão-de-obra. Você pode economizar muito tempo aqui, simplesmente eliminando o designer da linha de montagem. Se houver elementos de interface prontos, você poderá montar janelas de conversão a partir deles.
Projetando um futuro melhor
E então eu comecei a trabalhar. Antes de tudo, eu queria fazer um aplicativo fácil de usar. Os serviços financeiros geralmente não devem ocupar um cliente por muito tempo. Nele, você precisa navegar rapidamente, escolher uma operação, conduzi-la e continuar seus negócios.
Outra constante importante é a facilidade de desenvolvimento. Se tivermos um novo chip, moeda ou serviço, frentes e mobilizadores não devem sofrer e despertar todos os estilos. Eles simplesmente adicionam um novo recurso que parece claro e esperado.
Eu estava procurando a analogia mais simples e percebi que precisávamos de um construtor de janelas. Temos um conjunto de controles (voltar, avançar, seleção de contas, inserir detalhes) e regras para trabalhar com eles (cores, recuos, tamanhos de elementos). No designer, analistas e trabalhadores móveis podem criar novos cartões de serviço e janelas modais sem virem para mim "curvando-se".
Era importante considerar que o produto está se desenvolvendo em amplitude. Hoje temos 3 moedas, em um ano podem ser 33. Hoje damos 15 maneiras de transferir dinheiro, amanhã será 115. No aplicativo podem aparecer entidades completamente novas: cartões virtuais, compra de ações ou outros serviços.
Descarte os grilhões das limitações
Problema : o projeto tem um número crescente de elementos - moedas, métodos de transferência e assim por diante. Muitos elementos são organizados horizontalmente, quanto mais houver, mais inconveniente será usá-lo.
Solução : prever a expansão com antecedência, escolha o posicionamento conveniente dos elementos.
O principal problema da versão anterior é o dimensionamento. Portanto, temos uma tela condicional com uma resolução de 480 * 720 px. E, horizontalmente, existem três guias com métodos de transferência de dinheiro. Bem, amanhã eles terão 15 anos. Quem, em sã consciência, irá rolar 15 abas para a direita? Ou você precisa torná-los de tamanho micro para poder entrar neles apenas com o dedo mindinho?
Nos ePayments, o cliente possui uma carteira com várias seções de moeda. O elemento mais escalável da interface do usuário móvel é a lista. Pode ser virado quase sem fim com um movimento completamente familiar. Mesmo que de repente haja muitos elementos, você sempre pode fixar o filtro ou pesquisar.
O limite de conveniência é algo em torno de 10 moedas ou métodos de transferência. Quando houver mais deles, conectaremos o segundo mecanismo, que agora está em desenvolvimento - as seções selecionadas. O próprio cliente escolhe quais seções da moeda são mais importantes para ele e as marca com um asterisco. Ou constrói seu painel no construtor, como a tela inicial do Jira.
Além disso, eu tinha um "hambúrguer" à esquerda e uma barra de torneira na parte inferior. As operações mais importantes que colocamos no painel inferior. Primeiro de tudo, você analisa o saldo de seções e cartões. Depois, você pode ir para a recepção ou transferência, ver o histórico da transação ou a moeda de troca. Todas as coisas menos importantes que coloquei no "hambúrguer". Agora existe, por exemplo, um programa afiliado que é acessado com menos frequência.
Ok, o problema está resolvido, vá para o próximo.
Mantemos as diferenças no passado
Problema : os aplicativos iOS e Android não são iguais. Seu design está desatualizado, a interface possui muitos elementos extras. É difícil para o cliente se concentrar, ele rapidamente se cansa.
Solução : faça aplicativos de acordo com as diretrizes, mas com um design unificado. Limpe de gradientes, trabalhe na usabilidade.
Como eu disse, as versões para Android e iOS eram aplicativos fundamentalmente diferentes. Não há nada de bom para o cliente ou para nós. Além disso, os desenvolvedores tiveram problemas ao lançar novos recursos e testes. Portanto, decidimos trazer tudo para uma forma.
Você não pode fazer aplicativos idênticos. O Google tem Design de materiais, a Apple tem interfaces humanas. Mas os elementos básicos que fazemos semelhantes. A grade, a maioria dos controles e a disposição dos blocos ficaram iguais. Os controles responsáveis pela estrutura básica são adaptados aos guias do sistema operacional. A solução mais fácil é portar totalmente o aplicativo. Mas isso é antes um sinal de preguiça e ignorância dos guias. E os guias são escritos por pessoas que são muitas vezes mais inteligentes que nós, vale a pena ouvi-las.
A primeira vez que atualizamos o aplicativo no Android. Era mais barato nos "pontos da história", a maioria dos nossos clientes usa esse sistema operacional. Além disso, em algum momento, tivemos um desequilíbrio na equipe de desenvolvimento móvel - havia mais pessoas na equipe de desenvolvimento do Android e poderíamos alocar algumas delas para o reprojeto. Esta versão foi em frente e a versão para iOS agora está alcançando gradualmente.
É baseado em guias de design de materiais e, graças a isso, temos um aplicativo em que uma pessoa com Xiaomi condicional está familiarizada com tudo. Ele aprende rapidamente como enviar o dinheiro ganho para um cartão bancário.
Quando lançamos o redesenho, começamos a coletar reações e críticas construtivas. Primeiro, houve um pequeno fluxo de negatividade daqueles que não gostam de redesenhar como um fenômeno. Isso é normal e não deve ter medo. Cada serviço é confrontado com isso. Então tudo se acalma e você pode coletar informações úteis.
No início, a classificação caiu um pouco e depois voltou para 4,6. Fizemos alguns comentários críticos e as críticas tornaram-se boas e gentis novamente. A partir deste momento, você pode assumir o aplicativo para iOS.
Agora, os aplicativos são bastante semelhantes. Algumas coisas são feitas deliberadamente, não de acordo com as diretrizes, mas a principal métrica é a reação do cliente. Tudo parecia conveniente para os usuários: a avaliação não mudou, fomos agradecidos pelo reprojeto nas revisões.
O fato de os aplicativos terem se tornado semelhantes se refletiu no desenvolvimento. Agora eles são mais fáceis de testar, os casos no Testrail são os mesmos. Toda a documentação do caso é duplicada - naturalmente, conforme alterada. Por exemplo, quando estamos preparando um recurso em um aplicativo iOS, ele já possui JSON do Android e os desenvolvedores não precisam fazer solicitações.
Damos as rédeas do governo
Problema : O processo de desenvolvimento não é otimizado. Cada novo cartão de tradução é elaborado e desenvolvido do zero.
Solução : crie um conjunto de elementos e regras prontos, transformando o processo em um "designer".
A ideia do designer apareceu junto com o redesenho do aplicativo, mas o implementamos um pouco mais tarde. Como eu disse, o aplicativo não deve depender de mim. Se introduzirmos um novo recurso, a tarefa passará do analista para os desenvolvedores móveis. Eles montam uma janela a partir dos controles concluídos, verificam seus estilos, margens e tudo mais - e pronto, a janela está pronta. Eu posso criar um ícone, mas minha participação direta deve terminar aí.
Primeiro, desenhei cada tela individualmente. Em seguida, ele agrupou elementos repetidos: listas, controles, botões, ilustrações, telas de confirmação e assim por diante. Quando o aplicativo estava pronto, eu tinha uma interface do usuário completa do componente.
Veja os elementos, todo mundo tem algo parecido:
• título
• "voltar"
Droplist
• linha para inserir detalhes
• "próximo"
Fazemos esses elementos antecipadamente. Além disso, preparamos guias para cores, recuos e fontes. Na saída, obtemos um construtor no qual o desenvolvedor transforma o desenho no Paint condicional do analista em uma janela de tradução finalizada.
Naturalmente, os trabalhadores móveis tiveram que trabalhar para transformar várias telas em um sistema de componentes organizado. Mas aconteceu com eles depois: não era mais necessário ir ao Zeplin para o layout da tela, compor e armazenar no futuro. Existem componentes, existe uma rigorosa folha de estilos.
Resumir
Eu gosto do que fizemos. A aplicação ficou mais bonita, foi apreciada pelos clientes. Tornou-se mais fácil para as frentes e mobilizadores trabalharem.
Ainda não estamos utilizando totalmente métricas que mostram como o comportamento do usuário mudou. Portanto, agora só podemos julgar pelas classificações e comentários dos clientes. A classificação permaneceu a mesma - 4.6 no Google Play, 4.8 na AppStore. A maioria das análises negativas está relacionada ao processo de verificação, parece que os clientes já estão há muito tempo. E no positivo, o aplicativo é frequentemente elogiado.
Outra métrica, apenas interna: eu muito raramente abro um arquivo de esboço com um projeto móvel. Os desenvolvedores estão adicionando novas maneiras de depositar e sacar sem mim. Isso significa que a interface do usuário do componente está funcionando e eu pude tornar o design sistêmico, sem a ditadura do designer.
Agora, planejamos dar uma olhada no produto em diferentes plataformas, incluindo a versão para desktop. Além disso, planejamos "escavar" toda a estrutura de recursos dos aplicativos móveis, para que o cliente gaste ainda menos tempo nas operações. Bem, ao mesmo tempo, abandonaremos o hambúrguer à esquerda - esse é um padrão desatualizado, existem opções mais convenientes.
Procurando emprego?
Estamos à procura de funcionários para trabalhar em um escritório em São Petersburgo. Se você está interessado em fintech, estamos esperando por você. Abaixo, você encontrará vagas e links para as páginas correspondentes de hh.ru.