У нас в Контуре многие знают, кто такой Максим Ильяхов и любят инфостиль. Я тоже. Чтобы понять, чем хорош инфостиль, надо погрузиться, проникнуться, почитать много всего на эту тему. После этого вы не сможете его не любить.

Все то, чему учит Максим, основано на простой логике и здравом смысле. Даже без особых знаний до некоторых вещей можно дойти самому. Например, простота.

Люди легче воспринимают простую незамысловатую речь. Навороченные обороты никто не любит. «Кто ясно мыслит — ясно излагает». И это ценно. Канцеляризмы, язык нормативных документов сложны. Вот, например, цитата из статьи:

В соответствии с положениями статьи 346.23 НК РФ налоговая декларация по налогу, уплачиваемому в связи с применением УСН, представляется организациями и индивидуальными предпринимателями один раз в календарный год (налоговый период) по его окончании.

Как можно было бы сказать проще:

Статья 346.23 НК РФ говорит, что организации и индивидуальные предприниматели на УСН сдают налоговую декларацию после окончания каждого года.

Может быть и мой вариант не идеален, но читать уже проще. К сожалению, некоторые по-прежнему считают, что бухгалтеры привыкли к сложным оборотам и любят читать конструкции из первого примера. Я не преувеличиваю, так и говорят, что они любят такой язык. Да ладно! Как можно это любить? Это можно разве что навязать. Наверняка у бухгалтеров не было выбора, никто их не спросил, что они любят. Они вынуждены жить среди этого.

На тексты законов мы не можем влиять, но зачем тащить этот язык в интерфейсы? Говорите проще. Если у бухгалтеров непростая сфера, где черт ногу сломит, это не значит, что не надо упрощать им жизнь. Наоборот, если постараться написать понятно, они это оценят. Среди кучи сложностей ваша простота будет им бальзамом на душу.

То же самое касается интерфейсов. Часто говорят, что бухгалтеры привыкли к сложной 1С, жизнь у них такая, им не страшны непонятные интерфейсы. Мне кажется, что так можно говорить только от лени. Если ты дизайнер, ты должен уметь сделать сложное простым. Когда оно супер-сложное — у тебя просто задача чуть посложней, но она никуда не делась. В общем-то это твоя работа, не надо от нее увиливать.

Все это можно распространить и на другие непростые сферы со своими языковыми или интерфейсными особенностями.

Хорошая статья про Data-Driven Design чуть было не проскочила мимо меня.

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

А вот дальше уже интереснее. Цитирую:

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

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

Это то, с чем я начинаю сталкиваться прямо сейчас. Внутри Контура мы много общаемся с дизайнерами. К тому же сейчас я состою в комитете по стандартизации дизайна Контура, то есть общения действительно много. Мы, прямо как описано в статье, пытаемся затестить все на свете. Три года назад я даже рисовала на эту тему.

Из этого вытекает и другая проблема. Очень часто ребята печалятся, что какие-то их идеи не могут противостоять критике с цифрами, обратной связью, информацией, которая касается их решений. С одной стороны хочется придумывать нечто крутое, не скучное, а с другой — тестирования, опыт пользователей, цифры, вот это все. Дизайнерам становится неинтересно заниматься рутинным и привычным.

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

Сложно определить, где должна проходить грань между слишком непонятным, новым и тем, что привычно и уже скучно. Мне кажется, что сейчас мы с ребятами много спорим как раз по этой причине. Я изо всех сил не хочу сломать мозг у пользователей. В сервисе по ведению бухгалтерии и так все слишком непросто, а ребята часто хотят что-то невообразимое. Иногда они слишком отрываются от земли, а я все пытаюсь вернуть их обратно :) Я, как и ребята, люблю много придумывать, поэтому мне понятны их рвения. Но я не могу закрыть глаза на то, что уже знаю о пользователях, об их опыте взаимодействия с какими-то штуками. Эта информация есть, я не могу ее игнорировать.

