Você sabe qual o tipo de roubo mais comum no mundo?
Não, não é o roubo de celulares ou carteiras… Mas o roubo de dados! O que acarreta em enorme perda para as empresas. Um estudo global lançado recentemente pela IBM, que analisa o prejuízo anual por companhia, aponta perdas de U$ 3,8 milhões. No Brasil, a realidade não é muito diferente, tendo em vista que o custo médio para violações cibernéticas é de R$ 5,88 milhões. Ainda mais alarmante é saber que, no cenário brasileiro, 85% dos brasileiros já foram vítimas de fraudes online ou conhecem alguém que tenha passado por pelo menos um tipo de fraude cibernética. Eu já caí neste tipo de golpe, pessoas da minha família já passaram por isso, e com certeza você conhece alguém que foi vítima de algum esquema de cyber crime.
A internet faz parte das nossas vidas em praticamente todos os aspectos, e é quase impossível não ficar diante de situações que poderiam ser ameaçadoras para nós, usuários (quer estejamos, ou não, conscientes dessa ameaça). Não seria um erro afirmar que poucas pessoas entendem os riscos envolvidos nas etapas de segurança; e o pior, nem sempre importam-se verdadeiramente com estes riscos. As pessoas estão mais preocupadas na velocidade e qualidade do acesso de determinado site, ou em conseguir pagar um boleto pelo aplicativo do banco sem complicações, por exemplo. Assim, constatamos que o interesse do usuário é prático: ele quer realizar sua tarefa com sucesso, atingindo seu objetivo prontamente.
E o que isso tem a ver com design?
No começo de 2019, ingressei na Tempest, e também no mundo da cybersecurity. Assim, comecei a desenvolver produtos pensando em segurança; o que, pra mim, ainda é um nicho da tecnologia diferente do que eu estava acostumada a trabalhar, em termos de desenvolvimento de projetos e produtos. E foi assim que, certo dia, escutei de um colega de trabalho que a usabilidade e a experiência do usuário andam na contra-mão da segurança.
Como usuária da grande rede — e também como pesquisadora — procurei entender o comportamento das pessoas diante das etapas de segurança no mundo digital e das (muitas) verificações chatas, como por exemplo: a experiência de fazer login. Já parou pra pensar quantas vezes você faz login por dia? O quão chato isso é? A consequência disso, naturalmente, aumenta os comportamentos inseguros, quando por exemplo, grande parte de usuários opta por utilizar a mesma senha em aplicações diferentes. O que fica ainda mais grave quando a pessoa opta por anotar a senha em um post-it deixando-o à mão, em sua área de trabalho, seja ela física, ou em seu desktop.
Entretanto, não adianta querer culpar o usuário, nós que desenvolvemos produtos digitais temos a obrigação de tornar os sistemas mais seguros.
Por mais que muitas vezes possa de fato parecer que usabilidade e experiência do usuário sejam opostas à segurança, as três podem e devem andar de mãos dadas; sobretudo em um mundo cada vez mais conectado e cheio de armadilhas virtuais, como o nosso. Nós também temos um papel muito importante como guia e educadores, quando as pessoas começam a utilizar um produto digital ou serviço construído por nós.
Como podemos projetar a experiência do usuário pensando em segurança?
Bom, um projeto não é responsabilidade exclusiva do designer, existem outras pessoas-chave envolvidas do início ao fim do mesmo: product owners, desenvolvedores, scrum master, analistas de segurança, entre tantos outros. Quando criamos a consciência de que precisamos desenvolver um produto seguro, temos que pensar em segurança desde o planejamento das features pelo designer até a sua codificação. O foco em segurança não é pontual, ele deve estar presente no projeto desde o dia 0. Ao construirmos um produto seguro para o usuário, também estamos atribuindo segurança e menos prejuízo para o negócio em questão.
Existem muitas ferramentas que podem nos auxiliar a pensar em toda a jornada de uso do produto. Porém, primeiramente, precisamos entender questões básicas: O que estamos tentando resolver? Pra quem? Qual o contexto que essa pessoa está inserida? Para a partir daí, inferir os seus modelos mentais e desenhar uma experiência mais segura.
Vamos por partes…
Para que nossas questões sejam ilustradas com experiências reais de trabalho, escolhi usar como exemplo para este artigo, um projeto que chegou nas mãos do nosso time de engenharia para refatoração de código e re-design. Logo que passaram esse projeto pra nós, foi perceptível que conseguiríamos melhorar a experiência de uso e refinar a sua proposta de valor. O produto em questão já existia na Tempest como uma solução focada em auxiliar a gestão de e-mails corporativos que possam estar associados a vazamento de dados sensíveis. Vou trazer alguns exemplos relacionados ao EIM — E-mail Incident Manager no decorrer do texto, que terá como roteiro, a partir de agora, o modelo visual do Double Diamond (neste caso adaptado à inclusão do desenvolvimento seguro):
1. O que estamos tentando resolver/descobrir?
Se você trabalha com produto, com certeza já se deparou com uma das seguintes situações: a) o cliente já chegou com uma ideia formulada; b) foi identificada uma necessidade de mercado; c) essa ideia surgiu do feedback de um cliente, etc. Estas são apenas algumas entre as muitas situações de gatilho para o início de um produto. Assim que somos apresentados ao projeto, começamos uma grande pesquisa para saber se essa ideia faz sentido; ela já existe no mercado?
Existindo, quem são os players? Como podemos tentar nos diferenciar? E essas são apenas algumas das indagações que passam a nos orientar. A partir deste momento, estamos abrindo as possibilidades para que a ideia vá se tornando algo tangível. Quando sabemos em qual contexto e nicho de mercado o produto atuará, podemos começar a buscar entender o comportamento das pessoas e a mapear os modelos de ameaças mais comuns. Já a partir daqui é importante ter um analista de segurança no time, para que ele possa desde o princípio priorizar a segurança no projeto.
Abaixo estão algumas ferramentas que podem ser utilizadas para esta parte de discovery:
- Brainstorming (Toró de ideias)
- Imersão
- MVP (Produto mínimo viável)
- Matriz CSD (Certezas, suposições e dúvidas)
- Canvas proposta de valor
2. Conheça o seu usuário
Já sabendo o que estamos tentando resolver, precisamos agora conhecer melhor quem vai usar o nosso produto! Esse é o passo mais importante para que se chegue em uma solução de segurança adequada ao cenário. Quando conhecemos bem nosso público, conseguimos insights importantíssimos sobre os possíveis contextos de ameaça aos quais o usuário e o sistema poderão estar expostos. Assim, poderemos projetar melhor as etapas de segurança, bem como pensar nos tradeoffs entre as dores e os riscos na jornada de uso.
Para mensurar critérios de frustração e delight na experiência de uso, devemos considerar toda a jornada do usuário incluindo o login. Conhecer o seu usuário é ir além do que foi dito numa entrevista, ou do que foi extraído de uma base de dados. É tentar enxergar também toda a rotina de uso dos envolvidos, assim como os fatores humanos presentes. Pessoas de profissões diferentes terão rotinas, focos e backgrounds diferente. Temos que entender que o produto que estamos propondo é mais uma ação a ser executada no dia a dia, aumentando o fardo de trabalho para nosso usuário. E ainda assim, somos responsáveis por estimular os usuários a terem um comportamento mais seguro e, assim, guiá-los nessa jornada. Por isso, volto a dizer que tornar uma aplicação segura é tarefa de quem desenvolve, e não uma obrigação da pessoa que está usando o produto.
Caso seu produto já esteja no mercado, e você queira melhorar a experiência do usuário em relação às suas etapas de segurança, pode-se extrair algumas métricas de UX, até mesmo através do Google Analytics, como por exemplo: Quantas mensagens de segurança estão sendo visualizadas? Qual o erro, relacionado à segurança, mais recorrente em sua aplicação? Qual a página mais visitada de seu site? Não mensurar esse tipo de dado, é perder informações ricas em detalhes e insights que elementos como estes podem nos trazer.
A seguir estão algumas ferramentas que podem ser utilizadas para descobrir mais sobre as pessoas de interesse:
- Entrevistas
- User Journey
- Google Analytics (Não subestimem a riqueza dessas métricas)
- Surveys
- User shadowing (Sombra)
3. Desenvolvendo a partir de Modelos Mentais
Os modelos mentais também falam muito sobre quem são as pessoas que estamos tentando conquistar. Por isso, esse tópico merece um destaque neste artigo.
Quando desenhamos experiências, precisamos nos basear na vivência do outro e com isso aprendemos com ele. Somente o usuário pode dizer se uma experiência projetada é eficaz para ele ou não.
Os modelos mentais tem interferência direta na eficácia da experiência de uso, pois eles ilustram a maneira como enxergamos o mundo, bem como os modos como representamos internamente a realidade ao nosso redor. Devemos levar em conta, portanto, a cultura, background, a geração (faixa etária) a qual o indivíduo pertence, o ambiente social em que essa pessoa cresceu, entre outras coisas que influenciam a tomada de decisão. Sendo assim, podemos perceber que os usuários utilizam seus modelos mentais para prever o que está por vir.
Quer um exemplo prático? Quando vemos um cadeado antes da URL do site que acessamos (imagem abaixo), para algumas pessoas esse cadeado é referente a proteção, reafirmando para o usuário que ele está seguro no site, quando na verdade, ele só representa que aquela página tem um certificado SSL válido, e infelizmente, até uma página maliciosa pode obter um destes certificados.
“Modelos mentais são baseados em crenças, não em fatos: isto é, é um modelo do que os usuários sabem (ou pensam que sabem) sobre um sistema ou site” — Grupo Nielsen Norman
Por isso mesmo, eles nos dão inputs importantíssimos sobre como podemos projetar para um determinado tipo de público: que affordances (referências visuais) e tipo de linguagem utilizar. Estes fatores são os reais motivadores por trás do comportamento do usuário, e para projetar produtos mais seguros, precisamos influenciar e ensinar as pessoas a ter um comportamento seguro por padrão.
Trazendo para o exemplo da Tempest, o EIM tem como público gestores de uma infinidade de áreas diferentes de TI ou segurança: finanças, contabilidade, recursos humanos, auditorias, etc. Por ser um público que se distancia da área de TI, toda a linguagem do produto foi pensada com o intuito de afastar os assustadores jargões técnicos de segurança; com o objetivo de traduzir melhor a importância da tomada de ação por parte desses usuários, tornando evidente a consequência de cada ação. A seguir, duas imagens que refletem essa preocupação e utilizam de uma linguagem mais corriqueira para falar com esse público:
Abaixo estão algumas ferramentas que podem ser utilizadas para compreender modelos mentais:
- Mapas mentais
- Mapas cognitivos
- Mapas conceituais
- Card Sorting
- Personas e Arquétipos
4. SUX (Security User Experience)
Security User Experience, que o Jared Spool chama carinhosamente de SUCKS, é a primeira experiência. Antes de se preocupar se o produto será mobile first ou o content first, temos que nos preocupar, na verdade, é com a segurança. É com ela que o usuário esbarrará primeiro. Pois quando ele encontrar sua primeira barreira, terá que escolher se adotará um comportamento seguro ou não dentro da aplicação. Assim, é essencial que as seguintes etapas sejam bem planejadas:
- Identificação, autenticação e/ou autorização
Você talvez ainda não tenha parado pra se perguntar a diferença entre identificar o usuário, autenticar e autorizar, também conhecido como Controle de Acesso (que inclui o processo de auditoria, o que não vem ao caso no momento).
Identificação é quando o usuário diz ao sistema quem ele é (normalmente com o nome de usuário ou e-mail em alguns casos). Por exemplo, quando você acessa o site da Amazon (caso tenha cadastro) e já está automaticamente “logado”, quer dizer que o mesmo já lhe identificou. Porém, se você tentar realizar uma compra ou adicionar um endereço, você será redirecionado para as etapas de autenticação e autorização. Para garantir que seja mesmo o usuário identificado pelo sistema. Autenticação é quando perguntamos para a pessoa: Você realmente é quem está me dizendo? Prove! E aí entra o segundo fator de autenticação (2FA), biometria etc. Autorização é quando definimos quais são as permissões que uma pessoa tem dentro do sistema.
Posso até citar um exemplo disto via outro produto da Tempest chamado AllowMe. Ele auxilia a identificar atividades suspeitas, através da análise do comportamento de navegação, identificação de novos dispositivos e geolocalização. Caso ocorra algum tipo de comportamento suspeito, uma etapa extra de autenticação é solicitada.
A separação destes 3 momentos: Identificação, Autenticação e Autorização dá-nos mais flexibilidade na perspectiva do design para projetar momentos mais agradáveis na jornada do usuário. A pergunta para esse momento é “Estamos identificando, autenticando e/ou autorizando as pessoas certas, na hora certa e no lugar certo?”
Contextos de ameaças e perímetros de segurança
A partir do momento que sabemos quem são os usuários do produto já temos muitas informações sobre os possíveis riscos aos quais essas pessoas estão expostas, por exemplo: se o produto for para um banco, sabemos que os usuários podem estar expostos a tipos de fraudes bancárias específicas, já que este é um contexto de ameaça completamente diferente de um usuário que tiver sua conta no Twitter hackeada, obviamente. O foco dessa etapa é o diálogo constante com o analista de segurança ou engenheiro responsável, pois ele saberá mais que o designer, onde estão as vulnerabilidades mais comuns e/ou mais críticas. É aqui onde devem ser discutidas as possibilidades de interações e distribuição dos perímetros de segurança.
Não é necessário autenticar o usuário para toda e qualquer ação que ele for realizar, deixando para solicitar uma camada extra de segurança apenas nos momentos cruciais e relevantes da jornada, de modo a podermos dar um certo nível de liberdade e navegação em outros momentos menos críticos em termos de acesso a dados e informação críticos. A imagem a seguir ilustra alguns exemplos de camadas de proteção mais comuns:
- Produtos diferentes precisam de níveis de segurança diferentes. Aqui temos que estar atentos para lembrar desses perímetros na jornada de uso: login, autenticação (sendo ou não necessário um 2FA) e autorização de segurança requerem um esforço grande do usuário e é preciso considerá-los na jornada de uso. Em uma user story muitas vezes dizemos “o usuário faz login na plataforma y” como se essa ação fosse uma coisa trivial, mas não é. Fazer login muitas vezes pode ser uma experiência extremamente frustrante, podendo inclusive ser o fator decisivo para que uma pessoa não use mais o seu produto.
- Redução da carga cognitiva do usuário. A carga cognitiva acontece quando uma pessoa precisa aprender algo novo para executar uma determinada tarefa, como por exemplo: ficar diante de muitas escolhas em determinado site/app; ou ter dúvidas sobre o que está escrito (falta de clareza). Tudo isso prejudica o entendimento e a tomada de decisão do usuário.
As duas imagens acima ilustram essa dificuldade de clareza. Na primeira imagem temos os tamanhos misturados, entre os numéricos e as letras representativas. Na segunda, que mais parece um painel de elevador, temos uma disposição completamente fora do padrão esperado de ordenação, o que causa não apenas um estranhamento, mas também uma confusão visual que, de fato, dificulta a leitura da informação. Para evitar percalços no caminho do usuário de qualquer sistema, precisamos fazer com que essa jornada seja a mais fluida e natural possível, adotando sempre soluções que causem menos frustração em comparação à sua avaliação de risco. Devemos pensar fluxos que minimizem esse esforço cognitivo, por exemplo: o que podemos fazer quando o usuário esquece o nome de usuário/login, a senha, ou até mesmo quando ele tenta tanto acessar e acaba bloqueando a conta, quanto mais simples para a escolha de uma solução ao usuário melhor:
As soluções também devem seguir o que chamamos de Safe by default. Não queremos que o usuário comum fique desprotegido no nosso sistema, muito menos que ele perca tempo em configurações de segurança às quais não compreenda. Por isso, menos é mais. E vale lembrar que:
“People ignore designs that ignore people” — Frank Chimero
Concluindo
O desenvolvimento de produtos e serviços digitais apartou durante muito tempo analistas de segurança, designers e desenvolvedores. Essa realidade não deveria mais fazer parte de nossas rotinas de trabalho, dado o contexto de conexão de mundo no qual estamos inseridos.
Estabelecer diálogos e trocas entre esses profissionais é essencial para que ótimas soluções aconteçam. A responsabilidade por um mundo digital mais seguro é nossa.
“User experience design isn’t a checkbox, you don’t do it and then move on. It needs to be integrated into everything you do.” — Liz Danzico
Devemos, portanto, ensinar e conduzir nossos clientes, reduzir jargões técnicos para quem não é técnico, usar e abusar de affordances e heurísticas que pertencem aos modelos mentais aprendidos nas pesquisas e, sempre que possível, embutir segurança em diferentes camadas do sistema para que a experiência palpável do produto seja mais fluída e, consequentemente, a segurança dependa menos do usuário final.
Quando uma solução tem uma boa usabilidade, o usuário toma suas decisões com mais confiança. Neste caso, o saber o que eu estou fazendo tem um papel fundamental para estimular um comportamento de uso mais seguro e consciente.
“If it’s not usable, it’s not secure!” – Jared Spool (Founder of User Interface Engineering)
