Três erros comuns na criação de aplicativos móveis e como evitá-los

Padrão

Frequentemente, apps corporativos não entregam exatamente o que os usuários precisam, ignoram processos existentes e estão desalinhados com as estratégias de negócios. O que fazer?

Boa parte dos aplicativos móveis corporativos percorrem um longo caminho antes de serem considerados grandes sucessos. Infelizmente, os apps muitas vezes falham repetidamente pelas mesmas razões, com organizações deixando de ver os problemas antes que seja tarde demais. Sem qualquer motivo aparente, a adoção por parte dos usuários cai, o uso de aplicativos não aprovados pela TI torna-se comum, e o negócio começa a correr riscos desnecessários.

Com isso em mente, aqui estão três erros comuns que podem comprometer o desenvolvimento do aplicativo móvel corporativo – e como evitar que isso aconteça.

1. Não dar aos usuários exatamente o que eles pedem
Comece encontrando o seu melhor analista de negócio e passe algumas semanas compilando uma lista de requisitos para seu aplicativo. Depois de ter uma boa ideia do que você precisa, faça uma solicitação de proposta (RFP) e procure um fornecedor que não entende como funciona seu negócio para implementar o aplicativo.

Assim, você se sente confiante de que o app será um enorme sucesso: você entrevistou partes interessadas, criou uma especificação funcional baseada em processos existentes e anotou tudo. Como isto poderia falhar?

Eu tenho uma palavra para você: repetição. Quantas vezes você pediu exatamente o que queria em um restaurante apenas para ficar desapontado quando recebeu o pedido? Esse mesmo sentimento de arrependimento acontece o tempo todo com os aplicativos móveis.

Em vez de gastar semanas ou meses reunindo os requisitos, identifique rapidamente o MVP (Minimum Viable Product, ie, algo que atenda os requisitos mínimos) e disponibilize um app já funcionando – e rápido! Uma vez que o aplicativo é liberado, peça a seus usuários um feedback. Incorpore esse feedback. Lance o aplicativo novamente e novamente. Não só o seu aplicativo não será ruim, mas seus usuários vão sentir que participaram dele.

2. Não modelar o app com base em processos de negócio existentes
E se eu dissesse para você anotar o que faria se precisasse encontrar o número de telefone, endereço e horário de funcionamento de um restaurante específico no centro de uma cidade – mas sem acesso à internet? Então, por que criar aplicativos móveis corporativos modelados sobre processos já existentes?

Seus usuários provavelmente não gostam de processos quando eles têm um teclado completo e uma cadeira confortável para inserir informações. Então os forçar a fazer em um teclado projetado para pixies será ainda mais doloroso.

Aqui está um exemplo: os motoristas de entrega muitas vezes tem dificuldade em encontrar o endereço certo na primeira visita. Com o processo existente, os condutores adicionam uma descrição da localização no sistema. Com os dispositivos móveis, no entanto, o motorista pode tirar uma foto do local e marcá-lo no GPS. O processo mobile é completamente diferente e mais eficiente, e os motoristas podem concluí-lo muito mais rapidamente.

Experimente essa tática para evitar a armadilha comum na construção de aplicativos móveis baseados em processos existentes: divida um quadro em três colunas verticais. As classifique em Processos de Negócios, Mobile-First e Novas Oportunidades. Na primeira coluna, desenhe o processo existente em um diagrama de fluxo. Na segunda coluna, desenhe linhas a partir do diagrama de fluxo para as etapas que poderiam ser reimaginadas com mobile e as inclua na coluna Mobile-First.

Finalmente, na terceira coluna, com base em suas ideias para o fluxo Mobile-First, anote todas as novas oportunidades de aplicativos ou processos de negócio que este novo processo oferece. Usando o exemplo de motorista de entrega já citado, o fato de que o motorista tenha marcado o local como apartamento significa que as entregas podem ser sinalizadas, por exemplo, como “apenas embalagem fina” para permitir que o motorista deslize a entrega sob a porta e evite que entregas futuras faltem ao cliente, mesmo que eles não estejam em casa.

3. Não verificar se o aplicativo realmente está ligado ao seu negócio
Se você realmente quer estragar o seu aplicativo móvel, faça um app que crie ou atualize dados em um único sistema, e force o usuário a editar posteriormente os dados ou adicionar mais informações para que sejam parte de um processo mais amplo.

Você não quer que seu aplicativo móvel seja separado de seus processos de negócios e incapaz de atualizar seus sistemas centrais. Você quer que os dados de aplicativos móveis sejam parte contínua da experiência empresarial – o que eu gosto de chamar de empresa UX (User Experience – ou experiência do usuário, em tradução).

Estou constantemente vendo organizações lançarem novos aplicativos móveis incríveis para a visualização de dados corporativos que são completamente desprovidas de empresa UX. Estes aplicativos permitem que os usuários exibam informações em movimento, mas os obriga a ir para outro sistema para atualizar dados. O que realmente acontece é que o seu processo de negócio é mais difícil agora do que era antes de você dar a seus usuários o novo aplicativo sofisticado.

Uma estratégia para evitar uma empresa UX ruim é a utilização de plataformas de nuvem e provedores, conectando com segurança os sistemas existentes para a nuvem como um hub de integração móvel. Então, construa seus aplicativos com esta nova plataforma como um ponto único de conectividade de aplicativos mobile.

Plataformas de nuvem falam em mobilidade – com APIs RESTful, transferências de dados eficientes e SDKs móveis nativas – para que seja possível criar uma grande empresa UX sem nunca gastar em ciclos de desenvolvimento caros atualizando sistemas legados.

Com frequência, vejo empresas condenarem seus aplicativos mobile. O motivo predominante é que eles se aproximam de aplicativos móveis da mesma forma que sempre trataram projetos: usam especificações de requisitos em excesso, não criam processos para utilização das novas tecnologias, e não prestam atenção à experiência do usuário empresarial (ou enterprise UX experience).

Deixe uma resposta

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *