Desenhando a experiência do Desenvolvedor

Developer Experience

Jeremiah Lee criou este logo para seu workshop no SXSW. Desenvolvedor, UX e designer, né?

Muito do sucesso do iPhone, Twitter e Facebook está no fato de serem mais do que produtos: são plataformas que permitem outras pessoas criarem negócios baseados em seus serviços (pense na indústria de apps e games entorno do iPhone). Outras empresas começaram a perceber as vantagens nesta abordagem, como a Nike está fazendo com o Fuelband. Assim, não é de se espantar que o seu cliente/empresa decida também seguir este caminho de abrir as portas do produto (seu código) para que outros criem novos produtos a partir dele (se já não o fez).

Contudo, ao abrir suas funcionalidades para que outros utilizem, você está criando também um novo público para o seu produto: os desenvolvedores, afinal eles serão os responsáveis em utilizar o seu código para criar algo novo em cima.  E a necessidade deste público é totalmente diferente da necessidade do usuário final: eles vão querer conhecer as regras do negócio, entender as funcionalidades disponíveis e precisarão de um meio de comunicação dedicado à ele. A decisão por usar um serviço ou o outro pode depender disso.

Da criação desta interface com o desenvolvedor vem a necessidade de pensarmos na experiência do desenvolvedor, termo que conheci assistindo uma palestra do Jeremiah Lee, um desenvolvedor que descobriu a imporância do UX também nesse contexto. A partir desta palestra (e também deste artigo),  fiz essa pequena lista com o papel do UX para a criação desta interface com desenvolvedores:

#1 APIs

A maneira mais comum de disponibilizar seus serviços para desenvolvedores terceiros é por meio de uma API (sigla em inglês para Interface de Programação de Aplicativos). Assim como você se preocupa com a navegação, fluxo e coerência da interface visual do usuário final, as APIs precisam ser pensadas com o mesmo carinho. Isso vai desde escolher a terminologia e o padrão mais adequado (“Nome completo” ou “nome” e “sobrenome”?) até pensar todos os cenários de erros que podem acontecer e a mensagem para cada um. Interessado no assunto? Recomendo a leitura do livro Web API Design (gratuito e em inglês) e também do blog API UX (em inglês).

Continuar lendo

Anúncios

A aproximação entre Designers e Desenvolvedores (e alguns links úteis caso você esteja interessado)

Designers versus Developers

Quantas vezes você já ouviu alguém falando que o site, app ou campanha “não foi para o ar do jeito que projetamos”?

É, várias.

Já trabalhei em estúdios de design muito pequenos onde precisava fazer de tudo um pouco. Quando você passa a trabalhar em lugares maiores, com mais departamentos e maior quantidade de bons profissionais no projeto, é natural que você pense “esse projeto vai ficar completíssimo e vai ser o melhor projeto que já fiz”. Mas no final, você se vê repetindo exatamente a mesma frase de antes.“Ficou legal, mas não foi para o ar do jeito que projetamos”.

Será então que eu preciso voltar lá para o começo da minha carreira e fazer de tudo um pouco?

Não acho que seja o caso. Por mais que você aprenda a programar, você nunca será o melhor programador. E essa limitação pode acabar influenciando aquilo que você faz como Designer.

Mas e se ao invés de só entregar uma pasta cheia de Wireframes e PSDs, você entregasse outras coisas? Um guia de espaçamentos, um outro de estilos de elementos, uma página HTML com elementos básicos, imagens recortadas, variações de tamanhos de um mesmo elemento para outras resoluções…

“Ah… mas aí você está aumentando a lista de coisas que eu preciso entregar, e o prazo é curto, e assim o programador não vai fazer mais nada.”

Não, não é bem assim.

Esse tipo de entregável traz muito mais benefícios junto com ele: muitos PSDs não precisarão ser feitos, a responsividade do design fica mais natural e quando você está próximo do desenvolvedor e ele tem dúvida sobre algum elemento fica muito mais fácil de resolver.

Hoje trabalho ao lado de um desenvolvedor e posso dizer que a parceria tem sido frutífera para os dois lados. A ideia é que Designer e Desenvolvedor se aproximem cada vez mais, e esqueçam qualquer tipo de “rivalidade” que possa existir entre um e outro. Não faz mais sentido. Essa é uma das formas que encontramos de ser mais ágeis por aqui e conseguir montar protótipos o quanto antes, ainda nos estágios iniciais do projeto. O resultado é visível. Nas reuniões com o cliente, é muito mais fácil chegar com protótipos funcionais, com o mínimo necessário para que ele entenda como aquilo vai funcionar.

Se você é designer ou desenvolvedor e também está interessado em se aproximar mais do seu colega do outro time, reuni aqui alguns links sobre ferramentas que podem ser úteis no dia-a-dia:

https://www.makesets.com/visual-design-to-development

Se tiver algum link para compartilhar, é só mandar aqui nos comments que eu incluo na lista :)

UX e Desenvolvedor trabalhando juntos, ao mesmo tempo

Esse veio de um infográfico da TargetProcess sobre como funciona o escritório da empresa e sobre como os ciclos de iteração entre UX e Desenvolvedor acontecem simultaneamente e tentam ser o mais breve possível.

UX Design e Desenvolvimento

Algo me diz que não é toda empresa que topa trabalhar assim e não é todo tecnólogo que aceita esse processo tão cheio de “incertezas”.

Alguns desenvolvedores têm receio de começar a programar sem antes receber um deck de wireframes de 50 páginas (no mínimo) aprovado e assinado pelo time e pelo cliente.

Mas quando você encontra espaço para esse tipo de metodologia, os resultados mostram que o tal “método de cascata” se torna cada vez menos produtivo para alguns tipos de projeto.