Блог NunDesign

Ну и правильно, зачем веб-разработчикам учить географию? Я тоже так считаю, каждый же должен заниматься своим делом, правильно? Поэтому ничего удивительного в том, что некоторые американские программеры уверены, что всё население земного шара живёт в пятидесяти соединённых штатах, а что тут такого? И тогда появляются замечательные, интересные сервисы, на которых очень хочется зарегистрироваться, но маленький квест затыкается на втором шаге при заполнении формы регистрации, где обязательным является указание страны проживания (подгружается стандартный список всех известных стран, выбираю Украину) и штат (! подгружается список из тех самых 50-ти соединённых штатов, какую бы страну предварительно из списка стран ты не выбрал). И этот “Please enter a valid state” становится непреодолимой ошибкой, которая не пустит никого на конечный этап заполнения формы.

Конкретно эту форму (на сайте sharpie.com) обойти удалось – достаточно оказалось при выбранной Ukraine и написанном ручками Kharkov из списка штатов указать один любой; так что у меня получилось Ukraine-Alabama-Kharkov, но некоторых разработчиков хватает на то, чтобы делать проверку на города каждого конкретного штата и добавлять ошибку “Enter a valid city”, но такое внимание делает форму ещё более нелепой: если в первом случае зарегистрироваться всё-таки, пусть и с дурацким адресом, получается, то во втором, понятное дело, нет, и тогда просто разводишь руками и удивлённо вопрошаешь: детки, зачем, ну зачем вы влепили в форму выпадающий список со всеми известными странами?? Чтобы форма выглядела солиднее? А дальше разработка не пошла, потому что всё равно основная платежеспособная аудитория у вас там, среди ваших 50-ти штатов? выпадающим списком пожертвовать при этом никак? Ну смешные, право.

У-у забыла, где-то совсем недавно на каком-то из российских магазинов была схожая ситуация: когда в форме доставки товара страну (Украину ту же) выбрать было можно, но дальше город тоже выбирался из списка; города в списке, ессно, были только крупные российские, штук 20, кажется. Видимо, по сценарию предполагалось, что служба доставки обеспечивает эту самую доставку только в конечное число городов (вот эти самые 20 из списка), и в этом нет ничего такого, если не задействуются внешние службы доставки, а работают только свои в рамках какой-то партнёрской сети. Но зачем, зачем при этом давать возможность выбрать страну?

На Web 2.0 Expo в Сан-Франциско, Кевин Линч (Kevin Lynch), Adobe Chief Technology Officer, презентовал бета-версию Flash Catalyst, программу для веб-разработки, которая позволит разработчикам импортировать любую графику и превращать каждую картинку в WEB элемент – кнопки, поля ввода, меню, и т.д. Flash Catalyst также сам создаст Flex код для этих элементов, с возможностью для разработчиков-программистов так же управлять кодом вручную; так же есть возможность коннектиться к Facebook API.

Помогите решить не сложную на первый взгляд задачку. Есть форма поиска (людей) в очень большой базе данных. Представлена в двух вариантах – дефолтовый (easy) и advanced. Но уже с оформлением дефолтовой, простой формы возникли траблы – она не только интуитивно не понятна, она, пока что, всем своим видом вводит пользователя в заблуждение.

При этом в форме одно из первых двух полей (или имя, или фамилия) – обязательно. Если не заполнено хотя бы одно из них (или оба), то поиск по другим полям не возможен, если заполнено одно (или оба), то остальные поля (год, страна etc.) являются, правильнее сказать, фильтрами в результатах поиска. Обязательные для заполнения поля принято (уже привычно) отмечать звёздочками:

Но такая подсказка будет не верной, потому что сценарий, представленный на картинке, читается как “в форме есть ДВА обязательных поля – и имя, и фамилия”; на самом же деле каким-то образом нужно указать, что здесь два ведущих поля обязательны не по правилу “и”, а по правилу “или”. Остальные поля – не обязательны, но и поиск по ним, если не заполнено одно из двух первых, не возможен. Кнопка Search не блокируется, но при клике, если незаполнены первое и/или второе, показывается сообщение типа “укажите *имя* или *фамилию* персонажа”. Но получается, что эту информацию – о том, что одно из двух первых полей обязательно – пользователь получает уже после того, как попытался искать, указав, к примеру, страну проживания и год.

По логике разумно было бы признать, что элементами формы поиска здесь являются только текстбоксы “имя” и “фамилия”, остальные поля являются фильтрами в результатах поиска, но, поскольку аудитория приложения – совсем ни разу не гики и, возможно, даже не продвинутые пользователи, то распугивать их наличием блока “Фильтры” не хочется, и заказчик категорически против, да и разработчики с этим соглашаются. Варианты?

Просто отделить отступом или разделительной линией два первых текстобокса от остальных – явно будет недостаточное решение. Дизейблить (не давать возможности заполнить) вторичные поля-фильтры до тех пор, пока не заполнено одно из первых – нечестно и тоже непонятно. Попробовать разделить даже Easy Search на два блока, те два поля, одно из которых обязательно, в групбокс (или филдсет, кому как удобнее понять термин) Basic Search, второе – в Additional Search, причём до тех пор, пока в первом блоке не заполнено хотя бы одно из двух – второй блок неактивен:

Как только же в первой части формы заполнено хотя бы одно поле, т.е. получается, введена хотя бы одна буква в одном из двух текстбоксов, вторая часть формы становится активной:

В этом случае мы уходим от проблемы – как указать, что обязательное – одно из двух полей, уходим от звёздочек и задачи отобразить “и”/”или”. Но стало ли понятнее пользователю, что ему делать с этой формой? Да и вообще безобразие это – получается, мы даём пользователю не две формы, как планировалось изначально, а три – Basic, Additional и Advanced (фактически их две, да, но визуально первая тоже делится на две части)? Вынести же фильтровые поля (Additional) в форму Advanced Search тоже не очень правильно – поиск по имени, тем более не редкому, будет давать здоровенные списки результатов поиска, которые никто не будет просматривать/проверять, т.е. дополнительная фильтрация нужна здесь же, на главной (простой) форме.

В общем, на этом полёт фантазии закончился. Куда размышлять дальше?

Я понял – это намек, я все ловлю на лету,
но непонятно, что конкретно ты имела в виду?
Вот я не понял.
© НС

Интересно, все ли постановщики задач для разработчиков мечтают стать телепатами, или даже телепатами наоборот – чтобы не описывать задачу словами, а вбивать её разработчику прямо в голову, со всеми формальными оборотами, чувствами, впечатлениями, чтобы у разработчика мгновенно появлялось видение результата его работы, полностью соответствующее задаче? Как часто постановщик, в документах, на досках, на пальцах объясняющий разработчику, что ему нужно сделать, не может перешагнуть барьер непонимания (или недо-понимания) задачи?

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

Зато часто бывает по-другому. Разумеется, прежде, чем позволить исполнителю начать процесс преобразования, постановщик может убедиться в том, что задача понята правильно. Если нет, то повторять (изменять, дополнять) процесс постановки до тех пор, пока не убедится в том, что его понимают правильно В ДОСТАТОЧНОЙ МЕРЕ для того, чтобы начать работу. Это довольно забавный и трогательный этап, особенно, если смотришь на него со стороны, не являешься ни постановщиком, ни исполнителем. Эмоции, повышенные тона, напряжение возрастает… Почему?

1. Возможно, постановщик даун. Не может словами выразить, что же и с чем нужно делать.

1. а) Нет картины исходных данных. Встречается довольно часто: постановщик с заказчиками, аналитиками и прочими ответственными людьми обсасывает проблему, можно ли её решить, если можно – то как, и почему так, и в результате у него накапливается изрядное количество мелочей, каждая из которых незначительна сама по себе, но незаменима для построения живой системы. Часть этих мелочей через некоторое время становится “чем-то очевидным” для него, и он начинает полагать, что опираясь только на здравый смысл и обычный житейский опыт каждый первый (разработчик) и так поймёт их необходимость в системе. Т.е. либо не считает нужным передавать исполнителю информацию обо всех этих мелочах, либо ему даже не приходит в голову, что об этом тоже нужно говорить. Исполнитель недополучает исходные данные, соответственно, не понимает, что от него хотят.
2. б) Не даётся полное описание требуемого результата работы, цели. Тоже много разных причин, одна из типичных – конечному разработчику это не нужно. К примеру, потому, что это, на самом деле, корпоративная тайна. Поэтому изыскиваются такие слова и обороты, которые скрывают реальную цель работы, отрисовывая некую псевдо- цель, подобную исходной настолько, что исполнитель, сам того не зная, как раз и сделает то, что нужно заказчику. Но нарисовать мнимую цель, действительно подобную реальной – это, знаете ли, великое искусство, не каждому дано, и, как следствие, редко срабатывает так, как ожидалось.
   -
   Ещё одна часто замечаемая причина – отсутствие понимания цели у самого постановщика. Т.е как бы он предполагает, что понимание есть, но именно в процессе постановки непосредственному разработчику, уже на этапе повышенных тонов и обид, обвинений во взаимной тупости выясняет (-ся), что — да, разработчик указывает ему на, к примеру, технические несоответствия, и в относительно благополучных командах это заканчивается перекраиванием задачи, в соответствии с другим уже пониманием цели. А бывает и такая причина: постановщик действительно не понимает чётко что нужно сделать и перекладывает ответственность на разработчика, расчитывая на его опыт, на то, что он, такой умненький, сам сведёт концы с концами и догадается, что же нужно было сделать.
3. с) Методы решения не вписываются в процесс преобразования одной системы в другую. Конечно, чаще всего бывает, что ведущими будут причины а) и б), но при этом постановщик вообще не озабочен тем, чтобы дать полное описание исходной системы и цели, упор же делается на метод решения, который как будто бы подробно описывается, а исполнитель всё равно не понимает, что же ему нужно делать и, главное, зачем.

2. Возможно, разработчик даун. Разумеется, приятно работать со звёздами, которые всё схватывают на лету, предугадывают следующую фразу и даже при небезупречной постановке умудряются сделать работу лучше ожидаемого. Средний разработчик среднее количество рабочего времени среднего уровня сложности постановки воспринимает на среднем уровне достоверности. Что означает, что даже при подробной и вполне качественной озвучке 1.а), 1.б) и 1.с) он всё равно будет “тупить”. Да по каким угодно причинам. Сонный после безсонной ночи (ребёнок плакал, девушка требовала внимания, у друга день рождения) с временно пониженной способностью воспринимать информацию. Недостаточно квалификации у разработчика (он ли не “семи пядей”, или задача на самом деле сверх традиционного уровня сложности для существующей команды). Нет цели понять (скучно ему, не зажигает задача, приступ мозговой лени, слизни одолели).

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