Наверное, истина где-то посередине. На первом этапе придумывания решения стоит отпустить свой мозг на волю, разрешить себе безумные варианты. На следующем этапе надо обратиться к логике, понять, в чем именно в этих решениях будут проблемы. Не выкидывать эти придумки за непригодностью, а модифицировать их так, чтобы грань была соблюдена. Методика мозговых штурмов на этом и строится: сначала генеришь все, что угодно, и только потом оцениваешь. Примерно об этом идет речь в конце той самой статьи. Ты не закрываешь глаза на все эти данные, ты их учитываешь в какой-то мере. Настолько, насколько тебе кажется, что решение все же будет работать и при этом не будет обыденным.

Наверное, мы с ребятами хорошо дополняем друг друга, хоть и много спорим. У нас большие шансы придумать что-то крутое без риска совсем погубить сервисы Конутра :)

Так ли необходимо заполнять все то, что вы предлагаете пользователю?

На первый взгляд кажется, что мы спрашиваем только важное, мы же серьезные ребята, знаем толк в своем деле. В сервисе по ведению бухгалтерии, к примеру, на странице реквизитов у вас спросят название организации, ИНН, КПП, систему налогообложения, ОГРН, ОКПО, ОКВЭД, ОКТМО, ОКОПФ, ОКФС и кучу всего еще, боюсь вас утомить. Сложно поспорить с тем, что все это важно. Но тут тонкий момент: важно не только «что», но и «когда». «Когда» спасет вас, друзья :)

«Когда» открывает еще одно измерение — время, и все становится простым. Для этого, правда, надо знать сценарии пользователей. Но разве не этим вы занимаетесь все время, когда проектируете? Наверное, вы уже догадались, к чему я веду.

Пример из бухгалтерии. Если тут не будут ясны детали, кто не в теме, суть вроде бы все равно ясна. Создаем документ, платежку, например. Нужен в нем контрагент? Смотря для чего. Если просто сохранили, и по документу сформировались проводки, то контрагент пока не нужен, в бухгалтерии все хорошо и без него. Это пожалуйста. А вот будем отправлять документ в интернет-банк одним нажатием кнопочки — тогда уж надо запросить, без него документ не примут. Спрашиваем своевременно.

То же самое с ОКВЭД и всеми этими непонятными буквами. На ведение бухгалтерии большинство из них никак не влияет, пока не начнешь сдавать отчетность. Вот тогда и надо их непременно затребовать. А до этого — по желанию пользователя. Когда спрашиваешь к месту, то у пользователей меньше внутреннее сопротивление, больше мотивация заполнить все эти миллион полей. Потому что абсолютно ясно, для чего это тебе прямо сейчас.

Всему свое время.

В прошлом посте я писала, что пользователю надо говорить правду. Да, в сервисе все должно быть прозрачно. Но всегда ли много информации это хорошо?

Бывают случаи, когда в сервисе настолько сложное поведение, что вываливать всю эту подноготную на пользователя просто негуманно. В большом количестве технической информации пользователь может не разобраться, поэтому объясняйте все простым языком, упрощайте. Лишней информации не нужно, если она не помогает принять решение, если она не нужна для дальнейших действий.

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

Не надо думать, что вы рассказали все от и до, были честны, пусть теперь сам решает. Вывалить всю информацию — это не забота. Если пользователь не сможет ничего решить, запутается, не поймет, до него не дойдет очередность шагов — вашей информации грош цена. Если ситуация сложная, и заранее неизвестно, как стоит поступать пользователю, придумайте план, решите за него. Посоветуйте сделать сначала что-то одно конкретное, а если оно не поможет, то пусть воспользуется вторым вашим советом. Проведите его за ручку по безопасному и понятному пути. Пусть это грозит тем, что пользователь сделает лишнее действие, зато он не будет в растерянности принимать решение, как ему быть. Лучше лишнее, но понятное действие, чем куча информации, с которой не ясно, как поступать, за что браться.

Я не думаю, что пользователи идиоты. Я считаю, что нет нужды, чтобы пользователь напрягал свой мозг на 146% на каждом экране и разгадывал загадки. Он не за этим пришел. Вы наивны, если думаете, что пользователь будет сосредоточенно постигать смысл сложного. Скорей, он не поймет и не сделает то, что ему нужно, не найдет, не увидит, не воспользуется. Сложными текстами, сценариями, взаимодействием вы создаете ему проблемы, а не решаете их.

