Redesign do site da Caelum: saindo dos anos 90 direto para os Hipsters Years

Encontrar certos cursos no site da Caelum era uma tarefa bem complicada.
Os cursos de NodeJS (back-end) e UX, estavam no menu de Front-end. O curso de PHP era o único item no menu que o click caia direto na página do curso.

Pensando na encontrabilidade de informações e da vontade de dar uma reformulada no layout, construímos o novo site da Caelum.

Como era antes

A falta de consistência funcional e da usabilidade foram os pontos principais sim, mas convenhamos que o layout estava meio vintage demais:

Site da Caelum aberto em PC antigo

Se você não conhecia, dê uma navegada aqui pelo Web Archive. Dúvido você achar o curso de Lógica de Programação.

Então os problemas principais eram:

  • Falta de consistência funcional
  • Encontrabilidade de cursos complicada
  • Layout datado
  • Pacotes de cursos (que chamamos de Formações) não tinham um “cantinho” só para eles

Como ficou

Você pode navegar no novo site ou ver a diferença da home acima da dobra nesse GIF também:

Como foi o começo do projeto e o primeiro problema

Deixar claro para o time envolvido no projeto o público que queremos atingir é importante, por isso que nas turmas do curso de UX da Caelum sempre falamos de personas e proto-personas. Fiz três proto-personas (1, 2, 3) focando em alunos que normalmente dou aula, como o perfil que quer entrar na área de tecnologia e perfil designer desejando aprender front-end.

Não precisei fazer uma vasta pesquisa nessas proto-personas, justamente por conhecer bem o perfil dos alunos, mas cometi um erro: fiz sozinho. A ideia da persona é alinhar o usuário e o time, mas como o time não participou do processo de criação, rapidamente foi tudo ignorado. Primeira lição aprendida então é: se for fazer persona, faça com o time.

Mesmo as lindas personas sendo deixadas de lado *suspiro*, em toda reunião semanal fomos alinhando os perfis de alunos que focaríamos naturalmente. O fato de boa parte do time tratar com alunos diariamente ajudou bastante nisso:

  • Aluno que tem um objetivo como fazer um site, aprender java, desenvolver um app;
  • Aluno que sabe exatamente qual tecnologia precisa

As categorias na home e na página de cursos matam o primeiro caso. E para o segundo usamos o conceito de ter logo de cara, as informações que o usuário precisa para chegar onde precisa, conceito esse chamado de “3W”, what, why e what’s next? (o quê, por que, e agora?).

 

  • What: uma rápida apresentação para quem não sabe o que a Caelum oferece (Cursos de desenvolvimento, web…)
  • Why: por qual motivo o aluno deveria conhecer a Caelum (Projetos práticos…)
  • What’s next: imagine o aluno pensando “me convenceu, agora o que eu preciso fazer nessa página?” (normalmente um call to action, no nosso caso a busca)

Quais ferramentas foram usadas no processo

Usamos muitas ferramentas no processo todo, umas online, outras de UX, entre elas vale citar:

  • Hotjar: antes de rabiscarmos qualquer coisa, analisamos algumas gravações e mapas de calor no Hotjar, recomendo fortemente a ferramenta para ter insights interessantes e tentar entender como o usuário;
  • Slack: foi nosso principal meio de comunicação, se não o conhece, por favor leia Encontrando melhores formas de trabalhar com o Slack;
  • Trello: conosco desde o princípio também para organizar nossas ideias e algumas referências, foi usado massivamente antes deixar o site no ar para organização e priorização de bugs funcionais e de design;
  • Card sorting (aberto): técnica colaborativa de UX para organizar e categorizar itens, como menu ou mesmo telas, usamos internamente bem no comecinho quando pensávamos em categorizar os cursos por profissões, e não por objetivos. Usamos também o app Post-it Plus (só iOS :/)Card sorting por profissões
  • Figma: similar o Sketch, só que online. Usamos no começo para montar wireframes e discutir a estrutura do conteúdo, além de servir como ferramenta principal para começar a fazer os protótipos juntamente com o…
  • Marvel – ferramenta online e free para você linkar as telas feitas no seu editor de imagem preferido e fazer seu protótipo.
  • Sketch + Zeplin: o primeiro para o designer do time fazer as telas, e o segundo foi essencial para agilizarmos o desenvolvimento front-end do site. Basicamente coloca o arquivo do design no Zeplin, e ele facilita para pegar coisas como paddings e hexadecimais;
  • Editores de texto/IDEs: não temos um padrão, cada um usa o seu. No começo eu estava usando o Brackets, mas depois precisei da performance do Sublime;
  • Sistemas operacionais: maioria aqui usa Mac e eu sofro bullying por insistir em usar Windows ¯\_(ツ)_/¯

Antes de codar, desenhar

