1. Objetivo: Um produto de trabalho que as pessoas usam

Um objetivo tão simples. Analisaremos cada palavra, porque não é tão formulada por essas palavras.

Preste atenção à falta de palavras do processo, como "criação", "design" e assim por diante. Processos não são um objetivo. O objetivo pode ser apenas um resultado, não um processo. Mas os designers de todo o mundo caem na armadilha mental dos processos; portanto, os resultados de seu trabalho são artefatos de processo, não produtos de trabalho.

Eu tenho estatísticas tristes. Dos dez designers que vêm “fabricar um produto e influenciá-lo”, um se concentra no resultado, o restante se concentra nos processos. Chega muito tempo e, se é que chega.

Antes da indignação, vou esclarecer: não diminuo a importância dos processos e os entendo. Estrutura, pesquisa, design, metodologias, especificações, diretrizes, sistemas de design, software profissional e assim por diante. Assim que o produto cai nas mãos do usuário, tudo isso não faz sentido: o produto funciona ou não.

Enfim, voltando ao texto.

1. Um produto de trabalho é aquele que pode ser usado para resolver problemas. É sobre a capacidade técnica de resolver o problema usando o produto.
2. O produto é um tipo de entidade completa, inteira, na quantidade de ingredientes que tem mais valor do que todos eles tomados separadamente.
3. Use - fala de demanda e conveniência.
4. As pessoas são um conceito mais amplo que "clientes", "usuários", "funcionários" etc. Ao trabalhar para pessoas, levamos em consideração a ergonomia e alguns padrões.

Digamos que o produto não funcione. Tudo está claro aqui: eles não serão usados ​​(pelo menos para o propósito a que se destinam).

Ou não é um produto: um conjunto de componentes díspares que não são interconectados por nenhum sinal (isso também acontece).

Ou existe um produto, mas eles não o usam (de maneira alguma). Também um fracasso, poderia ser qualquer um: a falta de marketing, desconfortável, diminui.

Se não as pessoas o usam ... então, admito, haverá princípios de design completamente diferentes.

Essa idéia é discutida de diferentes ângulos quando eles falam sobre Agile, entregas frequentes, Scrum e trabalho em equipe, mas mesmo com essas práticas, os designers às vezes entram em uma rotina acolhedora de "processos" por algum motivo. Eu admito essas razões:

• Eles não entendem as tecnologias e sua influência sobre elas,
• não pode influenciar o resultado (medo "eles não ouvem", falta de motivação, subordinação inventada "eles não me disseram para fazer isso")
• não entendo seu papel
• um scrum é explorado sem entender o objetivo, como uma estrutura (veja também Cult of Cargo ) - então definitivamente não é melhor que a cascata (ou pior ainda)
• organize pequenas cachoeiras dentro do scrum :-) - “Primeiro, projete e depois front-end”, em vez de trabalhar pelo menos dois / dois. Por algum motivo, isso é especialmente difícil para designers e desenvolvedores (mas quando e se o fizer, eles não querem mais voltar ao mini-modelo de água, porque ele é defeituoso em todos os sentidos).

PS Links para descrições das metodologias listadas, Wikipedia:

• Agile (Agile) - metodologia de desenvolvimento flexível
• Scrum (Scrum) - uma estrutura para desenvolvimento ágil de software (trabalho em equipe)
• Kanban

2. O papel do designer na equipe scrum

Muitas vezes, o papel de um designer em uma equipe de produtos é exagerado, porque eles pensam em termos de processos e sequência de ações (cascata) em vez do resultado.

(Pensar corretamente no resultado, por categorias de objetivo.)

O desenvolvedor, depois de fazer tudo de acordo com os padrões e especificações, provavelmente resolverá o problema melhor do que se ele passar pelas maquetes do designer. Provavelmente até as métricas de mercado serão melhores. Na completa ausência de um designer.

"Estamos aguardando layouts" - se isso soa, então os processos na equipe não estão organizados corretamente.

(Infelizmente, muitos desenvolvedores e designers não conhecem os padrões - pelo menos o W3C para a Web, e existem muitos princípios fundamentais que ajudam a criar a melhor experiência. Por analogia, existem descrições / padrões para as principais plataformas móveis e de desktop; iOS , Material .)

Preste atenção às startups - Facebook, Vkontakte, Odnoklassniki e a mesma Apple da Microsoft: elas são baseadas em soluções de engenharia (Wozniak, Gates), às quais os designers aderiram posteriormente. Eles criaram produtos de acordo com o objetivo.

