GH
Desenvolvendo um serviço de FAQ - Parte 2 (Escopo e Prototipação)
0
0

Desenvolvendo um serviço de FAQ - Parte 2 (Escopo e Prototipação)

Já entendemos a nossa razão de existir, volume esperado de clientes e nosso budget(Se não viu, confere na parte 1). Agora precisamos entender o que será de fato o produto e como ele irá funcionar.

Gabriel Henrique
3 min
0
0

Já entendemos a nossa razão de existir, volume esperado de clientes e nosso budget(Se não viu, confere na parte 1). Agora precisamos entender o que será de fato o produto e como ele irá funcionar.

É sempre bom conhecermos nossas inspirações, e para isso, é muito válido pesquisar o que os serviços que pretendem resolver esta dor estão fazendo. Uma sugestão é acessar sites como o Dribble (https://dribbble.com/search) e pesquisar soluções similares. Nessa busca rápida, eis alguns exemplos encontrados:

https://dribbble.com/shots/7886407-CircleTrack-FAQ
https://dribbble.com/shots/7886407-CircleTrack-FAQ
https://dribbble.com/shots/4171866-HelpCenter
https://dribbble.com/shots/4171866-HelpCenter
https://dribbble.com/shots/5437025-Apprian-FAQ
https://dribbble.com/shots/5437025-Apprian-FAQ

Dada as inspirações, vamos iniciar o nosso protótipo. Uma ferramenta muito boa para isso é o Figma. Para nos apoiar, um design system open source(gratuito), é uma mão na roda. Alguns design systems conhecidos são o Material Design. Este site fornece uma lista de design systems com componentes já montados para o figma: https://www.designsystemsforfigma.com/. Tome cuidado para validar se é um estilo gratuito e se planeje com algo que já possui o estilo para desenvolvimento (por exemplo, para o material design: https://mui.com/pt/)

No desenvolvimento do código deste projeto, irei utilizar React e escolhi pelo Ant Design (Ant Design for Figma e Ant Design for React).

Com o Ant Design for figma, criei uma nova página, um wireframe do tamanho de um desktop, e coloquei os componentes para darmos o norte da nossa primeira tela:

Email image

Com isso feito de uma forma um pouco mais visual, podemos entender com mais detalhes o produto. Vamos falar agora de requisitos para que o sistema funcione bem!

Requisitos

Conseguimos visualizar os seguintes itens:

  1. Buscar por tópicos
  2. Listar categorias
  3. Listar artigos relacionados a uma categoria
  4. Criar categorias
  5. Criar artigos
  6. Vincular um artigo a uma categoria

O próximo passo é pensar na escala do sistema. Lembre-se que estamos fazendo um MVP - tem que ser algo simples (mas muito usual, e que resolva um problema do cliente de forma muito bem feita).

Atenção! Não é porque é um MVP, que deve ser feito com baixa qualidade. Pense no volume de clientes que você irá atender. Faça um sistema que irá suportar no mínimo 2 anos sem gargalos. A tabela de viabilidade da parte 1 ajuda bastante a entender qual o volume de acessos que vamos ter e qual o nível de produto precisamos ter. O sistema irá evoluir muito rapidamente, portanto, precisamos criar algo fácil de dar manutenção. Minhas premissas para esse sistema será:

  1. Planejamento de performance para 1 mil clientes, cada um com 10 mil acessos por dia (10 milhões de acessos por dia)
  2. Pesquisa para encontrar os tópicos de ajuda precisa ter uma resposta imediata (na casa de milissegundos)
  3. Estrutura para cada cliente ter em média 50 categorias e 10 tópicos por categoria (500 tópicos por cliente, 500 mil tópicos no total)
  4. Registro de pesquisas, armazenando quais tópicos são os mais comumente solicitados
  5. Algoritmo para exibir as categorias mais populares primeiro, por padrão
  6. Personalização da logo, e cores, conforme a identidade visual do cliente
  7. Enquanto o cliente final digita sua dúvida na busca, exibir sugestões para o que está buscando

Agora, falando de engenharia, temos os seguintes requisitos:

  1. Criação de duas aplicações, o backend (que irá criar os tópicos, categorias e afins a partir de APIs) e o frontend (que irá exibir a informação dentro de nosso layout)
  2. Frontend em React
  3. Backend em typescript (node.js)
  4. Uso de TDD (Código precisa possuir testes de aceitação)
  5. Precisamos de um banco de dados com busca textual - fulltextsearch

Bora para o próximo capítulo? Criando a nossa API!