Aí você está doido pra codar, e já começar a montar toda  a build do projeto, Sass, Gulp, etc. Começa a fazer tudo na loucura e sangue nos olhos, para chegar lá na frente e o layout não tem nada a ver com o que você tinha pensado. Para evitar isso, por favor, rabisque antes de codar.

Rabiscamos algumas coisas no papel, mas logo jogamos tudo no Figma. Você pode ver algumas telas aqui ou nesse print:

Wireframes Caelum Mobile

Essa é a maior prova que pensamos primeiro em mobile (mobile first) para montar o site, nos preocupando desde o início que a experiência do aluno no celular seja tão confortável quanto no desktop.

E por qual motivo fazer de baixa fidelidade? Como a estrutura nem tinha sido fechada, não tínhamos nenhum styleguide e também queríamos pegar problemas de usabilidade logo no começo, optamos primeiramente por focar mais na estrutura do conteúdo (arquitetura de informação). O layout seria desenvolvido um pouco mais adiante, com as principais questões de estrutura já discutidas e testadas.

Clicou aqui e aparece qual tela mesmo?

Você pode montar suas telas e colocar o usuário para ir passando no app de fotos do seu celular por exemplo, mas como que ele usa um site normalmente? Clicando e navegando. Logo seria bacana que as telas tivessem um comportamento bem parecido com um site já no ar, por isso é interessante prototipar, para conseguir testar coisas como o fluxo de navegação e depois alguns erros de usabilidade. Que seja protótipos de baixa, média ou alta fidelidade. Para isso usamos o Marvelapp, o mesmo que os alunos utilizam no curso presencial de UX.

Então ficou assim: telas estáticas feitas no Figma e link entre essas telas, agora exportadas, no Marvel.

Fizemos diversos protótipos, e conforme o layout foi sendo desenvolvido, fomos aplicando as cores e tipografia neles. Dá uma olhada no primeiro protótipo:

Nem sabíamos o que colocar no menu nessa hora, mas já foi bacana para testar a encontrabilidade de certas informações, antes semi-escondidas, agora mais visíveis e de fácil visualização. Chegamos até a testar o famoso burguer icon (veja o protótipo com ele aqui), mas acabamos eliminando a ideia para enxugar o máximo possível o menu principal.

No final dessa primeira fase dos testes de usabilidade, o protótipo já tinha uma cara bem mais parecida com um site real e bem mais fiel ao layout final. Digo “primeira fase” pois o ideal é sempre testar seu projeto, não importa em que ponto está.

 

No futuro próximo farei um post exclusivo sobre o tema de teste de usabilidade e contando como foi a experiência. Enquanto isso você pode ouvir o Hipsters.tech sobre prototipação e o sobre Design Sprint.

Decisões e problemas da vida

Mudamos de weekly para reuniões 2x por semana (segundas e quintas), mais rápido para ter feedback do andamento das coisas e deixar tudo alinhado.

No lado do back-end, foi discutido três opções:

  • Manter a estrutura toda atual em Java
  • Fazer tudo do zero em Java
  • Fazer tudo do zero em PHP

Em altos papos “desenvolvedorísticos” o time optou por manter o back-end em Java do site antigo, visando ganhar tempo pois muitas decisões de negócio e de performance já tinham sido pensadas e desenvolvidas. Eu no entanto por não ter conhecimento técnico em back-end, não consegui opinar.

Layout definido, pelo menos as páginas principais, começamos a desenvolver o front-end, enquanto uns foram arrumando a infra, outros codando HTML e CSS. E quase que paralelamente esses HTMLs desenvolvidos foram passados para JSP (Java things…). Uma opção que tínhamos de infra era continuar usando pré-processador (LESS como no atual ou colocar o Sass, por exemplo), mas optamos por fazer tudo com CSS normal (componetizado, mas normal), e caso sentíssemos necessidade no correr da carruagem voltaríamos a discutir. E até que surgiu essa necessidade, mas estávamos ligeiramente atrasados, então iremos rever essa decisão mais pra frente, levando em conta o uso do PostCSS também.

E foi mais ou menos nessa época de começar o front-end, que começaram as “tretas da vida”. Dar aula em outros estados, férias já programadas, feriados e doenças (duas viroses em questão de duas semanas) foi a Lei de Murphy aplicada num projeto.

Interessante dizer que não demos a devida importância para diversas páginas, como a página de Cursos In-Company e fomos alertados por pessoas diferentes de dentro da empresa, como instrutores de outras unidades da Caelum ou mesmo do departamento comercial. Falha nossa por ter envolvido o comercial somente no final dessa primeira fase.

Site subiu

Its happening gif

Era pra ser lindo, mas logo notamos problemas de performance, o site estava extremamente lento. Tinha alguma agulha que não estávamos vendo. No caso, uma agulha de pé meio inclinada para o lado. Por conta de regras de redirect + código Java antigo + código Java novo, em todo request de uma URL que não existia, acabava consumindo CPU loucamente o que deixava todo o site lento, tudo por conta de uma barra. Mas agora todas as URLs estão sem a ordinária barra no final “/” e o time até voltou a falar comigo.