По поводу альтернативных методов можно с примером. И в самом деле, как выше и было написано, очень много для понимания задачи значит опыт (и жизненный, куда же без него), и по специальности. К примеру, ставится задача талантливому, умному и сообразительному дизайнеру, у которого вовсе не было никаких приступов тупости. И изрядный (можно уже сказать так на сегодняшний момент) опыт рисования интерфейсов для веб-сайтов. Но не особенно значительный опыт рисования интерфейсов для веб-сайтов с динамическим контентом – так, всё больше рекламные сайты, один раз сверстал почти открыточный макет, так он и живёт. И вот один за другим приходят проекты, где дизайн нужен для динамического контента, начиная от произвольного (для разных групп пользователей) количества элементов меню и субменю и заканчивая текстами, которые добавляют пользователи. И раз за разом дизайнер рисует эскизы, умиляюще красивые, такие, какие с первого раза нравятся заказчику, но, мягко говоря, не особо удобные для динамики. Первые проекты приходилось контролировать и переделывать оформление тех блоков, которые при всей их красоте были не особо уместны для конкретной задачи. Потом были разговоры о том, что надо, надо, надо обучиться вёрстке, что пока не будет пережитого лично тобой опыта вёрстки, внедрения твоего дизайна в живой проект, пока не увидишь причины, почему так а не иначе, на словах не получается объяснить, в чём разница “презентационного-рекламного дизайна” от “дизайна для динамического контента”, и желающих помочь, от тимлидера до остальных верстальщиков вроде хватает, и книг, и работы, но… то одно, то другое, то времени нет, то жених ждёт, то как-то прям сегодня не хочется…

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

Вот честно признаюсь, можно было изначально на этапе эскиза очередной раз указать на “великое будущее” этого блока, видно было изначально. Но тогда сколько ещё проектов, сколько ещё элементов в эскизах придётся под диктовку переделывать, сколько раз повторить практически одну и ту же лекцию про динамический контент? В таких ситуациях лучше, если дизайнер уже сам переживёт эту проблему, запомнит её и не будет смешно настаивать, чтобы “пользователи вводили четыре строки текста в этом дескрипшине, ибо это важно для дизайна” (что по любому невозможно будет заставить сделать тех маркетологов, которые ещё и не наши, а заатлантические). Будет опыт. Будет на пол повторяющейся лекции меньше. А всё потому, что я не могу передать часть своего видения системы, включающего опыт проектирования-рисования-вёрстки-интерграции макетов для динамического контента, напрямую в мозг моему хорошему, талантливому дизайнеру, который рисует эскизы для наших проектов.

Разбираем-изучаем с утра по-раньше корпоративную почту; один из новых программеров, работающих на новом же проекте, удивлённо замечает: странно это, говорит, обычно когда разрабатывается новый сервис, люди сначала думают, а потом делают. А здесь как-то странно: сначала делаем, потом обнаруживаем траблы, переделываем; по результатам переделывания обнаруживаем ещё более стрёмные траблы, уже труднее решаемые, переделываем. Цикл может повторяться до момента, когда руководство разочаровывается в проекте, что автоматически означает — разочаровывается в разработчиках, этот проект наваявших. И правильно, кто виноват в том, что программа “не пошла”? Ессно, программеры. Собирается новая команда, которая получает исходные коды предыдущей версии с задачей “переделать”.

Но, извиняюсь, что такое “думать, потом разрабатывать”? Кто конкретно должен думать и о чём? Чем занимается штаб “думателей” до момента, когда программер создал пустой ещё проект и написал свою первую строчку кода? Это у кого как. Хорошо, когда думают все участники процесса, начиная от заказчика и дальше постановщиков (для непосредственных разработчиков на самом деле, как правило, и разницы-то никакой нет). Наблюдаю неоднократно (а, значит, локализовываем ещё один опасный камушек как не случайный) такое замечательное явление: заказчик предлагает разработать сервис (не важно, веб или виндовз приложение), основываясь на своей личной необходимости в нём. Как правило, такое происходит, когда у заказчика есть какой-то процесс, который он пытается автоматизировать с помощью компьютерных технологий и, видимо, находит для этого некие инструменты, программы или веб-сервисы, тестирует их, пытается использовать в работе и находит кучу недостатков. Знакомая ситуация, так ведь?

Поэтому когда заказчик говорит о том, что “рынок нуждается в нормальном инструменте для *таких-то целей*, есть много много людей, которые хотят такой инструмент, он будет продаваться, его только нужно сделать по-грамотному” – он (понятно, что речь вряд ли идёт об одном человеке) всё-таки опирается на свой какой-то уже наработанный опыт, и этот опыт автоматически распространяется на ВСЮ потенциальную аудиторию этого инструмента. Формулируются требования, пишется ТЗ, собирается команда, которая это ТЗ анализирует и приступает к работе. Не углубляясь в подробности описания жизненного цикла разработки сложного программного продукта перейду сразу к этапу тестирования сценариев поведения пользователя в программе на прототипах экранных форм.