Кстати говоря, те же принципы закладывают в навигацию. По тем же причинам разделы бьют на подразделы и так далее. Меньше информации — проще выбор. Легче погрузиться на три уровня, когда делаешь простой выбор три раза, чем когда делаешь один сложный из большого числа элементов. Вы же помните закон Хика?

Снижайте когнитивную нагрузку.

С пользователями надо быть честным. Впрочем, как и в жизни с окружающими. Обычно это проще и лучше для тебя самого в итоге. Когда пытаешься обмануть, чтобы извлечь сиюминутную выгоду, может пострадать твоя репутация в будущем. Как минимум. Для бизнеса это тоже важно. Это вопрос доверия, вопрос того, насколько пользователи будут привязаны к твоему продукту, будут ли они любить его, считать своим помощником.

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

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

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

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

Сила в правде.

Насколько я помню, я ничего не писала в блоге на тему проектирования, хотя это моя профессия. Наверное, не хотелось какие-то больные моменты разбирать на публике, обострять. А писать часто хочется как раз о больном. Так и повелось, что в блоге живут только мои увлечения, то, чем я занимаюсь после работы. Хотя голова часто занята совсем другими думами.

В последнее время стала замечать, что хочется отметить какие-то мысли на эту тему, обратить на них свое внимание, да и другим это может быть интересно. Попробую писать об этом тут, даже если заметки будут короткие, капитанские, очевидные. Они тут будут, потому что показались мне интересными или важными. Это не какие-то открытия и озарения, скорей, это те вещи, которыми я часто руководствуюсь в своей работе, о которых часто говорю. Для меня они стали обыденными, но от этого они не стали менее важными. Записи будут по тегу #проектирование

Я очень хочу, чтобы эти темы не порождали споров с мелкими придирками и потерей берегов. Но, как и на работе, я всегда готова пояснять свою точку зрения, если она непонятна. У кого-то мнение будет отличаться от моего, а в чем-то я могу ошибаться. Вы можете пользоваться моим опытом, можете нет — решать вам. Если у вас будет что сказать — смело говорите. К здоровой критике я отношусь положительно.

Это была затравочка :) Не переключайтесь.

Сходили с Никитой на защиту работ после курса веб-дизайна в УрГЭУ. Пооценивать. Это уже потом оказалось, что ребятам просто не давали дизайна и проектирования. Ну, как не давали. 40 минут, говорят, было из 3 месяцев курса. Все равно, что и не было. Но мы-то не знали сначала. Пришли такие довольные, приготовились давать несомненно ценные комментарии, блистать сообразительностью, поражать наповал профессионализмом. Сели тихонечно на задней парте в предвкушении, нам выдали листочки с фамилиями и критериями оценки, штук 8-10 этих критериев. По каждому надо было оценить работу по десятибалльной шкале. Все критерии связанные с темой дизайна, нормальные. Ну, а дальше случилось неожиданное для нас. Собственно мы увидели первую работу и ничо не поняли. Верней суть-то была ясна, но вот дизайн и проектирование... А? Что это? Где-то на третьей работе я поинтересовалась, а сколько по времени читали весь курс и сколько там было собственно дизайна. И все встало на свои места.

Не хочется сейчас лошить работы ребят, хочется какой-то пользы. Что могли бы сделать эти ребята, которые ничего не слышали о дизайне? Могли ли как-то улучшить ситуацию? Они познакомились с версткой, могли верстать сайты, прикручивать CMS, они явно сообразительные, раз осилили это, что бы их спасло?

Спасло бы просто подумать.

Что сайты — для людей

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

Пусть одна страница, вырванная из контектса. Без сценариев. Вот на ней градиентный фон прямо радугой, чтобы было веселей. Окей, можно не понимать, что это некрасиво, потому что жил и не обращал внимания на красивое и некрасивое, другие вопросы волновали, не умеешь отличать. Ничего страшного, всякое бывает. Не все тут кругом дизайнеры. Но если ты на этот градиентный фон кладешь текст и он сливается с фоном по цвету в тех местах, где совпал, это же ты можешь понять, просто как человек, который хочет этот текст прочесть. Он же для этого там, правда же? И если его нельзя прочесть, то что-то тут не так. Наверное, надо что-то поменять, да ведь?