Primeiro, é um produto de trabalho.

(Bonito, por uma questão de justiça, o pessoal ideológico do laboratório Xerox o fez, mas a escala das consequências é completamente diferente.)

•••

Qual é então o papel do designer?

Agregar valor .

Você pode adicionar a algo existente , preste atenção.

Valor aos olhos dos clientes, usuários.

•••

Muitas vezes, a sequência é virada de cabeça para baixo e "aguardando o design". Isso, é claro, fala da imaturidade da equipe e do gerenciamento inadequado dessa mesma equipe.

•••

"Layouts" é um anacronismo, o legado de uma teia estática que costumava seguir a estética e os processos de preparação de gráficos de revistas e jornais. No design do produto, isso deixou de ser relevante, mas a abordagem - na ausência de outra - permaneceu, tanto nos processos quanto na consciência.

Comece com código em vez de layouts.

Aplicação - dinâmica, movimento, interação. Portanto, os layouts no trabalho do designer de produto geralmente são inadequados e contrários ao objetivo.

É por isso que designers avançados migram para protótipos com dados reais. Isso é bom? Eu acho que isso é redundante - por que programar um protótipo quando você pode (e logicamente) programar imediatamente um produto?

É melhor passar do desenvolvimento para o design imediatamente. Comece com o código - o protótipo que executa a tarefa do cliente de maneira mínima. Um protótipo que pode ser usado para fornecer suprimentos (lembre-se mais tarde sobre Desenvolvimento do Cliente)

(A abertura e a maturidade dos desenvolvedores são importantes aqui - a vontade de experimentar e melhorar o programa, possivelmente até reescrever o código várias vezes novamente. Tenho certeza de que há muitas soluções prontas para isso por um longo tempo.)

Para viagem

Realize a tarefa do usuário.

Comece desenvolvendo. Trabalhe em conjunto com o desenvolvedor (como diretor de arte e redator).

Melhore um produto funcional em vez de layouts.

Pense em termos de objetivos, resultados em vez de processos.

O designer do produto cria o produto, não os layouts.

3. Método

Esse método, junto com a biblioteca de componentes, tornou-se a base do sistema de design bancário .

Proponho trabalhar na seguinte sequência:

1. Reconheça a tarefa do cliente (usuário) e confirme-a como uma História do Usuário.
2. Defina métricas. Como entendemos que a tarefa do usuário foi resolvida? Confirmar.
3. Formule hipóteses. Confirmar.
4. Mapa da jornada do cliente.
5. Um protótipo de trabalho. MVP Desenvolvimento de Clientes.
6. Layouts. (Com o trabalho em equipe e o sistema de design existente, você pode fazer sem layouts).

Tarefa do cliente

Tudo parece claro aqui, mas muitas vezes não é. As hipóteses de interface são confundidas com as tarefas do cliente, são fornecidas pela lista de desejos do gerente e geralmente são usadas para manipulações de equipes não tão bonitas.

A tarefa do cliente é identificada com base em reclamações ("dor do cliente") ou em necessidades de pesquisa.

(De passagem, observamos que uma reclamação e uma tarefa são duas coisas diferentes, e é importante manter a cabeça fria e não se apressar em "resolver um problema" com base em uma reclamação - a tarefa pode ser diferente e a reclamação é causada por circunstâncias não relacionadas. Vem com a experiência. Use o método "cinco por que" - às vezes, ajuda a chegar ao fundo da base na qual uma tarefa objetiva pode ser formulada.)

Quando uma tarefa é realizada, ela é registrada como uma História do usuário. Muitos artigos e livros foram escritos sobre isso, então não vou me repetir aqui - estude por conta própria.

Para ter uma ideia do problema, recomendo vivamente o livro Mapeamento de histórias do usuário: descubra toda a história, construa o produto certo (Jeff Patton e Peter Economy) .

Dois tipos de métricas (é importante corrigir os dois!)

1. A resposta formulada à pergunta "Como entendemos que a tarefa do usuário foi resolvida". O que queremos obter na forma de uma solução.
2. Digital: valores relativos e absolutos. Mais frequentemente sobre indicadores quantitativos (financeiro, velocidade, clientes, tempo). Como entendemos que a decisão foi bem-sucedida. Existe um truque: geralmente nas apresentações, os valores relativos são ocultos, exagerados ou perdem a escala objetiva da decisão. Por exemplo, "o crescimento do público foi de 3%" - é muito ou pouco? Se são 150.000 pessoas (um assentamento de tipo urbano, com escolas e jardins de infância, lojas e sua própria administração), então este já é um número impressionante, embora pareça pequenas coisas. Por outro lado, o "crescimento de 300% do lucro", se for de 300 rublos por mês, já é um indicador duvidoso. E, novamente, se 150.000 pessoas representam um erro estatístico no tamanho da audiência de todo o produto (por exemplo, visitando a página principal do mecanismo de pesquisa por ano), é provável que esses tamanhos sejam negligenciados, embora falemos da população da mesma vila de tipo urbano.