Стоить заметить, что тестирование группой заказчика проходит при этом успешно, ему нравится (почти) всё, есть разумные замечания, есть нормальные рекомендации, это текущее и никого не пугает. Потом собирается фокус-группа для тестирования публикой совсем посторонней. Да, и вдруг оказывается, что обычный среднестатистический клиент со среднестатистическими навыками работы за компьютером сталкивается с тем, что ему непонятно ВСЁ. Как, зачем и куда. Аналитики отдела, который проводил тестирование, собирают информацию обо всех задачах, с которыми учасники фокус-группы не справились, трудных местах, на которых зависали, замечания, которые эти учасники высказывали в процессе. Кроме нескольких действительно конструктивных идей большая часть отчёта по результатам тестирования просто разгромная: это вообще не целевая аудитория подобных программ. То же самое, что для тестирования профессионального бухгалтерского приложения набрать ребят с ближайшего овощного ларька. Не, ну правда. Ок, может, не до такой степени, но похоже.

Получается, что мы должны (пусть ещё и в начале разработки, но всё же уже на лету) менять постановку задачи в целом: для кого всё-таки пишется инструмент? Если заказчик планирует выйти с ним на рынок и рекламировать для универсального пользователя, тех же домохозяек в том числе, он и должен получить продукт для универсального пользователя и домохозяек в том числе; ни к чему тогда такая развёрнутая функциональность, сложные формы, диаграммы и визарды разрешения конфликтов синхронизации данных (долго писать, но как раз этот визард, просто шедевр проектирования с моей точки зрения, удобный и понятный для всех наших и даже одобренный заказчиком, поставил в тупик 100% тестировавших из той самой фокус-группы неподготовленных пользователей). Да, разрабатывается совсем другая программа. И пусть весь интерфейс сводится к двум кнопкам, например, зелёной и красной (да, одной не обойдёшься, бывает), зато легко будет разобраться.