Потому что сайты — для людей

Или же почти белый текст на белом фоне. Не будем тут говорить о достаточной контрастности для удобства чтения. Это умно и сложно. А просто задумаемся, легко ли это, вглядываться в такие пункты меню? Ну нет же. И агрумент, что делал для жены (или девушки), а ей так понравилось, разве это аргумент? Для кого этот сайт? Наверное, для людей, которые придут и будут там пытаться разглядеть. Им до лампочки, кому там что нравится, они всего-то хотят текст прочесть. Главная мысль: сайт — он не для вас, не для вашей радости, даже если там ваши товары или работы. Он для тех, кто туда придет. Значит все вопросы-ответы должны строиться исходя из этого. И надо любить то, что ты делаешь, а раз любить, то и защищать это. Объяснять, что вот так нехорошо, объяснять причину. Ты ж на это время потратил, как так можно взять и загубить, просто потому что кто-то так хочет.

Сайты же — для людей

И вот я задаю вопрос по очередной работе, а какая цель у пользователя на этом сайте? И мне отвечают: цель — показать, что тут есть бревна, срубы, тут вот в меню есть то и се. Тогда я повторяю вопрос: не у сайта какая цель, а у пользователя.

Сайты-то — для людей

Или вот два товара, а кнопка покупки висит прямо посередине между двумя. К какому товару относится кнопка? И не надо тут знать про теорию близости. Это же ну просто непонятно тому, кто придет.

Ведь сайты — для людей...

На самом деле не так страшно, что мы попали не туда, куда хотели. Там всем кругом было не удобно, что позвали дизайнеров, а оценивать собственно дизайнерам было нечего. Бывает, не разобрались. Страшно, что люди почему-то просто не привыкли размышлять о том, что делают. И для кого.

Периодически появляются статьи о том, что дизайнер должен уметь верстать или кодить. Мол тогда всем будет счастье. Тогда дизайнер поймет, какие решения предлагать разработчику не стоит. Это сократит время на изменение негодных прототипов. Вроде бы выглядит разумно. Но почему-то никто не упоминает аргументы против.

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

А кроме того, наверняка дизайнер не будет так же хорошо разбираться в коде, как и разработчик. Из-за этого дизайнер может запросто ошибиться и отвергнуть какие-то хорошие для пользователя решения, которые сочтет сложными в реализации. А может и наоборот, знать что и как будет выглядеть в коде, но не знать каких-то архитектурных ограничений, каких-то тонкостей, которые знает только разработчик. И только разработчик может придумать способ обойти какие-то из них. То есть полной информацией все равно обладает разработчик. Тогда к чему это все?

Может просто не стоит кидаться отрисовывать прототипы, если есть сомнения в концепции? Это же так просто — взять и на словах рассказать разработчику, какое решение было бы идеальным для пользователя, почеркавшись на бумажках. Обычно уже тогда можно понять, что действительно будет сложным, а что только показалось таким. Всегда проще спросить. И не надо тратить кучу времени на усвоение новой, на мой взгляд, ненужной информации о коде, которая может только запутать, дизориентировать, сфокусировать не на том. Ведь так же качественно, как разработчик, не усвоишь и будешь ограничивать свои решения понапрасну. Думаю, это просто неэффективно. Зачем все усложнять. Лучше прокачиваться в проектировании, дизайне, так будешь больше полезен. Здорово, когда дизайнер может выходить за свои привычные рамки и придумывать новые интересные решения, удобные для пользователя, не ограничивая себя ничем. Это еще успеется. Всегда можно упростить после разговора с разработчиком, немного изменить хорошее решение. Лучше, чем сразу придумывать не очень хорошее, зато легко реализуемое. А разработчики, они же под боком, не прячутся, с ними можно говорить и все узнавать до финальных прототипов. Про верстку все то же самое.

Или я что-то упускаю? Может специфика моего проекта такая, а где-то там не так?

Ищем проектировщика в Контур. Пишите: me@oromanova.ru