Ну и - по традиции - расскажу, как лечится описанная выше херомантия (хотя все и так очевидно):
1. Не обещайте клиенту того, чего не сможете выполнить.
2. Если вы создаете геморные с точки зрения сервиса условия - сообщайте о них на видном месте.
3. В идеале, стройте свой сервис так, чтобы он помогал пользователю находить компромисс с геморными условиями. Это сложно, это больно, но в 95% случаев решаемо.
4. Не играйте с пользователем в прятки, только если он сам этого не захочет.
5. Не делайте говно на лопате.
Нарушение этих правил простительно только в том случае, если ваша бизнес-модель строится на прямом обмане клиентов, но это, сами понимаете, дело такое.
#бисквитныйдвор
P.S. Если у вас есть свои золотые кандидаты в БИСКВИТНЫЙ ДВОР, не ленитесь слать их мне в личку.
1. Не обещайте клиенту того, чего не сможете выполнить.
2. Если вы создаете геморные с точки зрения сервиса условия - сообщайте о них на видном месте.
3. В идеале, стройте свой сервис так, чтобы он помогал пользователю находить компромисс с геморными условиями. Это сложно, это больно, но в 95% случаев решаемо.
4. Не играйте с пользователем в прятки, только если он сам этого не захочет.
5. Не делайте говно на лопате.
Нарушение этих правил простительно только в том случае, если ваша бизнес-модель строится на прямом обмане клиентов, но это, сами понимаете, дело такое.
#бисквитныйдвор
P.S. Если у вас есть свои золотые кандидаты в БИСКВИТНЫЙ ДВОР, не ленитесь слать их мне в личку.
Про ТЗ вот вспомнил пятничную историю.
Жила-была одна контора разработчиков, которая сидела по соседству с нами и была нашим партнером. Ее владелец был колоритным армянином, похожим на хорошо откормленного Железного человека, и обожал мне повторять при встрече: «ЛЁХА ТВОЕ ТЗ ГОВНО». Я сперва деликатно отвечал, что-де, а в чем именно говно и давайте разберемся; потом просто злился; потом молчал; потом уже автоматом отвечал ему «ДА САМ ТЫ ГОВНО», а потом произошло вот что.
Как-то раз написал я ТЗ на личный кабинет одного пенсионного фонда и отправил его тем самым разработчикам. Они взяли ТЗ в работу и пообещали выдать результат через 3 недели - допустим, к 31 февраля.
И вот на календаре 30 февраля. Вечер. Падает снег, все дела, а у меня раздается звонок от тимлида этой партнерской конторы - типа, Лёха, заходи, надо кое-что обсудить важное.
Захожу. Тимлид показывает мне на мониторе 12 страницу ТЗ и говорит такой: «ЛЁХА Я НЕ ПОНИМАЮ КАК ЭТО ДОЛЖНО РАБОТАТЬ». Я ему в ответ говорю - как так, Миш, это же 12 страница, и тут все просто - а у тебя впереди еще 56 страниц, и там все куда сложнее.
Он такой: «НУ ВОТ Я НАЧАЛ ЧИТАТЬ И НЕ ПОНИМАЮ».
Я ему: Мишаня, а как ты только начал читать-то? Ты ничего не делал эти 3 недели, что ли?
Он такой: «ДЕЛАЛ» - и показывает кусок сырой херни, которая отдаленно похожа на сделанный мной личный кабинет.
Я ему: Миш, а Миш, а ты ТЗ вообще читал, прежде чем делать?
Он такой: «НЕТ», говорит.
Я молчу, уставившись в монитор как баран. И тут матерый программист Миша выдает шикарную фразу: «ТУТ МНОГО ТЕКСТА А ЛЮДИ ВООБЩЕ ПРИВЫКЛИ КАРТИНКАМИ МЫСЛИТЬ».
Еще раз: программист структурированного текста испугался. Текста. Программист. Подумать только.
В этот момент я четко понял, почему мое хорошее, чистое и опрятное ТЗ они считали говном - они его просто не читали.
Так я вывел простую мысль, достойную Agile-манифеста: хреновому разработчику напиши мало - ничего не сделает, напиши много - не прочитает и все равно ничего не сделает. Просто не надо хреновых разработчиков брать.
Потом эта контора как-то случайно взяла на должность программиста курьера, ошибшегося дверью, но это уже другая история.
#изкрестьянскогобыта #вашидокументы
Жила-была одна контора разработчиков, которая сидела по соседству с нами и была нашим партнером. Ее владелец был колоритным армянином, похожим на хорошо откормленного Железного человека, и обожал мне повторять при встрече: «ЛЁХА ТВОЕ ТЗ ГОВНО». Я сперва деликатно отвечал, что-де, а в чем именно говно и давайте разберемся; потом просто злился; потом молчал; потом уже автоматом отвечал ему «ДА САМ ТЫ ГОВНО», а потом произошло вот что.
Как-то раз написал я ТЗ на личный кабинет одного пенсионного фонда и отправил его тем самым разработчикам. Они взяли ТЗ в работу и пообещали выдать результат через 3 недели - допустим, к 31 февраля.
И вот на календаре 30 февраля. Вечер. Падает снег, все дела, а у меня раздается звонок от тимлида этой партнерской конторы - типа, Лёха, заходи, надо кое-что обсудить важное.
Захожу. Тимлид показывает мне на мониторе 12 страницу ТЗ и говорит такой: «ЛЁХА Я НЕ ПОНИМАЮ КАК ЭТО ДОЛЖНО РАБОТАТЬ». Я ему в ответ говорю - как так, Миш, это же 12 страница, и тут все просто - а у тебя впереди еще 56 страниц, и там все куда сложнее.
Он такой: «НУ ВОТ Я НАЧАЛ ЧИТАТЬ И НЕ ПОНИМАЮ».
Я ему: Мишаня, а как ты только начал читать-то? Ты ничего не делал эти 3 недели, что ли?
Он такой: «ДЕЛАЛ» - и показывает кусок сырой херни, которая отдаленно похожа на сделанный мной личный кабинет.
Я ему: Миш, а Миш, а ты ТЗ вообще читал, прежде чем делать?
Он такой: «НЕТ», говорит.
Я молчу, уставившись в монитор как баран. И тут матерый программист Миша выдает шикарную фразу: «ТУТ МНОГО ТЕКСТА А ЛЮДИ ВООБЩЕ ПРИВЫКЛИ КАРТИНКАМИ МЫСЛИТЬ».
Еще раз: программист структурированного текста испугался. Текста. Программист. Подумать только.
В этот момент я четко понял, почему мое хорошее, чистое и опрятное ТЗ они считали говном - они его просто не читали.
Так я вывел простую мысль, достойную Agile-манифеста: хреновому разработчику напиши мало - ничего не сделает, напиши много - не прочитает и все равно ничего не сделает. Просто не надо хреновых разработчиков брать.
Потом эта контора как-то случайно взяла на должность программиста курьера, ошибшегося дверью, но это уже другая история.
#изкрестьянскогобыта #вашидокументы
Давайте сбросим онлайн-оковы и предадимся утехам реальности (у меня еще запасен текст про проблемы параллельного проектирования всего на свете, но давайте этот праздник задротства оставим на выходные).
На фото выше вы видите летопись многодневной, тяжелой и изнуряющей битвы пользователей с владельцем продукта (представители управляющей компании, наверное, удивились бы такому титулу и обиженно переспросили бы «НИМА УЧУН ШУНДАЙ КИЛЯПСАН?»).
Короче, дело было так:
1. Жила-была Даниловская мануфактура с удобной лестницей. Все пользовались лестницей и были счастливы.
2. Управляющая компания в рамках Федеральной программы «Задай огня этим пешеходам» поставила кладбищенскую оградку в конце лестницы, какбе намекнув людям ходить в обход по набережной без тротуара и c кучей машин.
3. Народ пожал плечами и стал перешагивать через оградку.
4. Управляющая компания, возомнив себя шашечным гроссмейстером, сделала свой ход, выдвинув на переднюю позицию клумбу, которая нафиг заблокировала лестницу.
5. Народ пожал плечами и стал топтать газон.
6. Итог: вытоптанный газон, кладбищенская оградка, клумба в конце лестницы, пожимающий плечами народ. Вид, деликатно скажем, уродливее некуда. Если бы это был сайт, то он попал бы к нам в БИСКВИТНЫЙ ДВОР и мы долго и обидно смеялись бы над его фасоном.
Мораль I: ставьте дверь там, где ходят люди, а не там, где возжелалось вашей экспертной заднице. Иначе люди пробьют двери сами.
Мораль II: если понять, по какой логике управляющие компании занимаются благоустройством, то откроется сакральное знание, как вообще существует сайт galya.ru.
#хуикс4real
На фото выше вы видите летопись многодневной, тяжелой и изнуряющей битвы пользователей с владельцем продукта (представители управляющей компании, наверное, удивились бы такому титулу и обиженно переспросили бы «НИМА УЧУН ШУНДАЙ КИЛЯПСАН?»).
Короче, дело было так:
1. Жила-была Даниловская мануфактура с удобной лестницей. Все пользовались лестницей и были счастливы.
2. Управляющая компания в рамках Федеральной программы «Задай огня этим пешеходам» поставила кладбищенскую оградку в конце лестницы, какбе намекнув людям ходить в обход по набережной без тротуара и c кучей машин.
3. Народ пожал плечами и стал перешагивать через оградку.
4. Управляющая компания, возомнив себя шашечным гроссмейстером, сделала свой ход, выдвинув на переднюю позицию клумбу, которая нафиг заблокировала лестницу.
5. Народ пожал плечами и стал топтать газон.
6. Итог: вытоптанный газон, кладбищенская оградка, клумба в конце лестницы, пожимающий плечами народ. Вид, деликатно скажем, уродливее некуда. Если бы это был сайт, то он попал бы к нам в БИСКВИТНЫЙ ДВОР и мы долго и обидно смеялись бы над его фасоном.
Мораль I: ставьте дверь там, где ходят люди, а не там, где возжелалось вашей экспертной заднице. Иначе люди пробьют двери сами.
Мораль II: если понять, по какой логике управляющие компании занимаются благоустройством, то откроется сакральное знание, как вообще существует сайт galya.ru.
#хуикс4real
Я совершенно забыл поблагодарить за последний подгон товарища Семена Злобина. Здоровья ему, счастья, детишек побольше.
А вот какой образец ЖЭК-арта прислала мне в ответ на последний пост госпожа Анастасия Дэ - смотрите ниже. И на этом с оградами закончим, а то я себя каким-то Варламовым уже чувствую.
А вот какой образец ЖЭК-арта прислала мне в ответ на последний пост госпожа Анастасия Дэ - смотрите ниже. И на этом с оградами закончим, а то я себя каким-то Варламовым уже чувствую.
Простите, что так пропал - решали тут на работе сложную задачу про волка, козу и капусту, которых надо переправить на другой берег в режиме Scrum’а (скрам-мастер, распевание скрам-псалмов по утрам и перевешивание стикеров с места на место прилагаются). Поскольку меня злобно у вас украли, я хочу отомстить ЭТОМУ ВАШЕМУ СКРУМУ и сказать про него от себя пару ласковых.
Точнее, про сам СКРУМ я рассказывать не буду - про него уже отхоливарено столько, что на двадцать гражданских войн хватит, - но хочу порассуждать о том, как СКРУМ взаимодействует с UX.
Взаимодействует он, прямо скажем, херово. Классический СКРУМ (насколько к нему вообще применимо слово «классический») предполагает, что у нас есть 3 роли - СКРУМ-мастер, продакт овнер и толпа разработчиков, разношерстных как средневековые бриганды. Продакт овнер определяет приоритеты и переживает, СКРУМ-мастер устраивает стендапы и перевешивает стикеры, а бриганды берут под козырек и совместно пилят фичи в рамках спринта - двух недель или, там, месяца.
По замыслу СКРУМ-фундаменталистов, в этот момент должна устанавливаться благодать как на картинах эпохи романтизма (пейзане и пейзанки, коровы на залитом солнцем лугу и так далее); в реальной жизни вместо этого в итоге выстраивается типичная картина Брейгеля-старшего (алкашня, писающие собаки, разруха и уныние), особенно если говорить про UX-составляющую.
Почему так происходит? СКРУМ предполагает, что команда разработчиков обладает так называемыми Т-компетенциями: каждый специалист со временем прокачивается по смежным навыкам, и в идеальной перспективе аналитики начинают разбираться в коде, а разработчик - пропитываться аналитическими компетенциями, а все вместе они начинают учиться хитростям профессии QA. Сам по себе подход здравый: T-образные компетенции помогают балансировать нагрузку на команду и всем скопом наваливаться на задачи по аналитике и разработке. Ряд идеологов, впрочем, останавливается на делении на аналитиков и разработчиков, но общей сути это не меняет - все в команде начинают заниматься всем, попутно пропитываясь духом продукта, развивая чувство локтя и так далее.
Вся эта схема работает ровно до того момента, пока в СКРУМ не вклинивается UX. И вот тогда начинаются интересные вещи:
1. Наши бриганды - аналитики, девелоперы и QA - с жутким скрипом учатся UX-подходам, не понимают этой штуки и начинают творить лютую продуктовую фигню.
2. В процесс привлекается UX-дизайнер, который с порога начинает ЛЮТО, БЕШЕНО страдать: выполнение его работы требует долгих исследований и танцев с бубном, которые выходят за рамки спринта (что с точки зрения СКРУМа грешновато - все должно вписываться в спринт и преображаться в конкретный командный артефакт), а ту работу, которую он может сделать руками здесь и сейчас, он делает за три дня и сразу начинает скучать.
3. «ДАВАЙТЕ НАУЧИМ ЭТОГО СРАНОГО ДИЗАЙНЕРА КОДИТЬ ЧТОБЫ НЕ ПРОСТАИВАЛ» - начинает вопить СКРУМ-мастер и оказывается не прав, потому что большинство UX-дизайнеров органически не любят кодить и этому учиться не будут. Кроме того, если он даже будет кодить - кто ж будет исследовать и делать миллион подготовительных приседаний к дизайн-работе, которые требуют массу времени и сил?
4. «ДАВАЙТЕ РАСШАРИМ ДИЗАЙНЕРА СРАЗУ НА НЕСКОЛЬКО КОМАНД» - озаряет еще кого-нибудь, и бедного дизайнера начинают рвать на задачи нескольких команд сразу, от чего у него теряется весь фокус на задачах, подрывается командный дух и появляется ощущение, что он вернулся в старое-доброе агентство с 10 проектами в параллели и 20 менеджерами над головой.
Точнее, про сам СКРУМ я рассказывать не буду - про него уже отхоливарено столько, что на двадцать гражданских войн хватит, - но хочу порассуждать о том, как СКРУМ взаимодействует с UX.
Взаимодействует он, прямо скажем, херово. Классический СКРУМ (насколько к нему вообще применимо слово «классический») предполагает, что у нас есть 3 роли - СКРУМ-мастер, продакт овнер и толпа разработчиков, разношерстных как средневековые бриганды. Продакт овнер определяет приоритеты и переживает, СКРУМ-мастер устраивает стендапы и перевешивает стикеры, а бриганды берут под козырек и совместно пилят фичи в рамках спринта - двух недель или, там, месяца.
По замыслу СКРУМ-фундаменталистов, в этот момент должна устанавливаться благодать как на картинах эпохи романтизма (пейзане и пейзанки, коровы на залитом солнцем лугу и так далее); в реальной жизни вместо этого в итоге выстраивается типичная картина Брейгеля-старшего (алкашня, писающие собаки, разруха и уныние), особенно если говорить про UX-составляющую.
Почему так происходит? СКРУМ предполагает, что команда разработчиков обладает так называемыми Т-компетенциями: каждый специалист со временем прокачивается по смежным навыкам, и в идеальной перспективе аналитики начинают разбираться в коде, а разработчик - пропитываться аналитическими компетенциями, а все вместе они начинают учиться хитростям профессии QA. Сам по себе подход здравый: T-образные компетенции помогают балансировать нагрузку на команду и всем скопом наваливаться на задачи по аналитике и разработке. Ряд идеологов, впрочем, останавливается на делении на аналитиков и разработчиков, но общей сути это не меняет - все в команде начинают заниматься всем, попутно пропитываясь духом продукта, развивая чувство локтя и так далее.
Вся эта схема работает ровно до того момента, пока в СКРУМ не вклинивается UX. И вот тогда начинаются интересные вещи:
1. Наши бриганды - аналитики, девелоперы и QA - с жутким скрипом учатся UX-подходам, не понимают этой штуки и начинают творить лютую продуктовую фигню.
2. В процесс привлекается UX-дизайнер, который с порога начинает ЛЮТО, БЕШЕНО страдать: выполнение его работы требует долгих исследований и танцев с бубном, которые выходят за рамки спринта (что с точки зрения СКРУМа грешновато - все должно вписываться в спринт и преображаться в конкретный командный артефакт), а ту работу, которую он может сделать руками здесь и сейчас, он делает за три дня и сразу начинает скучать.
3. «ДАВАЙТЕ НАУЧИМ ЭТОГО СРАНОГО ДИЗАЙНЕРА КОДИТЬ ЧТОБЫ НЕ ПРОСТАИВАЛ» - начинает вопить СКРУМ-мастер и оказывается не прав, потому что большинство UX-дизайнеров органически не любят кодить и этому учиться не будут. Кроме того, если он даже будет кодить - кто ж будет исследовать и делать миллион подготовительных приседаний к дизайн-работе, которые требуют массу времени и сил?
4. «ДАВАЙТЕ РАСШАРИМ ДИЗАЙНЕРА СРАЗУ НА НЕСКОЛЬКО КОМАНД» - озаряет еще кого-нибудь, и бедного дизайнера начинают рвать на задачи нескольких команд сразу, от чего у него теряется весь фокус на задачах, подрывается командный дух и появляется ощущение, что он вернулся в старое-доброе агентство с 10 проектами в параллели и 20 менеджерами над головой.
5. «ЛАДНО ЛАДНО ДАВАЙТЕ ПРОСТО ПУСТИМ ДИЗАЙНЕРА РАБОТАТЬ НА ОПЕРЕЖЕНИЕ» - великодушно решает какой-нибудь сердобольный продакт овнер и разрешает дизайнеру планировать свою работу самостоятельно в отрыве от основного СКРУМ-процесса. И в этот момент для UX-дизайнера весь СКРУМ исчезает как с весенних яблонь дым: измученный дизайнер начинает работать по собственному, напрочь отвязанному циклу, перевешивая задачи на своей крохотной досочке и ориентируясь на единственную цель - давать основной СКРУМ-команде вовремя макеты.
На этом все выдыхают, успокаиваются и продолжают работать дальше. И все бы ничего, кабы не одно «но» - это уже не СКРУМ единой командой, а постоянное жонглирование разными методологиями и разными циклами разработки со всеми сопряженными рисками. Некоторым людям и особо либеральным Scrum-мастерам это ок, но многие упоротые СКРУМ-мастера начинают от того беситься и выть «УЧИТЕ ДИЗАЙНЕРА КОДИТЬ» и «УЧИТЕ РАЗРАБОТЧИКА ХУИКСУ». Наверное, где-то работает и такой подход с прокачкой, но в нормальном виде я его пока не встречал.
И не только я: на Западе очень многие проходились по сложным отношениям СКРУМа и UX, в том числе наши любимые гуру-деды из Норман-Нильсен Групп.
Так что если вас угораздило женить UX и СКРУМ, готовьтесь рвать задницу - не себе, так окружающим. Жизнь - все-таки сложная штука.
#изкрестьянскогобыта
На этом все выдыхают, успокаиваются и продолжают работать дальше. И все бы ничего, кабы не одно «но» - это уже не СКРУМ единой командой, а постоянное жонглирование разными методологиями и разными циклами разработки со всеми сопряженными рисками. Некоторым людям и особо либеральным Scrum-мастерам это ок, но многие упоротые СКРУМ-мастера начинают от того беситься и выть «УЧИТЕ ДИЗАЙНЕРА КОДИТЬ» и «УЧИТЕ РАЗРАБОТЧИКА ХУИКСУ». Наверное, где-то работает и такой подход с прокачкой, но в нормальном виде я его пока не встречал.
И не только я: на Западе очень многие проходились по сложным отношениям СКРУМа и UX, в том числе наши любимые гуру-деды из Норман-Нильсен Групп.
Так что если вас угораздило женить UX и СКРУМ, готовьтесь рвать задницу - не себе, так окружающим. Жизнь - все-таки сложная штука.
#изкрестьянскогобыта
🔥2
Друзья мои сердешные, как вы помните, я категорически не пускаю в этот блог рекламу - много мне платить не будут, а каждый из вас у меня и так на вес золота, чтобы подсовывать вам всякое гуано. Заместо этого я периодически палю бесплатную годноту, которая может оказаться вам полезна. Мне не жалко, а вам ничего не стоит - вот вам и основы для ДОВЕРИТЕЛЬНЫХ ОТНОШЕНИЙ между нами.
Сегодня я хочу рассказать вот о чем. В эту субботу (завтра) мы проводим очередное, аж тридцатое по счету собрание Гильдии вольных проектировщиков. Раз в месяц мы собираемся нашей профессиональной могучей кучкой и обсуждаем всякое-разное за продуктовый дизайн, всякое проектирование и нелегкую IT-жизнь. Обычно наши встречи закрыты для широкой публики, чтобы все было тепло и лампово.
В этот раз мы будем собираться по теме бизнес-анализа и говорить про то, как (и зачем) стать бизнес-аналитиком, что это вообще такое, как описывать бизнес-процессы и работать с этим хозяйством. Хедлайнером конвента будет Семен Злобин из компании Align Technology (https://www.aligntech.com, это крупный международный медтех). Давним читателям нашего хуикс-блога товарищ Семен Злобин уже знаком - это постоянный поставщик нашего БИСКВИТНОГО ДВОРА, за что ему очередной земной поклон.
Собираемся мы 13 июля в 11.45 в Москве на территории Даниловской мануфактуры (Варшавское ш., 9, стр. 1Б) в офисе Align Technology. В программе разговоры, общение и еще раз разговоры: как правило, каждая наша встреча превращается в уютную дискуссию, где можно поговорить о своем наболевшем.
А теперь ВНЕЗАПНЫЙ ПОВОРОТ СЮЖЕТА: это собрание мы решили открыть для широкой публики, чтобы придти на него мог каждый желающий. Бесплатно, без смс и прочих лопухов.
Нужна лишь регистрация вот тут: https://forms.gle/7BXRXaRATZhpExATA
Почему мы говорим об этом в последний момент? А чтобы веселее было (все равно мы это делаем не для количества).
Так что регистрируйтесь, приходите сами, приводите жен, детей и собак, будем только рады (ладно, про собак шучу, а детям чего про бизнес-процессы слушать, это законом не положено).
Я тоже буду с высоченной вероятностью, так что подходите знакомиться, устроим заодно АВТОРСКИЙ ВЕЧЕР ЛЁХИ БОРОДКИНА И СВИДЕТЕЛЕЙ ЕГО ХУИКСА.
#агабесплатнаягоднота
Сегодня я хочу рассказать вот о чем. В эту субботу (завтра) мы проводим очередное, аж тридцатое по счету собрание Гильдии вольных проектировщиков. Раз в месяц мы собираемся нашей профессиональной могучей кучкой и обсуждаем всякое-разное за продуктовый дизайн, всякое проектирование и нелегкую IT-жизнь. Обычно наши встречи закрыты для широкой публики, чтобы все было тепло и лампово.
В этот раз мы будем собираться по теме бизнес-анализа и говорить про то, как (и зачем) стать бизнес-аналитиком, что это вообще такое, как описывать бизнес-процессы и работать с этим хозяйством. Хедлайнером конвента будет Семен Злобин из компании Align Technology (https://www.aligntech.com, это крупный международный медтех). Давним читателям нашего хуикс-блога товарищ Семен Злобин уже знаком - это постоянный поставщик нашего БИСКВИТНОГО ДВОРА, за что ему очередной земной поклон.
Собираемся мы 13 июля в 11.45 в Москве на территории Даниловской мануфактуры (Варшавское ш., 9, стр. 1Б) в офисе Align Technology. В программе разговоры, общение и еще раз разговоры: как правило, каждая наша встреча превращается в уютную дискуссию, где можно поговорить о своем наболевшем.
А теперь ВНЕЗАПНЫЙ ПОВОРОТ СЮЖЕТА: это собрание мы решили открыть для широкой публики, чтобы придти на него мог каждый желающий. Бесплатно, без смс и прочих лопухов.
Нужна лишь регистрация вот тут: https://forms.gle/7BXRXaRATZhpExATA
Почему мы говорим об этом в последний момент? А чтобы веселее было (все равно мы это делаем не для количества).
Так что регистрируйтесь, приходите сами, приводите жен, детей и собак, будем только рады (ладно, про собак шучу, а детям чего про бизнес-процессы слушать, это законом не положено).
Я тоже буду с высоченной вероятностью, так что подходите знакомиться, устроим заодно АВТОРСКИЙ ВЕЧЕР ЛЁХИ БОРОДКИНА И СВИДЕТЕЛЕЙ ЕГО ХУИКСА.
#агабесплатнаягоднота
Google Docs
Регистрация на Собрание Гильдии №30
Добро пожаловать в имени Карла Иваныча Вигерса регистрационную анкету на тридцатое собрание Гильдии вольных проектировщиков про бизнес-анализ, описание бизнес-требований, жизнь бизнес-аналитика и прочие бизнес-трудности.
Время: 13 июля 2019, 11:45
Место:…
Время: 13 июля 2019, 11:45
Место:…
«АНАЛИТИКИ НЕ УМЕЮТ В UX И ТВОРЯТ ЛЮТУЮ ФИГНЮ? ЛЁХА ТЫ СОВСЕМ ПОЕХАЛ ЧТО ЛИ?» - такие добрые письма стали мешками поступать в нашу дорогую редакцию с прошлого четверга, и я понял, что меня то ли не так поняли, то ли я сам не так выразился.
Что ж, я не гордый, мне выйти посреди Красной площади, шваркнуть от души шапкой о землю и вскрикнуть «ПРОСТИ МЕНЯ НАРОД РУССКИЙ ПРОСТИ МАТЬ СЫРА ЗЕМЛЯ ПРОСТИ МЕДВЕДЬ ЛЕСНОЙ ГОСТЬ НЕ ТОГО Я ХОТЕЛ» не зазорно. Давайте-ка я вам расскажу, что имел в виду на самом деле.
Вот вам три мысли.
1. Если в большинстве случаев посадить неподготовленного человека в кресло дизайнера, нахмурить скрам-брови и сказать «МАЛЮЙ МНЕ ИНТЕРФЕЙСЫ», то действительно получится вышеупомянутая лютая фигня. Рисовать интерфейсы - это определенный навык, который требует знания инструментов, наличия художественного вкуса, понимания методологий и так далее. Воспитать хорошего дизайнера - это долгий, муторный и требующий определенной предрасположенности процесс, который проходят далеко не все.
2. В ряде случаев можно спокойно отказаться от дизайнеров и жить в формате «нарисовал разработчику на бумажке - а он собрал это из готовых элементов за три прихлопа». Чаще всего это актуально для интерфейсов, предназначенных для узкого, лояльного круга пользователей - в случае админок, CRM и прочего внутреннего добра, где ошибиться не страшно. Тут главное не увлекаться - хорошие, продуманные внутренние интерфейсы куда лучше непродуманных, причем аргумент «а наши пользователи все равно никуда не денутся» не канает: любой UX-косяк во внутренней системе бьет и на продуктивности работы, и на лояльности человека к своей компании.
3. Наконец, самое главное. Я допустил лютую ошибку, что не провел в четверговом посте четкой грани между «дизайнером» и «UX-подходами»: если визуальному дизайну обучишь не каждого, то принципы работы с UX способны освоить практически все участники процесса за вычетом уж совсем откровенных психопатов. Более того, я всегда выступаю против ЭЛИТАРНОГО СТАТУСА ХУИКС-СПЕЦИАЛИСТОВ - по моей мерке, UX-компетенциями в продуктах будущего должны обладать все участники команды, чтобы понимать, как результат их труда будет сказываться на пользовательском восприятии, клиентской лояльности и, соответственно, успехе продукта в целом.
Я глубоко убежден, что в будущем в командах все будут UX (и аналитики, и разработчики, и QA, и менеджеры, и кто угодно еще), и это слово станет наконец-то бессмысленным и ненужным.
Еще раз: «UX-подходам» должны учиться все — это не меч короля Артура, который способен достать только зашибись какой элитарный герой. Если кто будет вам говорить обратное, то смело гоните его в жопу.
#изкрестьянскогобыта #снимаюшапку
Что ж, я не гордый, мне выйти посреди Красной площади, шваркнуть от души шапкой о землю и вскрикнуть «ПРОСТИ МЕНЯ НАРОД РУССКИЙ ПРОСТИ МАТЬ СЫРА ЗЕМЛЯ ПРОСТИ МЕДВЕДЬ ЛЕСНОЙ ГОСТЬ НЕ ТОГО Я ХОТЕЛ» не зазорно. Давайте-ка я вам расскажу, что имел в виду на самом деле.
Вот вам три мысли.
1. Если в большинстве случаев посадить неподготовленного человека в кресло дизайнера, нахмурить скрам-брови и сказать «МАЛЮЙ МНЕ ИНТЕРФЕЙСЫ», то действительно получится вышеупомянутая лютая фигня. Рисовать интерфейсы - это определенный навык, который требует знания инструментов, наличия художественного вкуса, понимания методологий и так далее. Воспитать хорошего дизайнера - это долгий, муторный и требующий определенной предрасположенности процесс, который проходят далеко не все.
2. В ряде случаев можно спокойно отказаться от дизайнеров и жить в формате «нарисовал разработчику на бумажке - а он собрал это из готовых элементов за три прихлопа». Чаще всего это актуально для интерфейсов, предназначенных для узкого, лояльного круга пользователей - в случае админок, CRM и прочего внутреннего добра, где ошибиться не страшно. Тут главное не увлекаться - хорошие, продуманные внутренние интерфейсы куда лучше непродуманных, причем аргумент «а наши пользователи все равно никуда не денутся» не канает: любой UX-косяк во внутренней системе бьет и на продуктивности работы, и на лояльности человека к своей компании.
3. Наконец, самое главное. Я допустил лютую ошибку, что не провел в четверговом посте четкой грани между «дизайнером» и «UX-подходами»: если визуальному дизайну обучишь не каждого, то принципы работы с UX способны освоить практически все участники процесса за вычетом уж совсем откровенных психопатов. Более того, я всегда выступаю против ЭЛИТАРНОГО СТАТУСА ХУИКС-СПЕЦИАЛИСТОВ - по моей мерке, UX-компетенциями в продуктах будущего должны обладать все участники команды, чтобы понимать, как результат их труда будет сказываться на пользовательском восприятии, клиентской лояльности и, соответственно, успехе продукта в целом.
Я глубоко убежден, что в будущем в командах все будут UX (и аналитики, и разработчики, и QA, и менеджеры, и кто угодно еще), и это слово станет наконец-то бессмысленным и ненужным.
Еще раз: «UX-подходам» должны учиться все — это не меч короля Артура, который способен достать только зашибись какой элитарный герой. Если кто будет вам говорить обратное, то смело гоните его в жопу.
#изкрестьянскогобыта #снимаюшапку
Наши любимые UX-деды из Норман-Нильсен недавно разродились многословной и желчной статьей про попапы - то есть всплывающие окошки.
Вот о чем пишет этот вестник ЗОЖ от мира UX:
1. Показывать попап сразу после загрузки или авторизации - ХРЕНОВО. Пользователь приходит и логинится явно не просто так, а с конкретной своей целью, а тут вы перед ним попапами машете и его отвлекаете.
Что делать: во-первых, придерживайтесь принципа взаимности (как его заумно называют деды - Reciprocity Principle): прежде чем совать что-то пользователям, дайте ему что-то полезное (или хотя бы поманите издали). Во-вторых, подумайте еще раз: скорее всего, ваша задача решается не только попапами.
Это касается окошек всех видов - и предупреждений, и рекламных объявлений, и запросов емейлов. Ловите тот момент, когда пользователь действительно позитивно к вам настроен и готов с вами жить дальше.
«КОКОКО, - взовьется иной маркетологический гость моего блога, - НО ВЕДЬ ТАКИЕ ОКОШКИ ДАЮТ ПОТРЯСАЮЩУЮ КОНВЕРСИЮ В ПОДПИСКИ». Это иногда правда так, соглашусь я (и UX-деды) - если судить в моменте. Но сколько пользователей вы взбесите таким манером на дальней перспективе? Много. Вот и думайте про долгие метрики тоже. Исключениями могут служить лишь самые экстренные случаи, когда вам непременно надо поломать пользовательский сценарий.
2. Спрашивать «ВАМ ПОНРАВИЛСЯ НАШ САЙТ?» до того, как пользователь составил представление о продукте - ХРЕНОВО. Спрашивать фидбэк у пользователя (вот эти все звездочки-оцените-нас, окошки для ввода отзывов и тому подобное) действительно можно и нужно. Главное - отлавливать правильный момент: чаще всего это окошко вылезает в самый неудобный момент, и сразу начинает люто бесить.
Что делать: привязать это окошко к финалу пользовательского сценария. Пришел ваш пользователь заказывать мешок картошки - так и спросите у него фидбэк, когда он эту картошку купит. И ни в коем случае не вставляйте эти окошки с запросом фидбэка посреди сложных задач, требующих сосредоточенности (типа заказа авиабилетов) - для таких UX-гуру припасен отдельный уголок в UX-аду.
3. Показывать один попап поверх другого - ХРЕНОВО. Тут я даже комментировать не буду: когда я натыкаюсь на подобные ПОПАПЫ ПОВЕРХ ПОПАПОВ ПОВЕРХ ПОПАПОВ, я вспоминаю то ли порносайты начала 00х, то ли зомби-апокалипсис, то ли и то и другое одновременно. Это просто плохо, некрасиво, муторно. Подвидом этого срама является целый паровоз из попапов, который тебе приходится сто лет закрывать.
Что делать: так не делать. Обходитесь одним сборным попапом, если совсем припекло - слайдером. А еще лучше - подумайте, как обойтись без попапов и общаться с пользователями без костылей.
4. Подсовывать в попапе на сайте предложение скачать мобильное приложение - ХРЕНОВО. Не, задумка владельцев сайтов понятна - к нам пришел мобильный пользователь, давайте-ка его перенаправим в мобилу, - но делается это чаще всего через жопу. Клиент, который зашел почитать какую-нибудь жалкую статью, бомбардируется ОКНОМ ВО ВЕСЬ ЭКРАН ПРО НАШЕ ВОЛШЕБНОЕ ПРИЛОЖЕНИЕ, скачивает его миллион лет по своему жалкому мобильному интернету - и в итоге понимает, что после открытия приложухи попал хрен знает куда и своей статьи не видит в упор. Финита, блин.
Что делать: рассказывать о приложении, не вклиниваясь между пользователями и продуктом. Обойдитесь ненавязчивыми плашками внизу экрана, контекстными подсказками - и, опять-таки, ищите для этого правильный момент, когда пользователь уже нашел и сделал, что ему нужно.
5. Делать ставку на то, что пользователи читают содержимое попапов - ХРЕНОВО. Они их просто не читают.
Что делать: не делать ставку на модальные окна. Попапы надо использовать только в действительно экстренных случаях и в тщательно спланированных местах, иначе будет плохо, сам старина Нильсен придет к вам с линейкой и надает по щам. А удар у него хлесткий.
#дедыписали
P.S. Вот злая статейка, с которой все началось: https://www.nngroup.com/articles/popups/ (тут еще и картинки есть повтыкать)
Вот о чем пишет этот вестник ЗОЖ от мира UX:
1. Показывать попап сразу после загрузки или авторизации - ХРЕНОВО. Пользователь приходит и логинится явно не просто так, а с конкретной своей целью, а тут вы перед ним попапами машете и его отвлекаете.
Что делать: во-первых, придерживайтесь принципа взаимности (как его заумно называют деды - Reciprocity Principle): прежде чем совать что-то пользователям, дайте ему что-то полезное (или хотя бы поманите издали). Во-вторых, подумайте еще раз: скорее всего, ваша задача решается не только попапами.
Это касается окошек всех видов - и предупреждений, и рекламных объявлений, и запросов емейлов. Ловите тот момент, когда пользователь действительно позитивно к вам настроен и готов с вами жить дальше.
«КОКОКО, - взовьется иной маркетологический гость моего блога, - НО ВЕДЬ ТАКИЕ ОКОШКИ ДАЮТ ПОТРЯСАЮЩУЮ КОНВЕРСИЮ В ПОДПИСКИ». Это иногда правда так, соглашусь я (и UX-деды) - если судить в моменте. Но сколько пользователей вы взбесите таким манером на дальней перспективе? Много. Вот и думайте про долгие метрики тоже. Исключениями могут служить лишь самые экстренные случаи, когда вам непременно надо поломать пользовательский сценарий.
2. Спрашивать «ВАМ ПОНРАВИЛСЯ НАШ САЙТ?» до того, как пользователь составил представление о продукте - ХРЕНОВО. Спрашивать фидбэк у пользователя (вот эти все звездочки-оцените-нас, окошки для ввода отзывов и тому подобное) действительно можно и нужно. Главное - отлавливать правильный момент: чаще всего это окошко вылезает в самый неудобный момент, и сразу начинает люто бесить.
Что делать: привязать это окошко к финалу пользовательского сценария. Пришел ваш пользователь заказывать мешок картошки - так и спросите у него фидбэк, когда он эту картошку купит. И ни в коем случае не вставляйте эти окошки с запросом фидбэка посреди сложных задач, требующих сосредоточенности (типа заказа авиабилетов) - для таких UX-гуру припасен отдельный уголок в UX-аду.
3. Показывать один попап поверх другого - ХРЕНОВО. Тут я даже комментировать не буду: когда я натыкаюсь на подобные ПОПАПЫ ПОВЕРХ ПОПАПОВ ПОВЕРХ ПОПАПОВ, я вспоминаю то ли порносайты начала 00х, то ли зомби-апокалипсис, то ли и то и другое одновременно. Это просто плохо, некрасиво, муторно. Подвидом этого срама является целый паровоз из попапов, который тебе приходится сто лет закрывать.
Что делать: так не делать. Обходитесь одним сборным попапом, если совсем припекло - слайдером. А еще лучше - подумайте, как обойтись без попапов и общаться с пользователями без костылей.
4. Подсовывать в попапе на сайте предложение скачать мобильное приложение - ХРЕНОВО. Не, задумка владельцев сайтов понятна - к нам пришел мобильный пользователь, давайте-ка его перенаправим в мобилу, - но делается это чаще всего через жопу. Клиент, который зашел почитать какую-нибудь жалкую статью, бомбардируется ОКНОМ ВО ВЕСЬ ЭКРАН ПРО НАШЕ ВОЛШЕБНОЕ ПРИЛОЖЕНИЕ, скачивает его миллион лет по своему жалкому мобильному интернету - и в итоге понимает, что после открытия приложухи попал хрен знает куда и своей статьи не видит в упор. Финита, блин.
Что делать: рассказывать о приложении, не вклиниваясь между пользователями и продуктом. Обойдитесь ненавязчивыми плашками внизу экрана, контекстными подсказками - и, опять-таки, ищите для этого правильный момент, когда пользователь уже нашел и сделал, что ему нужно.
5. Делать ставку на то, что пользователи читают содержимое попапов - ХРЕНОВО. Они их просто не читают.
Что делать: не делать ставку на модальные окна. Попапы надо использовать только в действительно экстренных случаях и в тщательно спланированных местах, иначе будет плохо, сам старина Нильсен придет к вам с линейкой и надает по щам. А удар у него хлесткий.
#дедыписали
P.S. Вот злая статейка, с которой все началось: https://www.nngroup.com/articles/popups/ (тут еще и картинки есть повтыкать)
Nielsen Norman Group
Popups: 10 Problematic Trends and Alternatives
Whether modal or not, most overlays appear at the wrong time, interrupt users during critical tasks, use poor language, and contribute to user disorientation.
👍1
Не удержался и утащил к себе бонус - хитрую диаграммку, которая показывает разницу между модальными и немодальными окнами, а также между лайтбоксами и нелайтбоксами. Если коротко:
Лайтбокс - задник приглушен, фокус внимания тем самым смещен на само окно. Нелайтбокс - задник не приглушен, пользователь не так хорошо сфокусирован.
Если у нас модальное окно, то пользователь не может нажимать ничего на его фоне, если немодальное - позволяет взаимодействовать с фоновым контентом.
Чаще всего лайтбоксы бывают модальными, но это не точно.
#дедыписали
Лайтбокс - задник приглушен, фокус внимания тем самым смещен на само окно. Нелайтбокс - задник не приглушен, пользователь не так хорошо сфокусирован.
Если у нас модальное окно, то пользователь не может нажимать ничего на его фоне, если немодальное - позволяет взаимодействовать с фоновым контентом.
Чаще всего лайтбоксы бывают модальными, но это не точно.
#дедыписали
Вы же понимаете, что вы не просто подписаны на канал Хуикс - но включены в ФЕДЕРАЛЬНУЮ ПРОГРАММУ UX ТРЕША УГАРА СОДОМИИ И РАСШАТЫВАНИЯ ОКНА ОВЕРТОНА? Хорошо.
Так вот, тема со всплывающими окнами получила неожиданное продолжение - да такое, что я зацокал языком и воскликнул O LA LA (спасибо моей дражайшей супруге Вере Павловне за подгон, традиционный земной ей поклон, счастья, здоровья и мужа богатого).
Прежде чем мы продолжим и вы откроете ту ссылку, которую я вам дам, прочтите Важное Объявление:
1. Если вам нет 18 лет, то ОФИЦИАЛЬНО НЕ СОВЕТУЮ ХОДИТЬ ПО ССЫЛКЕ (хотя кого это когда останавливало)
2. Если вы на работе, сидите в присутственном месте и, допустим, окружены детьми малыми - ОФИЦИАЛЬНО НЕ СОВЕТУЮ ХОДИТЬ ПО ССЫЛКЕ (хотя кого это когда… ну, вы поняли)
3. Если вы трепетная, ранимая личность (что вы тут вообще позабыли в этом горниле чужих грехов?) - то ТОЖЕ НЕ СОВЕТУЮ. Вместо этого посмотрите на потешное видео с белочками: https://youtu.be/IDaqFiLvcB0
И запомните: я предупреждал.
Оставшихся же я приглашаю отрастить усы, раскрутить диско-шар и нырнуть в, гм, стихотворный труд французской дизайн-студии Twistudio: https://www.twistudio.fr/lespassantes/ (сайт открывается только с десктопа - и это важно)
Когда вернетесь обратно и тяжело выдохнете O LA LA, все же посмотрите на потешное видео с белочками: https://youtu.be/IDaqFiLvcB0. Обещаю, после всех этих процедур будете как огурчик.
И будете по-другому смотреть на всплывающие окна.
#царьхуикс #18плюсминус
Так вот, тема со всплывающими окнами получила неожиданное продолжение - да такое, что я зацокал языком и воскликнул O LA LA (спасибо моей дражайшей супруге Вере Павловне за подгон, традиционный земной ей поклон, счастья, здоровья и мужа богатого).
Прежде чем мы продолжим и вы откроете ту ссылку, которую я вам дам, прочтите Важное Объявление:
1. Если вам нет 18 лет, то ОФИЦИАЛЬНО НЕ СОВЕТУЮ ХОДИТЬ ПО ССЫЛКЕ (хотя кого это когда останавливало)
2. Если вы на работе, сидите в присутственном месте и, допустим, окружены детьми малыми - ОФИЦИАЛЬНО НЕ СОВЕТУЮ ХОДИТЬ ПО ССЫЛКЕ (хотя кого это когда… ну, вы поняли)
3. Если вы трепетная, ранимая личность (что вы тут вообще позабыли в этом горниле чужих грехов?) - то ТОЖЕ НЕ СОВЕТУЮ. Вместо этого посмотрите на потешное видео с белочками: https://youtu.be/IDaqFiLvcB0
И запомните: я предупреждал.
Оставшихся же я приглашаю отрастить усы, раскрутить диско-шар и нырнуть в, гм, стихотворный труд французской дизайн-студии Twistudio: https://www.twistudio.fr/lespassantes/ (сайт открывается только с десктопа - и это важно)
Когда вернетесь обратно и тяжело выдохнете O LA LA, все же посмотрите на потешное видео с белочками: https://youtu.be/IDaqFiLvcB0. Обещаю, после всех этих процедур будете как огурчик.
И будете по-другому смотреть на всплывающие окна.
#царьхуикс #18плюсминус
YouTube
Eastern Gray Squirrel (Video for dogs and cats to watch...)
An Eastern Gray Squirrel eating bird seed.
Hardware: HTC One X
Hardware: HTC One X
У нас очередная хуикс-угадайка. Еще когда я вращался на агентской стороне, я ОЧЕНЬ часто натыкался на следующий дурацкий кейс:
1. К разработчику приходит заказчик и ставит задачу: хочу, мол, сайт. Или мобильное приложение. Или еще что цифровое.
2. Разработчик не на помойке себя нашел, а потому начинает ДИЗАЙН СУКА ПРОЦЕСС: изучает имеющиеся материалы, формирует сценарии (в формате JTBD, CJM - да хоть МЖМ).
3. Далее на основе сценариев разработчик делает прототипы интерфейсов - те самые уродливые черно-белые картинки, при виде которых следует кокетливо повизгивать «ДАННЫЙ ФОРМАТ ПРОТОТИПОВ ОТОБРАЖАЕТ ЛОГИКУ НО НЕ ЭМОЦИИ И ЭСТЕТИКУ ТАК ЧТО ОТСТАНЬТЕ СО СВОИМИ ШРИФТАМИ»).
4. Само собой, все артефакты ДИЗАЙН СУКА ПРОЦЕССА показываются менеджеру со стороны заказчика - кутылому молодому человеку, который лениво копается в прототипах и периодически ноет про то, что к Единовластному Большому Начальству (далее - ЕБН) мы понесем уже готовые макеты - дураку половину работы не показывают.
5. Поскольку день показа наработок ЕБН близится с угрожающей скоростью, уродливые прототипы отгружаются по мере готовности господину Дизайнеру, который начинает натягивать на каркас логического задротства полотнище креативности. Получается вроде ничего.
6. Настает встреча с ЕБН. На нее едут все участники от разработчиков, но первую скрипку играет господин Дизайнер - он же руками все рисовал, вот и показывает макеты самостоятельно.
7. Макеты господин Дизайнер показывает примерно в той же очередности, как и делал - тут у нас вот главная, тут у нас список новостей, вот тут раздел о компании, тут карточка товара, спасибо за внимание.
8. ЕБН кивает, процеживает «Вроде ничего» и дает добро на запуск в работу.
9. Макеты запускаются в работу, выкатываются разработчиком.
10. Когда в проект запускаются пользователи, выясняется, что интерфейс - говно.
Немая сцена.
(ВОТ И СКАЗОЧКЕ КОНЕЦ А КТО СЛУШАЛ ТОТ ДМИТРИЙ САТИН ВРЕМЕН ОСНОВАНИЯ ЮЗАБИЛИТИЛАБ)
1. К разработчику приходит заказчик и ставит задачу: хочу, мол, сайт. Или мобильное приложение. Или еще что цифровое.
2. Разработчик не на помойке себя нашел, а потому начинает ДИЗАЙН СУКА ПРОЦЕСС: изучает имеющиеся материалы, формирует сценарии (в формате JTBD, CJM - да хоть МЖМ).
3. Далее на основе сценариев разработчик делает прототипы интерфейсов - те самые уродливые черно-белые картинки, при виде которых следует кокетливо повизгивать «ДАННЫЙ ФОРМАТ ПРОТОТИПОВ ОТОБРАЖАЕТ ЛОГИКУ НО НЕ ЭМОЦИИ И ЭСТЕТИКУ ТАК ЧТО ОТСТАНЬТЕ СО СВОИМИ ШРИФТАМИ»).
4. Само собой, все артефакты ДИЗАЙН СУКА ПРОЦЕССА показываются менеджеру со стороны заказчика - кутылому молодому человеку, который лениво копается в прототипах и периодически ноет про то, что к Единовластному Большому Начальству (далее - ЕБН) мы понесем уже готовые макеты - дураку половину работы не показывают.
5. Поскольку день показа наработок ЕБН близится с угрожающей скоростью, уродливые прототипы отгружаются по мере готовности господину Дизайнеру, который начинает натягивать на каркас логического задротства полотнище креативности. Получается вроде ничего.
6. Настает встреча с ЕБН. На нее едут все участники от разработчиков, но первую скрипку играет господин Дизайнер - он же руками все рисовал, вот и показывает макеты самостоятельно.
7. Макеты господин Дизайнер показывает примерно в той же очередности, как и делал - тут у нас вот главная, тут у нас список новостей, вот тут раздел о компании, тут карточка товара, спасибо за внимание.
8. ЕБН кивает, процеживает «Вроде ничего» и дает добро на запуск в работу.
9. Макеты запускаются в работу, выкатываются разработчиком.
10. Когда в проект запускаются пользователи, выясняется, что интерфейс - говно.
Немая сцена.
(ВОТ И СКАЗОЧКЕ КОНЕЦ А КТО СЛУШАЛ ТОТ ДМИТРИЙ САТИН ВРЕМЕН ОСНОВАНИЯ ЮЗАБИЛИТИЛАБ)
Угадайте, на каком шаге ВСЕ ПОШЛО НЕ ТАК?
anonymous poll
4 – 80
👍👍👍👍👍👍👍 30%
1 (да вы оптимист) – 69
👍👍👍👍👍👍 26%
2 – 69
👍👍👍👍👍👍 26%
3 – 23
👍👍 9%
5 – 8
👍 3%
6 – 6
👍 2%
8 – 4
▫️ 1%
9 – 4
▫️ 1%
10 – 3
▫️ 1%
7 – 2
▫️ 1%
👥 268 people voted so far.
anonymous poll
4 – 80
👍👍👍👍👍👍👍 30%
1 (да вы оптимист) – 69
👍👍👍👍👍👍 26%
2 – 69
👍👍👍👍👍👍 26%
3 – 23
👍👍 9%
5 – 8
👍 3%
6 – 6
👍 2%
8 – 4
▫️ 1%
9 – 4
▫️ 1%
10 – 3
▫️ 1%
7 – 2
▫️ 1%
👥 268 people voted so far.
Вот вам ответы на хуикс-угадайку, которую я вам загадал в прошлый раз (если вы ее еще не читали, сбегайте быстро почитайте и возвращайтесь, чего мы тут вас ждем, ну).
По своему обыкновению, в угадайку я заложил некоторое трололо: потенциально все ответы на нее были верными. В том есть великая сермяга: в заказной разработке НЕ ТАК может пойти буквально все, и остается вопрос - с какой вероятностью и почему это может произойти. Так что давайте разберем каждый из этапов угадайки и проследим, что может случиться. Рядом с каждым этапом я буду писать процент ваших голосов.
1. К разработчику приходит заказчик и ставит задачу: хочу, мол, сайт (24%). Действительно, уже на этом этапе все может полететь в тартарары: в идеале, заказчик должен не ставить задачу «ХОЧУ КРАСНЫЙ САЙТ СО СЛАЙДЕРОМ», но выдвигать определенную бизнес-проблему, которую ему нужно решить. Иное дело, что это в идеале: в жизни полно кривых разработчиков, которые понимают только задачи «ХОЧУ САЙТ СО СЛАЙДЕРОМ» (и даже спрашивают об этом в брифе!), а также жопных заказчиков, которые решают, что они знают все лучше всех на свете. В итоге вторые заказывают то, что им не нужно, а первые не делают то, что от них ожидается. Вин, сука, вин.
2. Разработчик не на помойке себя нашел, а потому начинает ДИЗАЙН СУКА ПРОЦЕСС (24%). На первый взгляд, удивительно: смотришь на эти 24% и думаешь - ну чо такого, как же без дизайн-процесса вообще стартовать разработку? Ответ тут простой - нередко ДИЗАЙН СУКА ПРОЦЕСС затевается ради ДИЗАЙН СУКА ПРОЦЕССА: перед заказчиком раскатывается ДИЗАЙН-МЫШЛЕНИЕ, его мурыжат на КАСТДЕВ-ВОРКШОПАХ, ему затирают про ДЖОБС ТУБИДАН и ПЕРСОНАЖЕЙ, вовлекают в БРЕЙНШТОРМЫ и кормят АЙС БРЕЙКЕРАМИ, а на выходе выдают кусок унылого дермантина, который даже врагу подкинуть совестно (а разработать - и вообще невозможно). В итоге все наедаются говна, а признаться в этом стыдно, и потому все важно делают вид, что все прошло офигенчик. Посему заслушайте мораль: без ДИЗАЙН СУКА ПРОЦЕССА вы никуда не уедете, но он должен не просто быть, но работать, быть управляемым и понятным для всех, а его результаты - безусловно внедряться. Не верьте словам, верьте делу.
3. Далее на основе сценариев разработчик делает прототипы интерфейсов - те самые уродливые черно-белые картинки (9%). Тут тоже интересно. Прототипы - штука крайне полезная (поскольку сильно экономит время дизайнера и команды), но изредка и она оказывается опасной. Самые страшные мои истории были связаны или с тем, что мы увлеклись и сделали слишком сложные интерактивные прототипы, которые было безумно сложно поддерживать и изменять - или с тем, что мы увлеклись и сделали слишком красивые прототипы, которые потеряли черно-белую условность, но не стали красивыми макетами, застряв в безжалостном уродстве посередине. Поэтому совет - не увлекайтесь. Прототип на то и прототип, чтобы быть быстро сделанным, а потом выброшенным на обочину истории во имя финального продукта.
4. Все артефакты ДИЗАЙН СУКА ПРОЦЕССА показываются менеджеру со стороны заказчика - кутылому молодому человеку (32%). Это безусловный фаворит в нашем голосовании, и вы еще как правы. Если вам достался дурной менеджер со стороны заказчика, то я могу вас поздравить - вы попали на съемки документального кинофильма «Стелите гроб, я спать пришел».
По своему обыкновению, в угадайку я заложил некоторое трололо: потенциально все ответы на нее были верными. В том есть великая сермяга: в заказной разработке НЕ ТАК может пойти буквально все, и остается вопрос - с какой вероятностью и почему это может произойти. Так что давайте разберем каждый из этапов угадайки и проследим, что может случиться. Рядом с каждым этапом я буду писать процент ваших голосов.
1. К разработчику приходит заказчик и ставит задачу: хочу, мол, сайт (24%). Действительно, уже на этом этапе все может полететь в тартарары: в идеале, заказчик должен не ставить задачу «ХОЧУ КРАСНЫЙ САЙТ СО СЛАЙДЕРОМ», но выдвигать определенную бизнес-проблему, которую ему нужно решить. Иное дело, что это в идеале: в жизни полно кривых разработчиков, которые понимают только задачи «ХОЧУ САЙТ СО СЛАЙДЕРОМ» (и даже спрашивают об этом в брифе!), а также жопных заказчиков, которые решают, что они знают все лучше всех на свете. В итоге вторые заказывают то, что им не нужно, а первые не делают то, что от них ожидается. Вин, сука, вин.
2. Разработчик не на помойке себя нашел, а потому начинает ДИЗАЙН СУКА ПРОЦЕСС (24%). На первый взгляд, удивительно: смотришь на эти 24% и думаешь - ну чо такого, как же без дизайн-процесса вообще стартовать разработку? Ответ тут простой - нередко ДИЗАЙН СУКА ПРОЦЕСС затевается ради ДИЗАЙН СУКА ПРОЦЕССА: перед заказчиком раскатывается ДИЗАЙН-МЫШЛЕНИЕ, его мурыжат на КАСТДЕВ-ВОРКШОПАХ, ему затирают про ДЖОБС ТУБИДАН и ПЕРСОНАЖЕЙ, вовлекают в БРЕЙНШТОРМЫ и кормят АЙС БРЕЙКЕРАМИ, а на выходе выдают кусок унылого дермантина, который даже врагу подкинуть совестно (а разработать - и вообще невозможно). В итоге все наедаются говна, а признаться в этом стыдно, и потому все важно делают вид, что все прошло офигенчик. Посему заслушайте мораль: без ДИЗАЙН СУКА ПРОЦЕССА вы никуда не уедете, но он должен не просто быть, но работать, быть управляемым и понятным для всех, а его результаты - безусловно внедряться. Не верьте словам, верьте делу.
3. Далее на основе сценариев разработчик делает прототипы интерфейсов - те самые уродливые черно-белые картинки (9%). Тут тоже интересно. Прототипы - штука крайне полезная (поскольку сильно экономит время дизайнера и команды), но изредка и она оказывается опасной. Самые страшные мои истории были связаны или с тем, что мы увлеклись и сделали слишком сложные интерактивные прототипы, которые было безумно сложно поддерживать и изменять - или с тем, что мы увлеклись и сделали слишком красивые прототипы, которые потеряли черно-белую условность, но не стали красивыми макетами, застряв в безжалостном уродстве посередине. Поэтому совет - не увлекайтесь. Прототип на то и прототип, чтобы быть быстро сделанным, а потом выброшенным на обочину истории во имя финального продукта.
4. Все артефакты ДИЗАЙН СУКА ПРОЦЕССА показываются менеджеру со стороны заказчика - кутылому молодому человеку (32%). Это безусловный фаворит в нашем голосовании, и вы еще как правы. Если вам достался дурной менеджер со стороны заказчика, то я могу вас поздравить - вы попали на съемки документального кинофильма «Стелите гроб, я спать пришел».
Все дело в том, что ценность работы любого агентства (от студии Лебедева до кучки студентов под каким-нибудь дурацким названием типа ПРО ВЕБ ДЕВЕЛОПМЕНТ) напрямую зависит от менеджера на стороне заказчика. Достался вам хороший менеджер, который заинтересован в продукте - все будет хорошо: он даст развернуться вашему профессионализму во всю ширь, укажет вам на ваши косяки, поможет в случае неурядиц, наладит коммуникацию и будет верным адвокатом продукта (и отчасти вас).
Если же в роли менеджера вам попалось грустное психопатическое созданье, то пиши пропало: с таким товарищем порой не совладать и лучшему агентству. Все нормальные инициативы будут стопориться, важная информация - пропадать, а вы приедете на презентацию топовому руководству и поймете, что руководство впервые слышит про ваш проект, знать не знает про ваши методы и вообще надо все переделать с нуля. Однажды у меня случилась в связи с этим поистине золотая история, но я вам про нее потом расскажу.
И на этом пункте мы сделаем, пожалуй, перерыв. Сходите выпейте коньяку, посмотрите на склоны Кавказа, поиграйте с кошкой (или что там у вас заместо кошки и Кавказа); у нас все только начинается - следующий пункт будет весьма убойным, ведь мы будем говорить про ОТРИСОВКУ ДИЗАЙНА.
#хуиксугадайка #изкрестьянскогобыта
Если же в роли менеджера вам попалось грустное психопатическое созданье, то пиши пропало: с таким товарищем порой не совладать и лучшему агентству. Все нормальные инициативы будут стопориться, важная информация - пропадать, а вы приедете на презентацию топовому руководству и поймете, что руководство впервые слышит про ваш проект, знать не знает про ваши методы и вообще надо все переделать с нуля. Однажды у меня случилась в связи с этим поистине золотая история, но я вам про нее потом расскажу.
И на этом пункте мы сделаем, пожалуй, перерыв. Сходите выпейте коньяку, посмотрите на склоны Кавказа, поиграйте с кошкой (или что там у вас заместо кошки и Кавказа); у нас все только начинается - следующий пункт будет весьма убойным, ведь мы будем говорить про ОТРИСОВКУ ДИЗАЙНА.
#хуиксугадайка #изкрестьянскогобыта