Летом 2009 года в своей штаб-квартире в Palo Alto, дизайн команда Facebook рассказывала о своей философии и подходе к дизайну. Они придают особое значение написанию кода, частому и раннему показу дизайна, вовлеченности в проект от начала до конца. Возможность дизайнеров писать код всплывало очень часто.

• Дизайн команда Facebook вовлечена в дизайн продукта, маркетинг, UI шаблоны, брендинг и front-end код. Команда состоит из 15 дизайнеров (product designer), 5 дизайнеров интерфейса и 1 “стратега” по контенту. Всего 25 дизайнеров на компанию из 1000 человек.
• Как команде удается создавать дизайн для четверти миллиарда человек? Четыре мысли: нужно быть вовлеченным от начала до конца, делиться наработками рано и часто, пачкать руки и не влюбляться.

Дизайнеры должны быть вовлечены от начала до конца: от создания общей стратегии до запуска. Этим Facebook отличается от остальных компаний.

• Facebook уделяет много внимания тому, чтобы их дизайнеры были вовлечены в процесс с начала до конца.
• Создание дизайна сразу с кодом позволяет увидеть, как реальная информация ведет себя в новой разметке.
• Дизайнер, пишущий код, быстрее и внимательнее внедряет мелкие детали дизайна.

Показывайте дизайн на ранних этапах и показывайте часто. Раннее обсуждение командой и пользователями помогает добиваться лучших результатов.

• В Facebook нет креативного или арт директора, вместо этого используется процесс “снизу-вверх”. Для команды критично, что бы всем было известно, чем они занимаются.

Не бойтесь пачкать руки. Очень важно, чтобы вы понимали, как работает Веб. Все дизайнеры немного используют HTML/CSS, а иногда даже PHP.

• Это упрощает взаимодействие между дизайнерами и разработчиками. Дизайнеры могут заниматься багами и строить быстрые прототипы сами.
• Очень важно быстро двигаться вперед. У Facebook’а много соперников во многих сферах и то, как люди используют Веб, постоянно меняется. Быстрая итеративность – ключевой, критический момент.
• В Facebook верят, что важно выпускать продукт как можно раньше, чтобы посмотреть, как его используют.
• Мокапы врут. Им не хватает контента и контекста. Нужно использовать реальный контент и реальные страницы, чтобы понять, как работает новый дизайн.
• Что бы продвигаться быстро, нужно прототипировать заранее. Например: интерфейс комментариев был протестирован и переделан несколько раз еще до того, как попал к конечным пользователям.
• Дизайнеры в компании «коммитяться» около 40 раз за неделю.

Не влюбляйтесь. Софт не постоянен, он все время меняется и вам нужно принять это.

• Цель – постоянные изменения принимать за должное.
• Не останавливайтесь на достигнутом сегодня. Уже завтра вы будете отставать. Как дизайнеру, вам нужно делать прогнозы и думать как будут обстоять дела через год.
• Самый долгоживущий дизайн Facebook’a был дизайн главной страницы в 2004 году, он продержался 18 месяцев.
• Как никогда раньше, наша работа бесконечна.
• Делайте А/Б тесты для большинства функциональностей. Используйте четко определенные метрики, но не позволяйте им определять дизайн.

Полный текст статьи Luke Wroblewski о том, как построен дизайн процесс у одного из самый посещаемых ресурсов в мире.

Еще о дизайне в разных компаниях на Usemenot:

• Дизайн процесс в Cooper Design.
• Дизайн процесс в Apple.
  
• Несколько слов о дизайне в Google.

• То что дизайнеры работают в паре дает возможность кому-то одному сосредотачиваться  на стратегии а второму на тактике. Идеи которые сами по себе крутые но могут не подходить к текущим задачам/требованиям могут быть отметены заранее.
• Если кто-то один болеет или отсутствует, работа все равно продолжается.
• Когда дело доходит до написания документации, парный дизайн дает возможность делать это в два раза быстрее.
• Два дизайнера в одной комнате занятые одной проблемой помогает не отвлекаться на переписку, и быть в тонусе.

Производительность

• Два мозга работающих над одной проблемой удваивает количество уникальных идей, перспектив и “впечатлений” (experiences, тежело найти рускоязычную аналогию).
• Необходимость вербально формировать идею для напарника, часто помогает “кристаллизовать” проблему, что очень помогает в поиске решений.
• Cooper  время от времени перемешивает дизайн команды для обмена опытом.

Если кому-тот интересно, то можно найти более детально описание обязанностей дизайнеров Copper у них на сайте, а еще более детально в книгах Алана Купера.

]]> http://usemenot.com.ua/2009/11/24/pairdesign-process-in-cooper/feed/ 2 http://usemenot.com.ua/2009/09/28/importance-of-details-in-interaction-and-visual-design/ http://usemenot.com.ua/2009/09/28/importance-of-details-in-interaction-and-visual-design/#comments Mon, 28 Sep 2009 14:24:19 +0000 Андрей Онофрийчук http://usemenot.com.ua/?p=192

Зачем это.
Как важно уделять много внимания деталям? Иногда мне кажется, что все, что меня окружает это набор типографских ошибок, неправильных отступов, неправильно подобранных цветовых схем, странных, не логичных и сбивающих с толку решений. На мои замечания друзья обычно отвечают: «никто кроме тебя никогда не замечает этого». «Кто ж если не мы», – звучит в голове. Если люди других профессий (врачи, инженеры, финансисты (хотя они уже облажались недавно) и т.д.) не будут обращать внимания на детали, то их «промахи» быстро заметят, так как часто они будут критичны.

