Curadoria de Funcionalidades
A filosofia de trabalho Getting Real prega que para ter um software fácil de usar e barato se de produzir e manter é preciso reduzir a quantidade de funcionalidades. Geralmente os programas têm mais funcionalidades do que o necessário e há um certo desperdício aí.
Resolver 80% do problema com 20% do esforço.
A melhor maneira de se enfrentar a complexidade é com menos código. Menos software significa menos funcionalidades, menos código, menos desperdício. A chave está em repensar qualquer problema difícil que venha a necessitar de uma grande quantidade de componentes para ser solucionado em um problema mais fácil, que requeira muito menos. Você pode acabar não solucionando exatamente o mesmo problema, mas tudo bem. Resolver 80% do problema original despendendo 20% do esforço é uma vitória e tanto. O problema original raramente é tão crítico de forma a realmente merecer cinco vezes mais esforço em sua solução.
A quantidade de funcionalidades importa?
Essa maneira de pensar pode levar uma equipe de desenvolvedores a pensar: então, quantas funcionalidades meu software deve ter? Três, cinco, doze? Hoje o pessoal da 37 Signals respondeu a esta interessante pergunta: É mesmo a quantidade de funcionalidades de um programa que importa?
Curadoria de Funcionalidades: escolhendo só o melhor.
Ao responder, Raymond Brigleb compara a escolha de funcionalidades ao trabalho de curadoria. Um museu, por exemplo, tem um espaço limitado para expor obras de arte. Por isso é preciso escolher muito cuidadosamente qual obra merece estar naquela valiosíssima parede.
No entanto quanto falamos de software, e principalmente de internet, não há limites. A parede é infinita. Portanto, é possível colocar em um programa tantas funcionalidades e telas quantas o programador quiser.
O espaço é infinito, a capacidade cognitiva do usuário não.
Mas é preciso entender que, se por um lado o espaço da tela é infinito dentro de um browser - ainda mais usando expedientes como lightboxes e outros recursos RIA - a capacidade do usuário de aprender a mexer no seu programa não é. Também não é infinito o tempo que o usuário tem para encontrar a funcionalidade que ele realmente precisa.
Muitas funcionalidades estragam a interface.
Basta perceber como um CD player comum geralmente tem muito mais funcionalidades que um iPod Shuffle. O iPod não tem botões para ativar graves, equalização, vários para sintonização e memorização de estações AM e FM, relógio, repetir, etc…
E por isso mesmo, porque não tem tantas funcionalidades pouco úteis para um tocador de música digital, o iPod é muito melhor que qualquer CD player: é absolutamente simples.
Equilíbrio entre interface, funcionalidade e produtividade.
Um bom software é o resultado de um cuidadoso equilíbrio entre uma interface limpa, simples e fácil de usar, funcionalidades que resolvem o problema do usuário e boa produtividade na hora de escrever o código e mantê-lo (para melhorar a relação custo-benefício).
Se duas funcionalidades são suficientes para resolver satisfatoriamente o problema, de maneira equilibrada, ótimo. Se é preciso 10, ótimo. O que realmente importa é a qualidade do programa, e que a quantidade de funcionalidades não estrague a experiência do usuário.
Portanto, ao pensar sobre uma nova funcionalidade para seu programa, pense como um curador, pense que cada pixel da sua interface é tão valioso quanto é cada centímetro do museu mais importante do mundo: será que esta funcionalidade merece este exposta aqui?

Todo designer já passou - ou sempre passa - por isso: você faz um trabalho que considera excelente, o cliente pede que “alguns detalhes” sejam alterados (há quem diga que é só para ter o gostinho de por o próprio dedo na criação) e no final o designer não tem coragem de colocar o trabalho no próprio portfólio.
Este aí ao lado é o meu novo celular.
Todo designer gráfico sabe que boas referências e trabalhos artísticos inspiradores são essenciais, como comida, para sua sobrevivência.
