Um protótipo que facilita a definição do CSS a partir de um arquivo PSD

Brackets- From Design Comp to Code

Ainda é um protótipo, mas em breve será lançado no Brackets.

Nesse vídeo, Rain Wilson e Mary Lynn Rajsku demonstram as funcionalidades desse editor de HTML que importa arquivos PSD e facilita a visualização das medidas e guias visuais de cada uma das camadas do arquivo. Segundo os criadores, o objetivo é facilitar o processo de interpretação de arquivos PSD quando eles são passados do Designer para o Developer – algo que ainda é feito manualmente em muitos times de desenvolvimento por aí.

Leia também:

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

Styleguides são o novo Photoshop

Atomic Design: redesenhando os entregáveis de designers e desenvolvedores

Atomic Design

Então Brad Frost foi lá e fez.

Desde que começou-se a falar em Responsive Design, muita gente tem se perguntado (e me perguntado) como fica a documentação e a entrega das telas de determinado produto. Já falamos sobre isso aqui no blog, e também como Designers e Desenvolvedores têm se aproximado cada vez mais para fazer isso acontecer.

Até alguns anos atrás era muito comum que em um projeto fossem desenvolvidos wireframes, layouts e depois mockups clicáveis de uma determinada interface. Um processo de trabalho em cascata, onde cada entrega é validada com o cliente para que a etapa seguinte se inicie. Essa é uma forma segura de garantir que o visual designer só começará a trabalhar quando o wireframe tiver sido aprovado pelo cliente e pelo restante do time, evitando horas desperdiçadas em refação.

Acontece que no exemplo citado acima, o time acaba desenvolvendo 3 protótipos sequenciais. O wireframe nada mais é do que um protótipo, uma simulação de como a interface deve funcionar. O layout em jpg também é um protótipo, uma segunda simulação da mesma interface. E quando o UX utiliza uma ferramenta de criação de layouts clicáveis ou wireframes clicáveis, ele acaba criando um terceiro protótipo da mesma tela.

Daqui

Então Brad Frost foi lá e fez.

E usando uma metáfora bastante conhecida da gente: átomos, moléculas, organismos, templates e páginas.

Continuar lendo

Como criar uma User Story?

Trello

“Felizmente, user stories são extremamente fáceis de criar depois que você fez o pensamento inicial por trás delas. Dependendo de como você pretende usá-las, tem três métodos diferentes que eu sugiro usar:

  1. Em cartões de papel – útil se você pretende organizar um workshop com outros membros do time ou se pretende agrupar as histórias.
  2. Em uma planilha de excel – útil se você tem um número muito grande de histórias, ou se você quer modificá-las com mais facilidade (por exemplo reorganizá-las por prioridade).
  3. Em uma ferramenta online – como o Trello, que permite criar e organizar suas user stories, para depois distribui-las entre seu time e seus clientes.

Dependendo do nível de detalhes das suas histórias, é interessante chamar um desenvolvedor ou um analista de negócios para te ajudar. Isso porque você pode precisar criar histórias para coisas como requisitos de sistema, que você pode não dominar completamente.”

Link do artigo completo: User Stores – The Beginner’s Guide >

O método de Deprivation Testing usado pelo Github

Tirando doce de criança

Outro dia li um texto na Fast.Co sobre como o Github tem um approach diferente na hora de testar as funcionalidades que seus usuários consideram mais importantes dentro do site.

Alguns produtos fazem isso através de testes com protótipos de papel, colocando “rascunhos” dessas funcionalidades na frente de pessoas que realmente usam o produto e perguntando para elas o que elas acham.

Outros fazem testes A/B, colocando versões diferentes do produto no ar (com e sem a funcionalidade) e depois averiguando os números para entender se aquela feature teve boa aceitação.

E existem muitas outras formas de pesquisa para descobrir isso.

O que o Github faz é o que eles chamam de Deprivation Testing (Teste de Deprivação?).

Chrissie Brodigan, pesquisador de design e experiência do usuário do Github, fala sobre como designers e desenvolvedores podem medir quais funcionalidades são mais vitais ao removê-las do site e verificarem o quão chateados ficam os seus usuários.

Tira o doce da criança e vê o quão alto ela chora.

Abaixo a explicação de Brodigan, traduzida, sobre como funciona esse estudo:

Continuar lendo