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

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

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

• Умение быстро разбираться в произвольной прикладной теме. Будет это какая-то программа-конвертер музыки или видео, или очередной антивирус, или TV-клиент – человечку придётся в короткие сроки разобраться с задачей и базовыми техническими особенностями проекта.
• Умение оценить целевую аудиторию и построить примерный портрет потенциального пользователя – может это гик озабоченный, или же “пересiчнi громадяне” – обычные люди, которые используют программу с исключительно развлекательной целью и т.д.
• Умение быстро разбираться в интерфейсах программ, любых. Тут, как я предполагаю, всё-таки должна быть практика использования разных тулзов (windows в частном случае) , редакторов, игровых интерфейсов, офисных приложений. Человечек не консервативный, без стереотипов типа “я пользуюсь винампом и остальные плейеры мне не интересны” или FireFox рулит а все остальные отстой. Гибкость, динамичность, любопытство очень помогут в работе.
• Умение общаться с разработчиками. Первые месяцы уж точно придётся работать над полуготовыми приложениями, т.е. это полуготовое приложение нужно будет понять – в чём его суть, почему, зачем и как используются те или иные формы, составить для себя все существующие сценарии поведения по приложению.
• Умение выработать рекомендации по сценариям доступа к интерфейсным окнам и по оптимизации содержимого интерфейсных окон, а так же рекомендации по дизайну и элементам оформления. Это, собственно, и есть главное умение и суть работы, для которой открыта вакансия. И здесь я вижу дополнительные сложности.

Вернее, много сложностей. Ведь у человечка должно быть не только понимание того, как сделать, чтобы было комфортно и удобно тому или иному юзеру? Должно быть понимание логики построения интерфейсных форм и умение обосновать – почему рекомендовано то или иное решение. И примеров море. Вот, к примеру, этап, когда при регистрации показывается интерфейс, где нужно ознакомиться с лицензией и согласиться или не согласиться с ней. По логике в большинстве случаев у пользователя есть выбор между двумя динозаврами – или соглашусь, или не соглашусь. Для реализации этого механизма я встречала самые разные, иногда парадоксальные решения. Встречала, когда под блоком текста предлагался выпадающий список с двумя элементами – соглашаюсь/не-соглашаюсь. Или было недавно совсем – два чекбокса, по дефолту оба открыты, выбираешь один из – второй дизейблится, и если хочешь поменять решение – сначала должен снять чекбокс с выбранного, тогда со второго уходит disable, оба активны – можешь, если хочешь, выбрать второй чекбокс. Хотя в самом обычном случае прочтение и согласие с лицензией – обязательный этап для инсталляции программы, и если не соглашаешься, инсталляция заканчивается ничем (после окошка “вы уверены, что отказываетесь от продолжения?”), т.е. что? достаточно ОДНОГО ЧЕКБОКСА, или соглашаюсь, или не соглашаюсь. Зачекал – продолжается инсталляция (или некоторые для упрощения процедуры по дефолту показывают чекбокс уже зачеканный чекнутый включенный), нет – досвидос.

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

И даже такие простые сценарии нужно уметь обосновывать – отчего, почему и как. Или, к примеру, если юзер инсталлирует триальную версию программы, имеет ли смысл тыкать ему кнопки “зарегистрировать для условно-бесплатного использования” или “купить” во все интерфейсы программы, даже в окна с Settings или Preview? А с другой стороны, допустимо ли не показывать ему эти кнопки (где-то в сомнительной понятности меню Help в списке сделать элементы “Register” и “Buy “), а после того, как юзер заинтересовался функционалом и что-то там насоздавал/нагенерил, потратил дофига времени и захотел сохранить, ему оп-па! а сохранять нельзя, потому что версия триальная. Или ещё мрачнее: юзер опять же заинтересовался, вроде подразобрался, заполнил одну нелёгкую форму, заполнил вторую нелёгкую форму, кликает “отправить”, и только на N-ом шаге обнаруживает, что сначала должен купить версию или зарегистрироваться (после регистрации ему ессно придётся заполнять все формы заново, обычное дело)? Программеру, между прочим, всё равно, а у PM`а обязанности не те, чтобы интерфейсы ещё на юзабельность и какую-то там эргономику тестировать.

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