Представьте, что врач при обследовании не обращает внимание на возможные проблемы с работой сердца пациента, потому что никто явно не заметит этой «детали». «И так все нормально сейчас работает».

Одной из причиной этого есть то, что часто дизайном (в более «инженерном» смысле , а не в плане дизайна сайта/айдентики) занимаются люди по совместительству. Разработчики программного обеспечения сами рисуют иконки и интерфейсы, руководители проектов пишут тексты,  рабочие решают где и как установить информационную табличку или знак итд.

Действуйте локально, думайте глобально.
Какой бы не была глобальной задумка без высочайшего внимания к деталям даже самые крутые хитрые и продуманные продукты могут легко проиграть более «детальным» конкурентам. Одним из примеров тому есть уже упомянутый мною ранее случай, когда интернет-магазину удавалось иметь выше продажи конкурентов всего лишь из-за  того, что у них был на один ракурс больше в фотографиях товаров. Не то, что б в одном случае не было совсем фотографий, или были в плохом качестве, просто не было в одном важном для покупателя ракурсе.

Пренебрежение деталями приведет к провалу.
Консультант-гуру по безопасности приводит пример, как усилия ограничить доступ в помещение оказываются напрасными из-за мелкой и непродуманной детали. Кодовый замок сам выдает код.

Угадайте, какой код к дверям на фото

Еще несколько примеров вдогонку. Они достаточно известны, только ленивые юзабилисты не писали хоть пару слов об этом. Оба случая касаются Амазона. Это «кнопка на $300 000 000» (ага много нолей всегда круто выглядит) и «вопрос на 2.7 миллиарда».

Не буду детально писать о них, в первом случае заменили кнопку «регистрация» на «продолжить» и количество покупок выросло на 45% и дополнительные покупки принесли больше 15 миллионов за первый месяц. За первый год сайт заработал дополнительные 300 миллионов. Во втором случае добавление функционала «Был ли этот отзыв полезным для вас?» тоже принесло внушительное увеличения прибили.

Последним примером будет внимание к группировке цифр или символов в длинных кодах или номерах. Всегда когда спрашивают чей-то номер телефона,  я удивляюсь, почему  больше десяти цифр в номере не разделено пробелом для удобства чтения (сейчас на моем телефоне уже все как должно быть). Даже некоторые наши мобильные операторы только недавно догадались, что нужно группировать длинные коды в припейд карточках.

Еще недавно пополнять Киевстар было менее удобно. Фото Романа Голубовського

Не спешите.
За время работы я выработал привычку в определенный момент по ходу работы над проектом останавливаться и как будто делать zoom-in, пройтись по задачам в другом, приближенном масштабе, концентрируясь на деталях. Обычно разработка ведется в быстро-срочном темпе и времени для этого нету, но я заметил, что даже минимум уделенного времени достаточно, что бы продукт в итоге оказался более жизнеспособным и готовым соперничать с конкурентами.

Всегда интересно узнавать, как построен рабочий процесс у других, и вдвойне интересно узнать о процессе известных и успешных команд, чтобы потом сравнить со своими принципами работы или попробовать что-то новое. На конференции SXSW в 2008м году Майкл Лопп (senior engineering manager) рассказал, как Apple добивается успеха в дизайне и разработке.

Майкл рассказал о принципе «ряда подарков» (очень хорошие идеи «запакованные» в другие хорошие идеи — другими словами, отличное программное обеспечение в отличном железе и в красивой упаковке). Конечно же, всем интересно, как бл* они это делают (формат конференции «South by Southwest» позволяет вольное выражение =) ). Майкл раскрыл некоторые детали:

Безупречные до пикселя наброски
Это забирает огромное количество сил и времени но убирает все неопределенности и любую двусмысленность которые могут быть в упрощенных мокапах или прототипах. Нужно потратить больше сил, но на последующих этапах это поможет избежать многих ошибок.

С 10 до 3 до 1
Дизайнеры готовят 10 абсолютно разных набросков нового продукта или сервиса. Никаких ограничений в требованиях к дизайну, все, что захочется дизайнерам. Позже число сужается к 3, и после месяцев работы над ними получится один финальный вариант.

Парные дизайн митинги
Эта часть действительно интересная. Каждую неделю команды проводят два митинга. На первом обсуждаются любые идеи, мозговой штурм без каких либо ограничений. Потом проводится второй (production meeting), где идеи с первого митинга пытаются «завалить». На нем дизайнеры вместе с инженерами думают, как бы все сумасшедшие идеи воплотить в жизнь. Такие встречи проходят на протяжении всего процесса разработки продукта.

Пони митинги
Эта история связана с рассказом Майкла о том как топ-менеджмент ставит задачи: «Я хочу WYSIWYG (what I see what I get)…что бы все новые браузеры это поддерживали…что бы отражалась философия компании», Это как детское «Я хочу пони!», а кто ж не хочет пони, они ведь классные. Проблема в том, что люди описывают то, что им только кажется они хотят. Тут помогают результаты парных митингов и процесс выделения 1 из 10 «прототипов» продукта.

Я буду стараться находить истории и других компаний, так скоро будет пост о процессах в Майкрософт и нескольких других известных компаниях.

via businessweek