A sua própria aplicação EMS: o que personalizar primeiro

Comece pela sessão, depois pela marca

Uma aplicação EMS personalizada pode fazer com que um produto de treino seja percebido como parte de uma marca coerente. O trabalho de valor começa antes de escolher as cores: decida quem utiliza a aplicação, o que precisa de fazer durante uma sessão e que assistência a sua empresa pode prestar após o lançamento.

Apenas o controlador 2011 utiliza a MBODY, ligando a aplicação ao seu vestuário EMS por Bluetooth. A MBODY não dispõe de funcionalidades para membros. A MacroSea pode desenvolver uma aplicação dedicada para o cliente com interface personalizada e funcionalidades para membros. Um projeto de aplicação personalizada começa em 100 conjuntos de vestuário e controlador. As quantidades de outras encomendas são discutidas por modelo e projeto.

Para um estúdio, a primeira prioridade pode ser uma visão clara dos controlos durante uma sessão supervisionada. Para uma marca de consumo, pode ser um percurso de primeira utilização que o cliente consiga seguir em casa. Inclua essa diferença nos requisitos antes de solicitar propostas visuais.

Escolha um percurso de primeira utilização

Mapeie o percurso desde a abertura da embalagem até ao fim de uma sessão. Liste cada passo que o cliente precisa de compreender: preparar o vestuário e o controlador, abrir a aplicação, ligar o dispositivo, identificar os controlos, fazer um ajuste e terminar. Assinale os pontos em que alguém possa hesitar ou precisar de ajuda. Essa lista é um melhor ponto de partida para uma primeira versão do que uma longa lista de funções desejadas.

Dê ao fornecedor um cenário breve. Por exemplo: «Um novo cliente abre a aplicação junto de um controlador carregado e precisa de saber se a ligação está pronta antes de ajustar a intensidade.» Peça os ecrãs, rótulos e mensagens propostos para esse cenário. Teste-os com uma pessoa que nunca tenha visto o produto.

As orientações da Apple para os primeiros passos favorecem a aprendizagem em contexto e o adiamento de configurações não essenciais. Aplique esse princípio à experiência EMS: explique a próxima ação útil no local em que acontece, em vez de obrigar os clientes a ler vários ecrãs antes de compreenderem a interface.

Torne os controlos compreensíveis

O sistema 2011 permite ajustar a intensidade por zona numa escala de 0–100%, e o controlador tem 16 saídas independentes. O número de canais do vestuário é diferente: por exemplo, os calções 2011 têm cinco canais e 10 elétrodos. Use rótulos que correspondam às zonas reais de cada peça e ao comportamento do controlador.

Nos requisitos de design, esboce as informações que os utilizadores precisam de ver durante uma sessão: estado da ligação, peça ou zonas selecionadas, valores atuais e ação necessária para terminar. Defina como utilizar linguagem clara, números legíveis e áreas de toque adequadas ao seu público. Pergunte à equipa de desenvolvimento que elementos já existem na experiência atual e quais exigem design ou desenvolvimento adicional.

Inclua exemplos de perda de ligação e de regresso do utilizador à aplicação. Acorde as mensagens e o comportamento pretendidos com o fornecedor e depois teste-os no hardware escolhido.

Atribua uma função específica ao sistema de membros

Podem ser desenvolvidas funcionalidades para membros na sua aplicação dedicada quando apoiam o seu modelo de negócio. Defina primeiro a função: um estúdio pode querer distinguir funcionários e membros; uma marca de venda direta ao consumidor pode querer que os clientes mantenham uma conta. Especifique o que cada pessoa deve poder ver ou alterar e o que acontece quando deixa de precisar de acesso.

Possíveis adições, como preferências guardadas, histórico de sessões, reservas, pagamentos ou painéis para treinadores, pertencem a um plano de evolução de funções. Descreva o resultado pretendido e peça uma avaliação de viabilidade, custo e prazo para cada uma; não pressuponha que estão incluídas na aplicação base. Ordene-as pelo valor para o cliente e pelo esforço operacional. Se uma função precisar de funcionários para atualizar dados diariamente, defina o responsável antes de a incluir na primeira versão.

Mantenha a primeira versão focada: um percurso de controlo compreensível e as funcionalidades para membros de que o negócio realmente precisa podem ser mais úteis do que um painel sobrecarregado.

Planeie antecipadamente as permissões e a submissão às lojas

Se planear uma versão Android, relacione as permissões Bluetooth com as ações reais da aplicação e a versão de destino. Mostre aos utilizadores por que razão uma permissão é necessária no momento em que surge e teste o que acontece se a recusarem. Esta é uma questão de interface e assistência, além de uma tarefa de desenvolvimento.

Para publicar na App Store, as diretrizes de revisão da Apple exigem uma política de privacidade e, quando a aplicação permite criar contas, uma opção para iniciar a eliminação da conta na própria aplicação. O Google Play exige que os programadores preencham uma declaração de segurança de dados sobre recolha e partilha, incluindo código de terceiros relevante. Dê à equipa um inventário simples dos dados que a aplicação proposta utilizará e de quem operará os serviços associados.

Decida quem é titular das contas de programador, quem prepara as páginas nas lojas e quem responde às questões de revisão. Os requisitos das lojas e o plano final de submissão devem ser revistos para as plataformas escolhidas.

Crie um protótipo antes de fechar a lista de funções

Use um protótipo de ecrãs interativo ou uma versão inicial para percorrer a sessão principal com o vestuário e o controlador. Dê aos participantes uma tarefa em vez de uma explicação: ligar o dispositivo e encontrar o controlo de intensidade. Registe onde hesitam, que rótulos interpretam mal e se conseguem perceber o estado do dispositivo.

Depois teste as variações práticas relevantes para o negócio: modelos de telemóvel e sistemas operativos que pretende suportar, uma permissão recusada, uma ligação perdida e um membro que regressa. Registe o resultado esperado para cada caso numa lista de aceitação partilhada. Assim, as observações tornam-se decisões que o fornecedor pode implementar e o comprador pode verificar.

Separe os requisitos de lançamento das ideias para mais tarde. Uma primeira versão coerente oferece uma base fiável para o próximo pedido de funcionalidade.

O que incluir nos requisitos da aplicação

• Público: quem utiliza a aplicação, onde e com que peça 2011.
• Marca: nome, logótipo, cores, idiomas e referências de interface.
• Percurso principal: ecrãs de preparação, ligação, ajuste por zona e conclusão da sessão.
• Membros: os perfis de conta e funções necessários no lançamento, além das ideias futuras.
• Plataformas: países de destino, tipos de telemóvel, sistemas operativos e contas das lojas.
• Entrega: aprovação do design, dispositivos de teste, critérios de aceitação, responsabilidade pelo lançamento e manutenção posterior.

Apresente o número estimado de conjuntos de vestuário e controlador e o calendário pretendido na primeira conversa. Discuta os custos de desenvolvimento personalizado com a equipa comercial. A MacroSea pode então transformar os requisitos numa conversa sobre OEM/ODM sobre âmbito, design e produção. Partilhe os seus requisitos para começar.