Всё-таки с большим подозрением отношусь пока к тестированию на экранных прототипах. К сожалению, не могла присутствовать лично — мы здесь, они там, за океаном, но что-то там недоработано имхо. Верится с трудом, к примеру, что на достаточно равномерном (скажем, тёмно-синем, ближе к чёрному, с белым текстом) интерфейсе с элементами форм в той же цветовой гамме – тёмно-синие бэкграунды и светлые+белые foreground`ы учасники фокус-группы не смогли выполнить “удалить пользователя” не смотря на то, что кнопка “Delete” – единственная ярко-красная, ещё и с соответствующим текстом. Может, что-то не то было в формулировке задачи?

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

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

И третье, что беспокоит: всё-таки отсутствие мотивации работы с программой. Почему заказчику пришла идея разработать этот инструмент? У него была необходимость, он работал с уже существующими аналогами, и необходимость у него остаётся. Какая же мотивация у тех участников фокус-группы, которые тестировали прототипы? Разобраться с интерфейсом и поскорее реализовать свою задачу на этом инструменте? Вовсе нет. Время в фокус группе оплачивается, что-то от 10 до 20 уе за час работы. На этом цель обычно заканчивается. “Всё равно на улице скучно”, “и друзья попросили там помочь”, “и десять баксов-то не лишние”, ни один мотив не сходится с мотивом потенциального пользователя программы. А вот 10 баксов за то, что он в этой программе исполнит что-то продаваемое (т.е. если исполнит – получит $10, не исполнит – не заработает), и мы получаем фокус-группу совсем других участников, и смотреть они будут на программу совсем другими глазами.

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

У нас продолжается наработка сурового опыта разработки ПО и сервисов разделёнными между двумя континентами командами. И сейчас те давние проблемы всего лишь синхронизации программерского кода и разрешения конфликтов в SVN представляются цветочками Оказывается, наиболее весёлый аттракцион происходит в том случае, когда идёт этап проектирования нового сервиса, так же разделёнными командами. И вот начата работа над новым сервисом, пока всё больше на этапе исследований, при этом маркетологи исследуют рынок и составляют портрет ЦА, программеры – изучают техническую часть и пишут тестовые примеры различных потенциальных веток проекта. В целом исследовательская часть подходит к концу, и перед дизайнерами становится задача – нарисовать дизайн “общего” экрана сервиса, включающий стиль для формы, логотип, различные панели-кнопки-формы и содержательную часть, которые будут присутствовать на, скажем, среднем экране (середина работы с сервисом), причём наиболее насыщенном всяким хламом.

Когда цели проекта сформированы сколько-нибудь внятно, прикинуть первую версию такого “среднего” экрана довольно просто; и дизайн был нарисован, и принят заказчиком восторженно, и даже программеры, которые изрядно придирались к некоторым элементам дизайна, как к трудно реализуемым или малоадекватным, наконец-то сказали, что всё замечательно. Т.е. утверждён будущий стиль дизайна сервиса. Игрушки закончились, и теперь нужно бы приниматься за отрисовку уже реальных экранов. И тут у нас начинается ступор. Потому что этап проектирования сервиса в целом полностью на себя взяла канадская команда. Именно они там у себя в своих конференц-румах ежедневно с отделом маркетинга, руководством и прочими участниками процесса бурно, по нескольку часов ежедневно (по словам нашего канадского управляющего) обсуждают сценарии поведения пользователя при работе с сервисом, только… Ни одно из этих обсуждений не заканчивается присланными прототипами экранных форм. Что ж за беда-то такая?

Человечек специалист, который у них, там, должен был бы рисовать прототипы, группировать по сценариям и присылать сюда готовые шаблоны для рисующего дизайнера, то ли не справляется, то ли вообще не подходит для такой работы. Его первый вариант экранов, отрисованный в Visio, который мы получили больше недели назад, даже на тот период был недостоверный и не отвечающий никакой логике, не иллюстрирующий ни один из возможных сценариев. Так, набор каких-то страниц с формами, который мы покрутили-покрутили, и отложили, как пример показательно безграмотной работы. Тогда решили попробовать другой метод: устроили телефонную конференцию с включенным на компьютере одним общим монитором (через сервис logmein.com, давно используем его в работе и радуемся, что такое есть). Предварительно, до начала конференции, набросали наиболее вероятных 5-7 экранов; оказалось, что для того, чтобы диалог был конструктивным, канадским менеджерам действительно проще получить пусть и не оптимальныме (а никто и не говорил, что это последняя версия), но хоть какие-то экраны.

Конструктивный диалог включал в себя обсуждение поведения пользователя в программе начиная с самого первого шага, к примеру: пользователь запускает программу впервые, что он видит? Грузится форма программы и в ней – сплеш с несколькими вероятными шагами. Обсудили шаги – что и зачем он выбирает, выяснили, что сплеш-форма имеет три представления, при выборе первого пути он сразу переходит в рабочий интерфейс, при выборе второго – на сплеш-же форме ему показываются некоторые опции и т.д. В обсуждении принимают участие и менеджеры, и программеры, которым зачастую тоже есть что сказать, и дизайнеры, ессно. Я всё это время зарисовываю черновики обсуждения с эскизами форм и текстовыми пометками. Дальше отрабатываем сценарий по первому пути: нулевой экран, на который пользователь попадает, инструменты, которые ему необходимы, акценты, которые подскажут, куда и что дальше, вторичные опции. Я на бумаге рисую черновик нулевого экрана, замечания – что успеваю (потому что в процессе обсуждения тоже принимаю участие, есть что сказать, предложить или наоборот – осудить как неэффективное).

В процессе обсуждения, кстати, народ довольно часто повышал голос. Особенно конфликтные моменты возникали между программерами и кем-то другим: что делать, если на панели размещены два *горизонтальных бегунка* для изменения размеров просматриваемой области (zoom) и ограничителя времени (time) – они так красиво нарисованы рисующим дизайнером, так эффектно смотрятся, но как они будут меняться, когда изменится горизонтальный размер панели? Должны они тоже “ужиматься” и до какого минимума или должны “уезжать” за край рабочей области? Или имеет смысл сделать их вертикальными, но ведь тогда придётся передоговариться с “генеральным”, который уже официально сообщил, что эскиз того самого презентационного варианта интерфейса ему так понравился, что он ТРЕБУЕТ, что бы ничего не меняли ни по пожеланиям отдела маркетинга, ни по техническим требованиям программеров, а зум и таймер уж больно замечательно визуально вприсываются именно в горизонтальном состоянии… А с точки зрения привычности-удобства для пользователя вертикальные бегунки будут удобнее… и т.д.

В общем, конференция прошла успешно, я успела отрисовать изрядное количество черновиков экранов, и сегодня девочка-дизайнер уже рисует визуальные представления по этим черновикам. Они-то на самом деле, чуть причёсанные, и стали прототипами экранов для дизайнера. Формально, если бы было больше времени (и каждый занимался своим делом) по этим бумажным черновикам стоило бы сделать аккуратные схемы в каком-нибудь правильном редакторе, но сроки, сорванные канадским “проектировщиком” из-за того, что сначала он нарисовал не то, что надо потому что не понял, что же надо, потом в отпуске был, потом просто потерялся из-за интенсивных дискуссий с идеологами-генераторами идей по сервису. Отчасти его кст.говоря стопорил именно поток-объём идей: фантазёры-идеологи придумывали что-то совершенно не из реального мира, настолько оторванное от жестокой действительности, что он даже не знал, как это можно преобразовать в экранную форму и тем более в сценарий (набор экранных форм). И даже более того: часть нафантазированных идей тормозилась из-за того, что наиболее приближенные к технологиям, к реальной разработке менеджеры останавливали некоторые особо фантазийные идеи именно тем, что не были уверены, что разработчики, гм., смогут “такое” реализовать, а обсудить непосредственно с разработчиками техническую возможность невозможно (извиняюсь), потому, что разработчики спят, отделённые от дискуссии часовым поясом в +7 часов. Но проблема, должен ли проектировщик хотя бы в какой-то мере быть в курсе особенностей технологий разработки — это к вопросу о небольшой дискуссии по поводу одного из недавних постов “Дизайнерское: интерфейсы в исходниках” в трансляции на ya.ru, когда обсуждали требования к вакансии специалиста, то ли инфоарха, то ли проектировщика интерфейсов

Lisa:
1. Понимание особенностей разработки на .net для инфоарха точно будет обязательным входящим, или это можно рассказать при общей вменяемости человека?
2. Я видела, когда аналитика сочеталась с коммуникабельностью, но редко люди признают в себе оба этих качества одинаково сильными То есть аналитика тут важнее и ее человек должен самопризнавать, но я бы вторй пункт формулировала бы не как коммуникабельность, а как готовность и способность обсуждать и работать в команде. Оттенок чуть другой.
3. “Получение, обработка и синхронизация информации о текущих этапах разработки между разными подразделениями, работающими над проектом: отделом маркетинга, программистами, дизайнерами, интеграторами.” Это инфоарха задача или все-таки менеджера проекта? Я бы инфоарха не стала бы нагружать синхронизацией в процессе, в начале – да, деваться некуда, а в процессе это скорее для пм задача, отдавать инфоарху для внесения изменений уже согласованное.

Tatyana:
1. Конечно, это не обязательное входящее но у нас 99% проектов на дотнете, рано или поздно спецу придётся научиться считаться с особенностями разработки на .Net, не такие уж они сложные и недоступные для понимания. Для человека открытого информации (что закономерно для такого специалиста) проблем не будет.
2. Да, “коммуникабельность” — само слово неудачное. Именно готовность и способность обсуждать. Здесь вот какая проблема: каждое из подразделений (возьмём в качестве подразделений отдел маркетинга,дизайнеров и программеров) плохо умеет “общаться” на рабочие темы между собой. Во-первых снобизм у каждого из подразделений, во-вторых специализация – каждый видит своё и не видит чужое, из-за этого часто бывают конфликты. У инфоарха не должно быть проблемы с неумением договариваться с разными подразделениями при получении от них информации и при выдаче им.
3. Нет, нельзя сказать, что это “задача менеджера проекта”. Просто в задачи менеджера проекта тоже входит в какой-то мере получение, обработка и синхронизация информации о текущих этапах. Видимо, они получают, обрабатывают и синхронизируют немного разную информацию менеджер – командами и задачами между командами, инфоарх – архитектурой проекта.

Так вот хотя бы общее представление о технологиях разработки вообще и технологии, на которой будет разрабатываться сервис в частности человек должен иметь, хотя бы именно затем, чтобы уметь вовремя реагировать на фонтанирующих идеями коллег, чтобы они не только сказки сочиняли (а это, кстати говоря, тоже важно и нужно, без фантазёров, сочиняющих нереальное, трудно даже пытаться создать оригинальный сервис), но и по текущему проекту думы думали.

В общем, описанным где-то там выше способом мы формируем первую группу наборов экранных форм, иллюстрирующих разные сценарии поведения пользователя в этой программе. Вплоть до того, что у файлов-иллюстраций каждого отдельно взятого сценария будут порядковые номера, чтобы канадские менеджеры не запутались при обсуждении первого, предложенного уже нами варианта; ведь следующий этап, всё ещё предваряющий уже реальную разработку, будет заключаться в том, что эти экраны (хоть и статическими картинками) будут тестироваться группой подопытных, которые будут изображать из себя представителей ЦА и создавать первую базу отзывов о работе будущей программы. А программеры уже в нетерпении подгоняют: их тестовые “учебные” скрипты готовы переростать в реальные, и, кажется им, затягивается процесс в бессмысленных совершенствованиях наименее важного для работающего сервиса этапа – проектирования интерфейсов и сценариев поведения.

Для нас же в общем-то понятно: канадское руководство просто пока прикрывает не особо одарённого чувака, который как бы “проектировщик интерфейсов”, понимает, что чувак не справляется, но, извиняясь перед нами, говорит о том, что “вот он ещё учится, пусть на этом проекте он ещё ошибается и делает неправильно, но если его не отшить, то на каком-то втором-третьем проекте у него начнёт получаться”. И ведь повлиять на ситуацию не возможно даже убеждениями в том, что на нашей стороне, в нашей команде этот этап – проектирования интерфейса – всё равно получается лучше, может сюда его и перенести? Ан нет. Почему? Потому что все те самые идеологи-фантазёры с генеральным в компании — они все там, за окияном, и проектировщик тоже им нужен на самом деле там, и это справедливо. Он должен их видеть, слышать, щупать общаться с ними, это должен быть диалог не только в процессе фантазирования, но и в процессе работы над прототипами, набросал черновики, показал, обсудили, перерисовал, показал, обсудили… а как удобно такие обсуждения иллюстрировать тут же зарисовками на доске с фломастерами! тут же стёр, дорисовал, показал, обвёл акцент… динамика! Мы оказались в менее динамичной среде: мои бумажные прототипы, дизайнерские эскизы, отрисованные в редакторе – это уже статика, на которую уходит больше времени; хорошо ещё, что почти всё, отправляемое от нас, почему-то утверждается почти без замечаний.

По поводу трудностей, которые возникают в таких распределённых командах, хочу процитировать кусок из одной замечательной статьи, найденной уже давно на rsdn`е и не закрываемой в окне Оперы уже несколько месяцев, изумительно иллюстрирующей именно наши проблемы, которые наблюдаю ежедневно, статьи Алистэра Коуберна “Люди как нелинейные и наиболее важные компоненты в создании программного обеспечения”