Muitas vezes acontece que as métricas surgem depois que um produto ou recurso já foi feito. Para relatórios e uma bela apresentação. Isso é triste e não mostra habilidade, mas, pelo contrário, estraga a imagem e cria uma falsa sensação de calma (o acerto de contas sempre ocorre). A situação é ilustrada muito bem pela piada sobre o melhor arqueiro do mundo.

Hipótese - a resposta à pergunta sobre a maneira mais rápida de resolver o problema do usuário

Sempre existem várias soluções para o problema. No desenvolvimento (design) não pode ser limitado a um! Ninguém sabe com antecedência qual deles funcionará melhor.

Faça um trabalho mental e encontre pelo menos três soluções diferentes.

Lembre-se de que “desenvolver” uma idéia na forma de um layout que muda progressivamente é uma solução, não três (ou quantos layouts diferentes você conseguiu criar).

Para simplificar, tente três abordagens:

1. Solução de interface. Também pode haver vários.
2. Automático (por exemplo, uma tarefa é executada no servidor após a ocorrência de um evento) - sem intervenção do usuário.
3. Processos - o que pode ser alterado nos processos para que o usuário não encontre uma tarefa, mas receba uma solução no momento certo.

A melhor solução é encontrada exclusivamente de maneira empírica (consulte “Método científico”). Qualquer uma das soluções / idéias mais loucas à primeira vista deve ser verificada. As hipóteses precisam ser verificadas. O caso ideal é testar todas as três hipóteses realizadas na forma de MVP. Você fará um protótipo para isso.

Mapa da jornada do cliente mergulha no contexto

Se você tiver um produto pequeno com uma única função, o CJM permitirá que você veja todo o processo de resolução de um problema pelo usuário e identifique pontos problemáticos, realize a conclusão real da tarefa.

Se a tarefa é desenvolver um recurso em um aplicativo existente, o CJM mergulha no contexto e fornece uma solução perfeita para o problema. Freqüentemente, ignorando o contexto, designers e gerentes de produto fazem uma "nova seção", propagando entidades, complicando a navegação e criando confusão na interface.

Muito já foi escrito sobre o CJM, você precisa estudá-lo e aplicá-lo em seu trabalho.

Você pode começar com o livro " Custom Stories ", de Jeff Patton.

Um protótipo de trabalho. MVP Desenvolvimento de Clientes.

Organize com o desenvolvedor e faça um protótipo funcional para testar cada hipótese. Essa não será necessariamente a solução ideal técnica e esteticamente - é importante criar um produto minimamente viável ( MVP ), no qual os testes podem envolver clientes novos e existentes (Customer Development).

« . Lean Startup -» . .

MVP, . .

,

Durante o desenvolvimento do MVP e o teste dos protótipos, você certamente refinará muitas pequenas coisas em cada entrega e após cada sessão de feedback do usuário. O máximo que precisará ser feito é alinhar as telas da solução pronta com estilo e testar novamente. Uma nova visão do produto pode sugerir novas soluções, simplificar ainda mais e repensar, tornar o resultado ainda mais conveniente e mais bonito para o usuário - é aqui que o valor agregado aparece.

Para viagem

Para informação

A maior coisa que você pode fazer

, / , . , .

.

, - , . , , . -. : , - , . , , , .

: , , . . , , .

, . ( ), , , , . , ( , «»; — ).

: , . , . — -: , — . -, . , , , , . ( «»), /. / , : / , , .

, .

, .

?

, / (), , , , . . , , .

, .

: ?

? ?

?

30 ? ?

? , ?

?

, ?

— , . .

, . — , : , . .

.

« », .

, . , . . , - . .

: .

? . ? .

. , — «» :-)

.

. : , , .

, , . ( ).

: , . : / .

:

1. , : , -, (// ). . ( ).
2. , , — . , : , «, » ( ), , «», . — .
3. , . , — . — /, . — , , , , . - . , — . « ».

Total

1. — .
2. — .
3. «» .
4. , « » «» ( / ) — .

— , , . .

ePub