Trabalho finalizado

Será? Não é porque o site subiu que o trabalho acabou. Depois de uns dias com o site no ar ainda aparecem páginas não previstas que nem são indexadas pelo Google, como páginas de algumas parcerias que a Caelum possui. Há um bom número de bugs de design para serem corrigidos também (um card de bug por dia, deixa o site bonito e com alegria). Ainda há muita coisa para testar, faremos mais testes de usabilidade a fim de colocar a prova teorias e ideias que tivemos, e outras que vamos ter também.

Agradecimentos a toda a staff que trabalhou diretamente com o projeto:

E toda a diretoria e pessoal que ajudou indiretamente também.

 

 

 

16 Comentários

  1. Cristofer Sousa 03/05/2017 at 15:59 #

    Seria muito bacana se colocar o repositório da parte de Front-end aberto para comunidade principamente para ver como ficou separado em módulos o CSS, até o ponto que usaram postcss sério mesmo que estão usando JSP? Se sim, muito louco! Parabéns pelo projeto reformulado, ficou legal!

  2. Danilo Siqueira 03/05/2017 at 20:57 #

    Muito legal. Obrigado por compartilhar essa experiência. Parabéns!!!

  3. Natan Souza 04/05/2017 at 09:51 #

    Vamos ver isso sim. Os modulos voce consegue ir vendo no inspect element por enquanto, temos coisas como `titulo.css` e `secaoTrabalheaqui` por exemplo. Queremos no futuro usar o PostCSS, repare que la no site cada categoria possui uma cor, –var nos ajudaria nisso. Sim, JSP, nao sei o que é mas estamos usando! Valeu pelo comentario!

  4. Daniel Destro 04/05/2017 at 13:04 #

    Excelente, parabens e obrigado por compartilhar.

  5. FABIANO RODRIGO 04/05/2017 at 13:09 #

    Natan,
    Tem como explicar o que foi esse problema de desempenho por conta de uma mera barra?
    Que medo! rs

  6. Mateus Queiroz Correia 04/05/2017 at 14:27 #

    Parabéns por compartilhar o conhecimento de forma tão didática e divertida – ficou bem legal explicar toda a história e desafios!
    Sugestão é fazer um podcast sobre o assunto hein? Ficaria bem legal!!!

  7. Alberto Souza 04/05/2017 at 14:50 #

    O problema de desempenho não foi conta da barra, hehee. Tinha uma rota no muito genérica no projeto, quase que asterisco mesmo… o fato de tirar as barras do fim começou a dar conflito com essa rota genérica e acabava gerando redirects infinitos.. esses redirects consumia demais a máquina impactando no tempo de resposta das outras requisições.

  8. Lucas Araújo Cassiano Dias 07/05/2017 at 02:18 #

    Porque tiraram a jaga do Schedule dos cursos?

    Cadê os designers de UX para explicar que muita gente acessa o site várias vezes só para se planejar quando poderá fazer os cursos?

  9. Natan Souza 09/05/2017 at 00:43 #

    Por dados do GA essa pagina nao era acessada e a colocamos na death list. Mas o comercial da Caelum sentiu falta, entao a colocamos no rodapé junto com outras paginas secundarias. Analisamos tambem jornadas de usuários para matar essa e outras paginas. Obrigado pelo comentário!

  10. Edward Klein 15/05/2017 at 08:51 #

    Faltou vcs colocarem os links das apostilas de Ruby e Algoritmos ;P
    ou elas serão descontinuadas? =O

  11. Natan Souza 15/05/2017 at 12:02 #

    Oi Edward, tiramos pois eram apostilas de cursos nao mais comercializados pela Caelum há um bom tempo, logo o conteudo ficou totalmente desatualizado. Entendemos que é melhor não deixar um conteúdo defasado online, portanto tiramos do ar. Obrigado pelo comentário!

  12. Edward Klein 15/05/2017 at 12:09 #

    Achei que tava faltando atualizar o site, mas então vcs realmente pararam com os cursos presenciais de RoR?

  13. paulo josé 16/05/2017 at 09:03 #

    Ola devia ter preços dos cursos .

  14. Leandro Takeda 16/05/2017 at 13:21 #

    Gostei muito do site mas achei que tem muito espaco em branco dos lados na pagina inicial, nao? Nao eh uma critica, somente minha opiniao. Eh indiscutivel o conhecimento de vcs, parabens!

  15. Paulo Silveira 17/05/2017 at 19:34 #

    essa é uma discussão que temos aqui todo semestre! difícil decisão.

  16. Paulo Silveira 17/05/2017 at 19:48 #

    sim edward. a demanda acabou sendo bem menor do que a que tínhamos e ficou difícil de acompanhar, uma pena 🙁

Deixe uma resposta