Laudos e exames médicos online em plataforma multidevice
Contexto
A área da medicina, que lida com questões e momentos delicados de nossas vidas, apesar de seu perfil quase que inerentemente analógico, tem se adaptado assim como todos os outros mercados, à prestação de serviços e adaptações de jornadas através do meio digital. Diante da aceleração da digitalização causada pela pandemia, surgem plataformas que tentam facilitar tanto o dia a dia dos médicos, a partir de gestão digital e integrada e consultas, agenda e paciente, quanto dos pacientes, através da telemedicina e do acesso facilitado à partir de sites de laboratórios que são disponibilizados através de sites e aplicativos.
Apesar da aceleração neste sentido, a disponibilização prática e unificada de laudos e exames, de forma que os médicos tivessem facilidade em adicionar documentos e os pacientes também de acessá-los ainda não havia encontrado alternativas eficientes e intuitivas. Da percepção desta dor surge a MediCloud.
A plataforma, tem como grande objetivo permitir que médicos registrem pacientes, criem "consultas" conectadas à estes pacientes, e, adicione tanto laudos médicos diretamente a partir da plataforma, quanto exames de imagens, de vídeo, de texto, permitindo ainda fazer edições como definir recortes de vídeo e adicionar carimbos ou marcas d'água com as credenciais do médico. A responsividade também era um critério importante do projeto, compreendendo que médicos poderiam fazer a adição de arquivos majoritariamente pelo computador, enquanto pacientes poderiam muitas vezes acessar estes arquivos pelo celular, mas que não eram isolados os casos que fugiam desta tendência.
Exploração
Prático, intuitivo, eficiência e limpo. Estas foram as diretrizes tratadas como base pelo cliente para a construção deste projeto.
Ao iniciar o design deste projeto, busquei no mercado algumas referências para entender principalmente como poderia se dar a estrutura do produto, considerando a navegação entre páginas. Para visualizar melhor como se daria esse fluxo, construí um sitemap do sistema, tentando conectar todas as necessidades do briefing de forma coesa e alinhada ao que costuma ser praticado no mercado. Para este projeto, era importante também que fossem trabalhadas 3 visões diferentes da plataforma: a do médico, do paciente e do operador.
O médico precisa ter acesso completo à todas as funções do sistema, o paciente, uma visão mais simples e direta para acesso rápido à suas consultas e exames. Já o perfil do operador, seria um perfil como um assistente ou auxiliar do médico, que poderia realizar algumas ações na plataforma mas não teria acesso aos exames e laudos, também como não poderia adicioná-los. As 3 diferentes visões foram construídas em sitemaps.
Com uma visualização mais clara dos requisitos do briefing e da possível estrutura do produto, comecei a tomar decisões básicas de design. Utilizei uma paleta de cores alinhada ao nicho de saúde, que costuma usar o verde ou o azul. Aqui optei pelo azul como cor principal. Para um sistema limpo, foi decidido o uso pontual da cor primeira, priorizando o uso do whitespace e da hierarquia da informação para manter as interfaces organizadas e os highlights chamativos para as principais ações de cada fluxo.
Conjunto de variáveis de cores primitivas
Defini uma paleta de cores primitivas para trabalhar uma base de cores relativamente ampla e coerente. Gosto de atuar com design tokens para cores mesmo para projeto mais curtos ou em estágios iniciais por entender que o ganho em consistência vale muito a pena, e que essas decisões de design precisam ser tomadas, sejam documentadas ou não. Portanto, tendo a preferir trabalhar com camadas de tokens primitivas e semânticas, mesmo que as nomenclaturas não sejam estabelecidas da forma ideal. Acredito que garante coerência, facilidade para alterar e manter o sistema, além de facilitar a evolução dos padrões do sistema para um biblioteca consistente ou um design system, artefatos muito úteis e até necessários para produtos maduros.
Após a definição da paleta de primitivas, comecei a tomar algumas decisões sobre tokens da camadas semântica. A imensa maioria dessas decisões foram tomadas enquanto interfaces eram construídas, não em um momento inicial anterior à exploração (como pode ocorrer com as primitivas), mas a documentação final dos tokens semânticos está representada abaixo.
Conjunto de variáveis de cores semânticas
Durante a construção das telas iniciais, além de definir as decisões de cores que seriam usadas como regra no sistema, também foram tomadas decisões relacionadas à tipografia. Para uma primeira versão de uma plataforma SaaS que tem como premissa ser simples e limpa, optei por utilizar uma escala tipográfica com pouco contraste e super enxuta, visando organizar as informações em blocos pequenos e restritos de informação, considerando a evolução da plataforma para um cenário de maior complexidade e volume de informações.
Durante a construção das telas iniciais, além de decidir as cores que seriam usadas como regra no sistema, também foram tomadas decisões sobre a tipográfia. Para uma primeira versão de uma plataforma SaaS que tem como premissa ser simples e limpa, optei por utilizar uma escala tipográfica com pouco contraste e super enxuta, visando organizar as informações em blocos pequenos e restritos de informação, considerando a evolução da plataforma para um cenário de maior complexidade e volume de informações. A partir de testes, segui com a Work Sans como família tipográfica, por acreditar que se encaixe nas exigências de marca e contexto da plataforma.
Definição de tipografia e escala tipográfica