Основным фактором в разработке программного обеспечения является возможность коммуникации. На рисунке 1 изображена некая кривая, с помощью которой я иллюстрирую свои методологические рассуждения. На этом рисунке видно, как падает эффективность коммуникации, если исчезает ее модальность и синхронизация. Этой теме посвящено несколько исследований (см. [Pl] и [Si]), кроме того, эту же зависимость подтверждает и Вайнберг, который описывал проекты около 30 лет назад [Wei].

Самым эффективным видом коммуникации является непосредственное, личное общение (например, когда вы обсуждаете что-либо и рисуете при этом на доске). Если мы будем убирать одно за другим все возможности общения, присущие двум людям, рисующим у доски, мы увидим, как падает эффективность коммуникации. Убирать мы будем следующие свойства:

• Физическая досягаемость. Я не знаю, как это объяснить, но физическая досягаемость собеседников влияет на их общение. Что бы ни лежало в основе этого влияния – трехмерность, синхронизация, запах или малозаметные визуальные сигналы – при коммуникации это имеет большое значение.
• Разнообразные модальности. Человек общается не только словами, но и при помощи жестов. Часто человек может высказать свое суждение жестикуляцией, например, поднимая бровь или указывая на что-то пальцем.
• Интонация и синхронизация речи. Чтобы подчеркнуть важность какого-либо высказывания или, к примеру, свое удивление, говорящий может ускорять или замедлять темп речи, делать паузы или изменять интонацию.
• Ведение диалога в реальном времени (вопрос-ответ). С помощью вопросов слушающий выясняет для себя то, что ему было неясно в речи собеседника, или же получает дополнительные сведения, которых ему не хватает для полного понимания предмета. Синхронизация вопросов и ответов является основополагающим определением типа коммуникации.

