Yahoo! Blog User Interface (YUIBlog)

Q: Qual é a melhor forma de comunicar um padrão?

Luke Wroblewski
Designer Principal, Yahoo Inc.
Fundador / Diretor, LukeW projetos de interface
Autor, Site Vê: uma aproximação visual à Usabilidade na Web

Jenifer faz alguns bons pontos sobre os principais ingredientes de um padrão de design. Eu segundo a importância dos exemplos e "problema" pensativo e "utilização quando" descrições. Para além destes elementos que definem o direito de metadados para um padrão de design é frequentemente indicado pela sua audiência.

Quando eu estava trabalhando na primeira iteração da biblioteca interna do eBay design padrão, o grupo de usuários design de experiência tinha sido baseada em diretrizes e normas. Perfeitamente compreensível, dada a quantidade de pessoas que estavam trabalhando em um único produto: o mercado do eBay. Porque tantas pessoas diferentes contribuíram para a concepção e desenvolvimento de um "site" único, as regras deviam ser postas em prática para assegurar uma certa consistência.

Ao longo do tempo estas regras evoluiu em alto nível arquitectónico orientações e descrições detalhadas de apresentação e interação. Nós chamamos esses tipos de regras de quadros e componentes. Quadros salientou a interação e estrutura visual dos fluxos de tarefas e tipos de tela. Por exemplo, o processo de registo é um fluxo e uma página da Ajuda é um tipo de tela. Quadros ajudou a estabelecer onde e quando o conteúdo e as ações devem ser apresentados aos usuários. Componentes descritos nossa base de usuário blocos de construção da interface (menus, formulários, barras de ferramentas, etc.) Eles foram projetados para otimizar a usabilidade e consistência em todas as unidade do eBay.

Então tivemos que institui quadros onde e quando os elementos da interface do usuário deve ser usado e tivemos componentes detalhando o que esses elementos se parecia e como se comportavam. Mas ainda estávamos lutando para entregar projetos de interface consistente.

Para usar a terminologia da multidão IDEO, profissionais criativos são naturalmente curiosos e muitas vezes se aplica "a mente de uma criança" - aberto a novas idéias e observações - a sua única forma de resolver o problema. Tivemos muita designers criativos no eBay e eles se aproximaram seu trabalho exatamente desta forma. Eles se esforçaram para novas ideias e soluções e eram inatamente curioso sobre a lógica por trás dos quadros e componentes que estávamos usando a unidade de coerência. Como resultado, muitas soluções foram propostas novas, e muitas vezes adotado. Como você pode imaginar isto criou uma dinâmica interessante entre as "regras" e design - uma abordagem iterativa e naturalmente abdutivo para resolver problemas.

Para abraçar o processo de design dentro do nosso redesenhado "regras", decidimos transformar os nossos quadros e componentes em um conjunto de padrões de projeto. Como as regras, os padrões poderiam ser testados, verificados e analisados. Ao contrário das regras, no entanto, foram as soluções de concepção repetitivo para problemas comuns. Essa foi uma distinção muito importante como a ênfase deslocou-se de "aqui é assim que tem que ser feito" para "aqui está uma maneira de tornar seu trabalho mais fácil."

A fim de fazer essa transição, nós modificamos nossa documentação de frameworks e componentes. Para nossas explicações iniciais de onde e que, acrescentamos:

• Por: quais as oportunidades e limitações ajudou a definir esse padrão? Houve alguma pesquisa feita para suportar isso?
• Como é: em um esforço para tornar a adoção padrão tão fácil quanto possível, incluímos links diretos para as especificações e código visual, sempre que possível. Fornecemos também uma indicação do estado para assegurar o uso apropriado: em desenvolvimento, necessário, recomendar, etc
• Quem: ligações directas foram fornecidas para as pessoas que tinham documentado, identificado ou projetou o modelo.

Dada a nossa audiência (uma equipe central do projeto trabalhando em uma infinidade de produtos, em última análise integrada e recursos), esta abordagem de uma flexibilidade muito mais em como nós compartilhada e documentada concepção de melhores práticas. Dito isto, há claramente algumas diferenças na abordagem da Jenifer defendido anteriormente. Integração dos exemplos de código e especificações visual foi importante para facilitar as coisas para os nossos designers e incluímos alguns campos que podem ser irrelevantes para um público de uso geral. As respostas básicas nossa documentação padrão fornecer ainda eram os mesmos:. "Qual é, usar quando, porquê, como e exemplos"

- Lucas