Итак, что же произойдет, если мы начнем убирать одно за другим все эти свойства?

• Убираем только физическую досягаемость. Поместим собеседников на противоположные концы видеосвязи. В принципе, при этом сохраняются все основные свойства физического присутствия, и тем не менее, эффект уже не тот. Когда мы испробовали этот способ в Норвегии, где одна часть команды разработчиков находилась в Осло, а другая – в Лиллехаммере, то оказалось, что команда находила верные проектные решения, только когда всем удавалось собраться вместе. Даже то время, которое люди тратили, чтобы вместе дойти до электрички, было более продуктивно для работы, нежели видеоконференция.
• Убираем жестикуляцию и визуальную синхронизацию, оставляем интонацию и вокальную синхронизацию (другими словами, используем для общения телефон). Большинство людей во время беседы по телефону рисуют. Если человек рисует линию, которая соединяет два прямоугольника, это значит, что он собирается сказать нечто важное, то, что нужно отметить особо. Визуально-слуховая синхронизация информации закрепляет в сознании человека ее суть. Когда люди говорят по телефону, эта синхронизация исчезает, а вместе с ней из коммуникации исчезают жестикуляция, выражение лица собеседника, и т.д.
• Теперь уберем голосовую синхронизацию и интонацию, оставим лишь возможность задавать вопросы (электронная почта). Без голосовой синхронизации мы не можем ни сделать эффектную паузу, ни подождать, не будет ли у собеседника возражений или вопросов, ни ускорить или замедлить темп речи, чтобы сделать высказывание. Лишив себя возможности использовать интонацию, человек не может выразить с ее помощью, насколько удивительна, скучна или очевидна выраженная в письме идея.
• Теперь уберем возможность задавать вопросы (но восстановим один из перечисленных выше факторов). Не имея возможности услышать вопросы собеседника, говорящий должен сам догадываться, что тот знает или не знает, какие вопросы мог бы задать, и включать в свою речь ответы на эти несуществующие вопросы. И все это он должен сделать, не имея обратной связи со своим слушателем. Этот вид коммуникации допускает наличие визуальной (видеокассета) или слуховой (аудиокассета) информации.
• И, наконец, убираем все свойства коммуникации – визуальные, слуховые, голосовые, синхронизацию общения, возможность задавать вопросы – что же мы получаем? Правильно, бумажную документацию. На приведенной выше модели вы видите, что документация является наименее эффективным способом коммуникации из всех возможных. Тот, кто пишет документацию, должен строить догадки относительно своей аудитории безо всякой обратной связи, у него нет возможности использовать ни синхронизацию и другие эмфатические сигналы, ни жестикуляцию и интонацию.

Новый дизайн MoiKrug нравится больше прежнего – чистенький, светленький, лаконичный, всё больше приближается к официальному стилю Яндекса.

Но к некоторым экранам не возможно не придраться. Вот, к примеру, замечательный раздел “Мои коллеги” при условии, что никто из моих коллег на сервисе не представлен:

Как это, интересно знать, я могу быть своей собственной коллегой? Зачем же меня в этот список? Это что-то сродни “добавить себя во френды”. Хорошо, что хотя бы кнопка “пригласить (себя) в 1 круг” задизейблена. В любом случае имхо добавлять “себя” в список своих коллег — излишне.
Если в списке найденных позиций всего один элемент – на самом ли деле так нужны целых два чекбокса типа “выбрать все”, окружающие никакие не “все”, а единственный элемент списка?

Ещё одно спорное решение – с пересечённой навигацией, когда один подраздел принадлежит сразу нескольким разделам. Никогда не нравились такие решения, всегда сбивали с толку юзеров и вызывали недовольство сервисом. Простой пример: заходим в раздел “Сообщения”, оттуда из подразделов выбираем “Вакансии” (т.е. предполагается, что мы получим список сообщений-вакансий) видим вроде пока логичную картинку с навигацией:

После этого кликаем на любое сообщение из полученного списка и оп-па! Меню меняется на такое:

Где я, кто я? Теперь я не в “Сообщениях”, а в “Работе”, в каком подразделе раздела “Работа” нахожусь? Где подменю “Отклики”?

Интересное решение с логотипом Moikrug+Yandex. Да, по традиции логотип размещён в левом верхнем углу, воспринимается единым, цельным объектом, но его “верхняя часть” ведёт на главную яндекса, а нижняя – на главную Moikrug соответственно.

Вот только интересно, как много благодарных пользователей скажут своё вежливое “спасибо”, когда, как и на других проектах, потянутся в этот левый верхний угол,чтобы, скажем, вернуться на главную страницу проекта MoiKrug, и, не прицелившись, попадут в Yandex?

А ещё интересная какая штучка! Временной вертикальный градусник в разделе “Люди” -> “дни рождения”. Который сворачивается по месяцам. Очень оригинальное решение, правда. А вот поздравить *не яндекс.открытками*, а просто текстом по-прежнему из этого интерфейса нельзя, неужели же ж все прям так любят эти открытки и ни разу никто из пользующихся сервисом не попросил такую простую задачку решить? А я каждый раз, если хочу кого-то поздравить, выхожу из интерфейса “дней рождений”, и иду отправлять пользователю обычное сообщение с поздравительным текстом.

Пару дней назад искали с хорошим знакомым информацию об одном харьковском пригороде; нашли мало чего, даже гуглмапс выдал больше информации, чем веб-сайты по запросу. Долго рассматривали один “информационный” сайт, на котором якобы рекламировался новый, довольно большой жилой микрорайон, с тучей новостроек и продающихся квартир. Только и удивлялись: рынок недвижимости — один из самых денежных рынков, это вам не бижутерия или компакт-диски, это большие деньги; сайт же, рекламирующий эту самую недвижимость, не просто нищий, вообще никакой: навигация бедная и непродуманная, фотографии этого микрорайона – убогие, отвратного качества (ни одной современной мыльницей такого не исполнишь), на фотографиях — всё больше котлованы и рытвины, сплошной депресняк. Дизайн явно исполнен не дизайнером, а типа “сыном брата секретарши”, если не самой этой секретаршей.

Знакомый всё удивлялся: как же такое может быть, ведь презентуются на продажу очень, очень дорогие вещи. Чуть даже заспорили с ним о том, кто же в подобных случаях виноват в том, что в сети появляются такие сайты, и ведь не “авторские” васейпупкиных, у которых и целей-то никаких нет. Заказчик? Это ведь он, по всей видимости, рассказал о том, какие должны быть разделы на сайте, какая информация внутри разделов. Это он, по всей видимости, предоставил эти убогие плохого качества фотографии “с мест событий”. Дизайнер? Разработчик — ему-то что, что дали, то он и сделал, и бюджеты, скорее всего, были низкие, и заказчик, конечно же, даун, ему ничего не объяснишь, и вообще, он что, должен с пеной у рта что-то этому толстому богатому дяде доказывать?
(more…)

Вчера анализировали некоторые присланные за последнее время разными дизайнерами эскизы на веб-сайты; только и удивлялись, как много общих ошибок, связанных, к примеру, со шрифтами, их выбором, оформлением, размещением. Некоторые из этих ошибок настолько очевидны, что кажется странным, что дизайнеры с нескольколетним опытом работы их не замечают или не считают ТАКИЕ ошибки сколько нибудь важными. Однако же речь идёт об одном из самых важных элементов дизайна интерфейса, а в случае информационных проектов, служб и сервисов – самом важном.

К примеру, в одной из прошлых заметок я писала о том, как часто дизайнеры, рисующие эскиз, забывают о том, что текст, который на конечном веб-сайте будет отображаться текстом, желательно в эскизе ставить с отключенным anti-aliasing`ом, что, с одной стороны, является подсказкой верстальщику о том, что этот текст – не элемент оформления, который будет картинкой, с другой стороны – не вводит в заблуждение заказчика, который, утверждая эскиз, видит одно представление, получая отвёрстанный веб-сайт – совсем другое. Оказывается, обратная проблема – тоже не редкость, когда текст, на эскизе отрисованный явно со спецэффектами и должен на сайт ставиться соответствующей картинкой, почему-то отрисовывается без антиалиасинга, и это не элемент дизайна. Типичный пример:

(more…)

Я уже расказывала о том, что наши дизайнеры кроме прочих задач рисуют эскизы рекламных сайтов, большей частью на наши же программы и сервисы, в том смысле, что разрабатываемые у нас, а не для сторонних заказчиков. Таких рекламных сайтов на каждую тему может быть несколько: организовывается ли акция, или  выпускается версия программы, заточенная под определённые задачи (суть определённых задач заказывает отдел маркетинга, у них там свои исследования) или затеваются продажи на другой рынок (один из примеров – индийский рынок, и рекламная компания, ориентированная на индусов, там и цветовые гаммы использовались другие, не такие, как для американской аудитории, ещё была кое-какая специфика). В принципе постановка задачи для рисующих дизайнеров всегда почти одинакова: чётко (не запрятано среди прочих “элементов дизайна”) видно название программы или сервиса, тексты, которые кратко дают понять, что это за программа и зачем она юзеру – в первой половине экрана, и СамаяГлавнаяКнопка “Download Now” (для программ) или “Join Now” (для сервисов) в правой верхней части экрана, по исследованиям отдела маркетинга эта зона – самая комфортная для клика по главному элементу сайта.

Но не следует преуменьшать роль дизайнера при создании эскиза сайта: визуальными элементами, комбинациями цветов, формами, размерами можно создавать акценты и манипулировать вниманием посетителя, поэтому базовые рекомендации, в том числе и по поводу места размещения СамойГлавнойКнопки – не обязательное руководство к действию, а упрощённая формулировка более расплывчатой задачи: дизайн должен быть таким, чтобы пользователь кликнул на кнопку и скачал программу или присоединился к сервису. Если эта задача дизайнером выполняется, и зона, где размещена главная кнопка, по статистике и в самом деле самая кликабельная, самая “активная зона”, то никакой отдел маркетинга не станет придираться к формальным постановкам задачи.

(more…)